GetTempPath2() is only available on Windows 11 and Windows 10 systems with full updates. We want to be compatible back to earlier versions of Windows and the only difference between the two calls is the behavior for processes running as SYSTEM, which we don't expect for SDL applications using notifications.
It does better version checking and has better compatibility.
This also fixes a crash in GameInputRedist.dll when attempting to load v3 when v2 is installed on the system. In this case, a thread is created in GameInputCreate() which is not cleaned up when the object is released, and can crash later with a NULL pointer dereference.
Otherwise, a device that is disconnected in the standard audio device thread
might keep failing WaitDevice() in a tight loop, each one generating a new
main thread callback. In normal situations, this is wasteful, but if the
app isn't pumping the event loop quickly (or at all!), this will quickly eat
up all the memory in a machine.
Now we note that the device is zombified right away, and device thread
iteration will use this to replace the implementation with the Zombie
equivalents once it owns the device lock.
The main thread callback will progress to device->zombie==2, which it uses to
decide if this is a duplicate disconnect notification. Since it also owns the
lock at this point, it takes the moment to set the Zombie implementation up,
too.
This allows things (like the WASAPI backend) to check for a non-zero zombie
state immediately without having to worry if the main thread callback ran, and
for the standard audio threads to also move to the Zombie implementation
without waiting on that callback.
(The Zombie implementation is used to make a dead device keep processing, so
things that need the audio device to make progress to function will keep
working, and things blindly pushing to an audio stream won't queue up endless
data that isn't being consumed.)
Fixes#15745.
Originally, macOS had opposite Y axis inversion as every other platform, likely to correct for an issue with the virtual gamepad reported by the old 360Controller driver.
Wired Xbox 360 controllers using native macOS drivers were first reported to be broken in https://github.com/libsdl-org/SDL/issues/11002. The inversion was removed in 7da728a642, presumably breaking 360Controller usage, but fixing wired 360 controller using the new native support in macOS 15 and above. However, this change was reverted without explanation in d7b1ba1bfc which added explicit support for the Steam Virtual Gamepad. Presumably, Steam on macOS reports inverted Y axes to match what SDL expected on the platform. However, this reversion broke the native macOS controller support. The incorrect inversion also breaks using off-brand 360-class gamepads via the libusb backend of HIDRAW.
If we lose focus during startup, we need to unlock the activity mutex before waiting for the focus lifecycle event, otherwise it will never be delivered.
Reproduced using testcontroller with a DualSense controller attached and the "Allow the app to access the USB device?" dialog popped up.
This fixes a deadlock when a call comes in from Java that takes the activity lock and then tries to send an event, which takes the event lock, at the same time the application thread takes the event lock and then calls SDL_RequestAndroidPermission(), which takes the activity lock.
Fixes https://github.com/libsdl-org/SDL/issues/15772
Fixes https://github.com/libsdl-org/SDL/issues/15771
This prevents ABBA deadlocks caused by taking a hardware resource lock then delivering events at the same time another thread is taking a hardware resource lock from an event watch callback.
Fixes https://github.com/libsdl-org/SDL/issues/15709
Otherwise, it might cause a deadlock, if the output_callback runs in another
thread while the guaranteed initial hint callback fires. One will wait for the
SDL device lock, the other the pipewire thread loop lock, each already holding
what the other needs.
This way, the hint callback fires and we ignore it, since the stream isn't
set up yet...which is good, because we're about to create the stream and set
that exact same state on it directly anyhow. Now there's no chance of this
deadlock happening.
Reference Issue #15075.
Some sensors will occasionally report two identical timestamps in a row.
This leads to the timestamp wrapping calculation to underflow, subtracting
0x80000000 from the timestamp whenever it happens. By adjusting the wrap
test, we can just directly add zero to the timestamp, fixing the underflow.
That also covers removal of the call `SDLActivity.onNativeAccel`,
plus a change of comment under SDL_android.c.
Definitions were previously used while an accelerometer could be listed as a joystick.
