Existing code is erroneous, because it adds or removes dependency's ref count based on number of InitSubSystem/QuitSubSystem calls, while ref count diff should depend on number of inited or quit dependents.
Recursive approach seems to be simplest solution that guarantees proper ref count.
Emscripten was using its own, private integer in order to allocate
new SDL_JoystickIDs. SDL keeps a similar integer for allocating
joystick-ids, one which is shared across multiple joystick backends.
SDL 2.0.13 introduces a new joystick-backend, a Virtual joystick
backend, which allows for software-driven joysticks, and which is
designed to sit alongside joystick-backends that provide access to
physical joysticks.
The Emscripten and the Virtual backends were, at times, getting
allocated the same SDL_JoystickIDs, if and when both backends were used
simultaneously. This could happen if, for example, an application
was using a virtual joystick in order to drive a touch-screen
based joystick, while also supporting physical joysticks through the
Emscripten backend.
When two joysticks end up with the same SDL_JoystickID, conflicts
can occur. For example, disconnecting a physical joystick with
the same SDL_JoystickID as a virtual one, can lead to the virtual
joystick being closed, inadvertently.
This fix makes the Emscripten backend use SDL's cross-joystick-backend
integer counter, which is shared among joystick backends, for allocating
new SDL_JoystickIDs, rather than a private, Emscripten-specific
counter.
Fixes https://github.com/libsdl-org/SDL/issues/3647
(cherry picked from commit 07cb7c10a15b95387431bcb3a1ae77cfd432707b)
(This fix was originally from @themightyoarfish on GitHub. Thanks!)
Fixes#8428.
Reference PR #8431.
(cherry picked from commit c6d9fb1ad71462bc844c6ca41e2ac7fe7cec3883)
GetRawInputDeviceList() can return a different number of devices than was allocated.
Fixes https://github.com/libsdl-org/SDL/issues/2759
(cherry picked from commit b9784feb2467dbb4cdc2474aa78098cd4f0b1630)
This reverts commit e5a15f94e2f1a8fbbffb25ea9932cda9679a68fd.
It turns out removing this check allows mice like the ROG PUGIO II to show up as game controllers. We need to find a different way to differentiate between gaming mice and pedals.
Since these mice show up as controllers, and potentially causing games to use them instead of real controllers, we'll go ahead revert this change for now.
Reopens https://github.com/libsdl-org/SDL/issues/8227
(cherry picked from commit ad0af488837e44cbea0f0eab3b2f73b50a74bff4)
If the relative protocol is unsupported, this will always be null and the destroy function won't be called.
(cherry picked from commit 0e87b71d08c75af8c4b02808038825d3b16bf854)
This reverts commit 642504bc5993a6acd4d9c1d4c1314c6b1cf6e4e1.
We have SDL_HINT_JOYSTICK_ROG_CHAKRAM to ignore or allow the ROG Chakram X mouse to be used as a joystick.
Fixes https://github.com/libsdl-org/SDL/issues/8227
(cherry picked from commit e5a15f94e2f1a8fbbffb25ea9932cda9679a68fd)
HIDAPI joystick drivers may call HIDAPI_JoystickDisconnected() in their
UpdateDevice() function during HIDAPI_JoystickOpen(). If they do this
today, the opened joystick will end up partially initialized (no name,
path, mapping GUID, etc.) because HIDAPI_GetDeviceByIndex() will no
longer be able to find the SDL_HIDAPI_Device for the removed joystick.
Worse still, joystick->hwdata->device becomes a dangling freed pointer
the next time HIDAPI_UpdateDeviceList() is called. This leads to a UAF
when the application or SDL calls SDL_JoystickClose() on this joystick.
Fix all this by checking if the device no longer has any associated
joysticks after calling UpdateDevice() and failing the open call if so.
(cherry picked from commit 435e7ce663b7e568086c5dc0fb1bb889e41a3ed1)
This specifically fixes a crash in X11_WarpMouseInternal if XInput2 was
missing at runtime, but also cleans up a few other existing checks.
Fixes#8378.
(cherry picked from commit 82f54af6177f3d50be1db42a528027ada6ea0a20)
Wayland does not allow warping the mouse pointer, thus these tests are unreliable and should be skipped.
(cherry picked from commit 9111c5e17843155019d444159a394ee480394056)
When initializing the Wayland driver, check if the application is being started in, or trying to connect to, a Wayland session and skip to another driver if not. If neither WAYLAND_DISPLAY nor XDG_SESSION_TYPE are set, try to start anyway, and if the Wayland library is missing or no Wayland sessions are started, initialization will fail later in the process as it previously did.
This fixes the case where a Wayland session is running on a different VT, but an application wishes to run via KMSDRM on the current VT.
(cherry picked from commit 836927edf8da93ca2d3c8dddf7653113da65ce65)
