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
(cherry picked from commit 2442c85cb8)
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.
(cherry picked from commit 45b01d16b1)
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)
(cherry picked from commit 52146cf067)
Allows users to overwrite the number of haptic axes defined for a given
joystick. Also supports a "wildcard" VID:PID of 0xFFFF/0xFFFF
(cherry picked from commit 0809be4ec5)
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
(cherry picked from commit 24693ac285)
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
(cherry picked from commit 5925c27efb)
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.
Apply the supplied xdg-toplevel bounds to resizable windows during initial mapping. Libdecor functionality will have to be added separately, as the functionality needs to be added to the library first.
Our understanding of what's going on here might be incorrect, but it seems
like we're getting this callback at a point where we shouldn't be able to,
with a device we've already closed.
If we're on the wrong track, this code should still be harmless; it just
verifies a device is still in the open list before dereferencing it.
Reference Issue #10432.
