Input monitoring permissions are requested on MacOS Big Sur

[sumibi-yakitori]

If Tetra uses sdl2::sdl::JoystickSubsystem or sdl2::sdl::GameControllerSubsystem, it seems that Input Monitoring permission is required on MacOS Big Sur.
Until MacOS Catalina, the dialog requesting this permission was never displayed.

This problem occurs when I run an application that I created using tetra as an application package using cargo bundle

We may have to wait for the upstream library to fix this problem, but could it be handled on tetra?
Such as a flag to disable joystick support, etc.

Links that may be relevant to this issue: https://discourse.libsdl.org/t/macos-catalina-keyboard-monitoring-permission/27529

// Official sample code for rust-sdl2
extern crate sdl2;

use sdl2::event::Event;
use sdl2::keyboard::Keycode;
use sdl2::pixels::Color;
use std::time::Duration;

fn main() -> Result<(), String> {
    let sdl_context = sdl2::init()?;
    let video_subsystem = sdl_context.video()?;

    // Request input monitoring privileges !!
    {
        let joystick_sys = sdl_context.joystick()?;
        let controller_sys = sdl_context.game_controller()?;
    }

    let haptic_sys = sdl_context.haptic()?;

    let window = video_subsystem
        .window("rust-sdl2 demo: Events", 800, 600)
        .position_centered()
        .resizable()
        .build()
        .map_err(|e| e.to_string())?;

    let mut canvas = window.into_canvas().build().map_err(|e| e.to_string())?;

    canvas.set_draw_color(Color::RGB(255, 0, 0));
    canvas.clear();
    canvas.present();
    let mut event_pump = sdl_context.event_pump()?;

    println!("This example simply prints all events SDL knows about.");

    'running: loop {
        for event in event_pump.poll_iter() {
            match event {
                Event::Quit { .. }
                | Event::KeyDown {
                    keycode: Some(Keycode::Escape),
                    ..
                } => break 'running,
                Event::MouseMotion { .. } => {}
                e => {
                    println!("{:?}", e);
                }
            }
        }

        canvas.clear();
        canvas.present();
        ::std::thread::sleep(Duration::new(0, 1_000_000_000u32 / 30));
    }

    Ok(())
}

[17cupsofcoffee]

I found a more recent thread on the forums mentioning joysticks, so it's not just you: https://discourse.libsdl.org/t/my-sdl-app-is-asking-for-permission-to-read-all-keystrokes-from-any-application-on-macos/32893

Do you happen to know if this is something that worked fine in older SDL versions? Or has an OS update made this start happening?

[17cupsofcoffee]

wow this comment ended up way too long

Maybe let's wait a little and see if the SDL2 devs respond? This issue theoretically affects a lot of projects other than Tetra (e.g. FNA unconditionally initializes the joystick subsystem at startup, and I think Love2D might as well), and I'd be interested to hear why it's suddenly started happening/if there's likely to be a fix in 2.0.18.

---

As far as I can tell, there are several possible workarounds for this issue on our end:

1. Downgrade sdl2-rs, recommend Mac users use the sdl2_bundled feature, and wait for things to hopefully get fixed in 2.0.18.

This would be a bit sad as there's some stuff in 2.0.16 I'd like to use in Tetra, and there's no guarenteed release timings for SDL2, so we could be waiting a while. But this would at least allow people to use gamepads on Mac without manual setup.

2. Keep the current sdl2-rs, ask Mac users to obtain 2.0.14 themselves (e.g. from source), and wait for things to hopefully get fixed in 2.0.18.

This would allow Tetra to carry on using new SDL features, but would make setting up a dev environment on Mac much more of a pain 😢

3. Add a ContextBuilder flag for enabling/disabling gamepads

This would be pretty simple to add, but would mean all the controller subsystems would have to be wrapped in Option, which is a bit ugly/might have overhead.

4. Add a input_gamepad feature flag

❌ This would be a breaking change, as even if we added it to the default feature, it would mean gamepad input would switch off for anyone who's Tetra dependency has no_default_features = true. This wouldn't be a bad idea when 0.7 comes out, but I don't know when that's going to be.

5. Add a disable_gamepad_input feature flag

This wouldn't be a breaking change, but non-additive feature flags are frowned upon in Cargo, as if a sub-dependency (e.g. egui-tetra) enables the feature, end-users can't then disable it. That said, it might be acceptable in this case, because there's zero reason for sub-dependencies to enable this, and it's very explicitly a workaround.

---

With all that in mind, I think my plan is to give Mac users three options on how to deal with this in the docs:

• Live with the prompt until it gets fixed upstream
• Build SDL2 2.0.14 from source (or obtain it from elsewhere)
• Disable gamepad input (haven't decided if this should be at runtime or via a feature flag yet)

Once I've made my mind up on how to approach this, I'll let you know :)

[sumibi-yakitori]

I see. As always, your insights are wonderful 👍
I'll wait a while.

The patch I was going to make was going to use method 3.

And it makes a lot of sense why the non-additive feature flags is frowned upon.
(I'm still using this)

[17cupsofcoffee]

I haven't forgotten about #245 😅 I would still like to support that use case better at some point.

[sumibi-yakitori]

Supplementary information.

Even if I install SDL2 from source, using brew upgrade will install the latest SDL2. This is due to the fact that ffmpeg and opencv depend on SDL2.

Since the probability of using these libraries is high if you are a programmer, you have to install the old SDL2 from source every time you update packages managed by the package manager...

[17cupsofcoffee]

Quick update: the SDL2 devs are going to try to replicate this.

I noticed on their GitHub that the 2.0.18 milestone has the due date set to November 12 - whether that means it's likely to be released in November, I'm not sure. If that ends up being the case (and assuming this gets fixed), I think we can skip adding the workaround and just wait a couple of weeks 🙂

If it looks like it's going to take longer than that, we can add the feature flag/runtime switch.