Add a loop around SDL_hid_read() in the Steam Deck HIDAPI driver as it
is done in other HIDAPI drivers. This loop reads data from the device and
processes it until the input buffer is empty which ensures that clients
always get the latest data.
This fixes an input latency issue if the application polls the events
slower than the hardware generates them.
This reverts commit 9f8dffbd2d.
This causes some tests to fail, and wasn't otherwise a necessary change, so
I'm backing it out.
(Looks like some sort of interaction with software renderers and their
surfaces not getting destroyed...?)
(cherry picked from commit f9a06c20ed)
This allows apps to destroy the window and renderer in either order, but
makes sure that the renderer can properly clean up its resources while OpenGL
contexts and libraries are still loaded, etc.
If the window is destroyed first, the renderer is (mostly) destroyed but its
pointer remains valid. Attempts to use the renderer will return an error,
but it can still be explicitly destroyed, at which time the struct is free'd.
If the renderer is destroyed first, everything works as before, and a new
renderer can still be created on the existing window.
Fixes#10174.
(cherry picked from commit cab3defc18)
Previously, each backend would allocate and free the renderer struct. Now
the higher level does it, so the backends only manage their private resources.
This removes some boilerplate and avoids some potential accidents.
(Manually cherry-picked from 39c8434f5f)
Reference Issue #10174.
- Disables chained fixups for macOS ('-no_fixup_chains' if supported by
linker), because it is not compatible with '-undefined dynamic_lookup'
- Fixes Wstrict-prototypes warnings
- Regenerate the 'configure' script.
Steam ran into a crash SDL_XINPUT_JoystickDetect() with XINPUTGETCAPABILITIES being NULL. I'm not sure how that happened, and there may still be a race condition if this is a multi-threaded issue, but at least this is more correct.
(cherry picked from commit 0ae4fd0ec9)
In the stdcpp thread implementation, the allocated std::thread objects were never deleted after joining/detaching
(cherry picked from commit 20dbe90771)
When loading libraries the `SDL.mContext` is still `null`. This results in
relinker code path in `SDL.loadLibrary(...)` always throwing a null exception
and fallbacking to system loader.
Fix it by passing the context explicitly.
Proton uses this on Linux to determine what the XInput slot is for the gamepad. Other applications will get the real controller name and VID/PID by virtue of the code in SDL_steam_virtual_gamepad.c
(cherry picked from commit 361cae0874)
I _did_ appreciate the explanation, but it doesn't have to live in the
source code; also we can just release `devuid` and then check for error with
the usual macro, since SDL is done with it either way at this point.
(cherry picked from commit 17af09f3a9)
