Amazon's store link was still "http://" instead of "https://", and since they
don't have the physical CD in stock anymore (and probably won't ever again), I
added a link to the album on Amazon Music, for those that want to access it.
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
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
