I changed it so that the OS does the orientation change itself with a potential performance penalty.
This makes it automatically do the right thing, just like on iOS which would make the orientation change behaviour more consistent across different platforms.
But without adding an option to the user, this would disallow the user solving the problem in his in the app/shaders and saving some performance.
It's up to you to decide what to do. But I changed this in my local copy of the source for my use case.
But this also
* Update SDL_mouse.c
Stop a mouseID of SDL_PEN_MOUSEID being discarded when dispatching mouse events. I'm not sure if this enough to fix the lack of SDL_PEN_MOUSEID being emitted.
* Update SDL_mouse.c
Since we test for touch input here we also test for pen input in the same way.
* Stop duplicate synthetic touch events
If SDL_HINT_PEN_MOUSE_EVENTS and SDL_HINT_MOUSE_TOUCH_EVENTS are both enabled, the pen generated synthetic mouse event will then produce a touch event without this additional check.
This requires the previous commits in order to do anything since it needs to be able to identify those pen generated mouse events.
It looks like both macOS (15.1.1) and SDL are trying to talk to the controller at the same time, which can cause interleaved replies or even locking up the controller. Waiting a bit before talking to the controller seems to take care of this.
This can happen on Windows when the controller is turned off directly. It still shows up in the device list and you can send packets to it, but it's off and doesn't respond. We'll mark this device as broken and open the other as a single Joy-Con.
When the flushing is not able to keep up with the audio stream coming in, it
will end up flushing forever and block API clients from getting any audio.
The example program in #9706 get some audio with SDL 3, while do not get any
audio with SDL 2, which I suspect is because SDL 3 is quicker at flushing the audio.
A fix for the SDL 2 issue is available in #12378.
Additionally, add a warning about calling the frame visibility function universally during the mapping process, as the libdecor Cairo plugin has a bug that will cause a crash in this scenario.
If the pipewire thread invokes output_callback() while we're still
waiting inside PIPEWIRE_OpenDevice(), we will deadlock. The pipewire
thread owns the loop lock and is blocked on the audio device lock,
which cannot be released because pw_thread_loop_wait() needs to
reacquire the loop lock before it can return and allow
PIPEWIRE_OpenDevice() to complete and release the device lock.
guitarfreak