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
From @AntTheAlchemist:
This is an interesting one, on a Xiaomi MiTV. Caused by a camera device, full stack:
android.app.LoadedApk$ReceiverDispatcher$Args.lambda$getRunnable$0$LoadedApk$ReceiverDispatcher$Args -> org.libsdl.app.HIDDeviceManager$1.onReceive -> handleUsbDeviceAttached -> connectHIDDeviceUSB -> getSerialNumber -> android.hardware.usb.UsbDevice.getSerialNumber -> android.hardware.usb.IUsbSerialReader$Stub.onTransact -> com.android.server.usb.UsbSerialReader.getSerial -> UsbUserPermissionManager.checkPermission -> hasPermission -> isCameraDevicePresent
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
We're still seeing this frequently when unregistering PlayStation controller sensors. We don't know what else is modifying the sensor list, but if we end up getting this exception we'll retry after a short sleep.
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.
This reverts commit 91173aba25.
As @icculus mentioned: I'd rather we not get into the business of making fixes by tweaking values in the Preseed files. Were there no preseed file, CMake would correctly record that the vfork function exists, so if we're really hitting the vfork() codepath on DOS, we should stop that in either CMakeLists.txt itself, or in src/process.
