On newer systems, the trick isn't necessary, and if you do it, if the user is
moving the mouse when launching the app, it'll show a hidden Dock.
Fixes#10340.
(manually backported from SDL3 from commit 279dabfc96)
SDL_PrivateJoystickAdded was called before setting the InstanceId in the adapters ctx->joysticks array. This would eventually broadcast the SDL_EVENT_JOYSTICK_ADDED event with the new InstanceId, if your program listens for the added events and opens joysticks at that point it would always fail because there would be no matching InstanceId in the ctx->joysticks array.
(cherry picked from commit afd1e51023)
The SIGILL handler is not very reliable and can cause crashes.
Linux provides the CPU's AltiVec support status in getauxval.
(cherry picked from commit 7490471796)
Unregistering the input report callback marks the device as disconnected, so IOHIDDeviceClose() would never be called if the device wasn't already disconnected when hid_close() was called.
Fixes https://github.com/libsdl-org/SDL/issues/12255
It looks like both macOS (15.1.1) and SDL are trying to talk to the controller at the same time, which can cause interleaved replies or even locking up the controller. Waiting a bit before talking to the controller seems to take care of this.
On Windows 11, apparently HidD_GetManufacturerString() and HidD_GetProductString() can return TRUE without actually filling in any string data.
Fixes https://github.com/libsdl-org/SDL/issues/12566
(cherry picked from commit 4fc9509ab7)
When the flushing is not able to keep up with the audio stream coming in,
it will end up flushing forever and block API clients from getting any audio.
Fixes#9706
Merged upstream fix for macOS:
cdc473dfe4
In one of the early versions of macOS, when you try to close the device
with IOHIDDeviceClose() that is being physically disconnected.
Starting with some version of macOS, this crash bug was fixed,
and starting with macSO 10.15 the opposite effect took place:
in some environments crash happens if IOHIDDeviceClose() is _not_ called.
This patch is to keep a workaround for old versions of macOS,
and don't have a leak in new/tested environments.
Fixes https://github.com/libsdl-org/SDL/issues/12255
Newer versions of Proton properly pass through the Steam virtual gamepad VID/PID, but older Proton (9.x and older) don't, so we have to rely on Steam and Proton hiding controllers we shouldn't have access to.
Fixes https://github.com/libsdl-org/SDL/issues/12106
Sometimes we'll get a Windows.Gaming.Input callback before the raw input device is even in the list, so try some other methods to better detect XInput devices.
Provious code wrongly assumed that direction is not an important part
of conditional effect. Moreover, if there's need to hardcode polar
direction, the default should be 0x4000 (north).
For one axis affects, a direction of 0 means complete lack of force, if
a FFB-enabled device takes direction into force calculation. A sine function
graph can be used to represent the resulting forces where X is the input
direction and Y is the force multiplier (360 degrees equals to 1).
This fixes conditional effect playback on Moza Racing devices, which do
not ignore direction field.
