Changing the mode triggers a display reconfiguration event, which will overwrite the desktop mode with the set fullscreen mode, preventing proper restoration when leaving fullscreen. Don't overwrite the desktop mode if the reconfiguration is due to a fullscreen mode switch.
Fullscreen spaces and miniaturization will always give us some notification that they succeeded or failed, so the timeout isn't required. This prevents errant timeouts when live-resize is active.
Since there is no option to change it this seems like a much better default value. The stretching behaviour is really off-putting.
The new behavior shows a small black border when resizing the windows. This makes it more in line with the other backends and it's what you would expect to happen as a user.
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.
