A number of third party Xbox controllers are not supported by macOS, but work with libusb and the SDL HIDAPI driver.
(cherry picked from commit 18fc4d931a)
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.
(cherry picked from commit 6136358840)
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.
(cherry picked from commit 157c839139)
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
(cherry picked from commit 42fc082b5e)
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.
(cherry picked from commit 75270a4264)
The experimental Steam Linux Runtime 3.0 (arm64) container is being
phased out, so games that want native arm64 binaries should upgrade to
Steam Linux Runtime 4.0.
steamrt/tasks#1032
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit d834351d69)
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.
(cherry picked from commit 687a59f277)
