If SDL_HINT_OPENGL_ES_DRIVER is enabled and a GLES context is requested,
don't try to load the WGL/GLX library. Doing so may fail, because
SDL_HINT_OPENGL_LIBRARY may have been set to a custom libGLESv2 (e.g.
ANGLE). This effectively restores the SDL2 behavior.
Other video drivers shouldn't be affected, because they always use EGL
for GLES.
Incidentally, this patch also fixes a missing GL_GetEGLSurface callback
in the X11 fallback path.
The first approach had the drawback that it accumulated handles while raw input was paused, eventually crashing the application.
Now we'll keep reading raw events from the queue, we just won't deliver them to the application.
When emulating display modes or using display scaling, custom cursors need to be scaled, or they can appear too large or small relative to the window size.
Added vids for a variety of xbox 360 devices, mostly for linux use.
Corrected wheel vid and pid being flagged as unknown. Internally, when XUSB is building vid and pids for wireless devices, it assigns 0x02a1 for devices with subtype 1 and 0x02a2 for devices with subtype 2, which are wheels.
Some of these vids and pids do rely on the following patch being merged into the linux kernel, as I have overhauled how VID and PIDs are handled there for wireless devices.
https://patchwork.kernel.org/project/linux-input/patch/20260314075034.1488655-2-sanjay.govind9@gmail.com/
Also added some lists for guitar and drum devices, so we can set controller types correctly for those controllers.
Previously we would spin up and shut down a thread every time we changed raw input mode, which can take several ms. Now we'll just put the raw input thread to sleep when disabling raw input and wake it up when enabling raw input.
The floating state is only set after the first configuration event arrives, so size changes before the window was initially shown could be dropped. Use the flags instead.
When using the display scaling mode, scaled outputs would overlap, as the origins are in scaled points, while the width and height are in pixels. Use a simple algorithm to push the overlapping rectangles apart, so they do not overlap. This may end up leaving gaps in complex layouts (which are already somewhat mangled from mixing coordinate systems), but it works well enough in most cases.
Technically we only want to do this for controllers that are opened, but we don't have a way to match up controllers using other APIs with individual GCControllers.
Some compositors will send a configure event immediately after a scale event, however, this event can contain the old logical size, and should be ignored, or the window will incorrectly change size when moved between displays with differing scale factors.
Store the last requested logical size as the last configure size when resizing a floating window due to a scale change, so a configure event immediately following with the old size will be ignored.
This PR makes the GameInput joystick backend ignore non-gamepad controllers if DirectInput or XInput backends are enabled. This is done to prevent possible bugs and/or regressions.
This PR includes small improvements to the GameInput joystick backend:
- Device subtypes
- Compatibility with DirectInput joystick mappings (if the controller is not a gamepad, i.e. `GAMEINPUT_InternalIsGamepad()` returns `false`)
- Fallback to DirectInput/XInput for currently unsupported devices (force feedback ones and the ones that are neither gamepads nor controllers, I'm not sure if that's possible, but maybe racing wheels and other device subtypes would count?)
We are locked to version 1 of the ABI, so don't load what might be a symlink to a newer and incompatible version.
Platforms like OpenBSD that only have .so versions of libraries can add a special case here like Android in the future.
Fixes https://github.com/libsdl-org/SDL/issues/15172
Read capabilities when using xinput controllers via the libusb backend
This gives us access to the subtype on linux and macOS, and gives us a lot of data we can use for handling more detailed device types when I look into a unified api for exposing instrument data later.
PS4/5 controllers put device specific data into a specific region in the report, so we have to extract it separately.
No known guitars use the right stick on the guitar, so to keep things working similarly to PS3, i have opted to map whammy and tilt the same way as the PS3 rb guitars.
Updated testgdk to demonstrate correct handling of suspend/resume and the new Render APIs, and updated the docs to explain the correct usage of these GDK functions.
