Jan Bujak
I wrote a new driver for my gamepad on Linux. I'd like SDL to support it out-of-box, as currently it just treats it as a generic joystick instead of a gamepad. From what I can see the only way to do that is to either 1) pick one of the already supported controllers' PID, VID and button layouts and have my driver send that (effectively lying that it's something else), or 2) submit a preconfigured, hardcoded mapping to SDL.
Both of those, in my opinion, are silly when we already have the Linux Gamepad Specification which standarizes this:
https://www.kernel.org/doc/html/v4.15/input/gamepad.html
Unfortunately SDL doesn't make use of it currently. So I've took it upon myself to add it; patch is in the attachments.
Basically what the patch does is that if SDL finds no built-it controller mappings for a given joystick it then asks the joystick backend to autodetect it, and that uses the relevant evdev bits to figure out which button/axis is which. (See the specs for more details.)
With this patch applied my own driver for my controller works out-of-box with SDL with no extra configuration and is correctly recognized as a gamepad; this is also going to be the case for any other driver which follows the Linux Gamepad Specification.
Added the functions SDL_JoystickFromPlayerIndex(), SDL_JoystickSetPlayerIndex(), SDL_GameControllerFromPlayerIndex(), and SDL_GameControllerSetPlayerIndex()
The code is now reliant on SDL_PrivateJoystickAdded() and SDL_PrivateJoystickRemoved() being called correctly when devices are added or removed on Windows
Jan Klass
Not sure if this is limited to the joystick subsystem,
but I created a minimal program for reproducibility,
which is attached.
The issue occurs with my gamepad Razer Onza (an xbox-style gamepad) plugged in.
On initialization, the gamepad is being recognized.
After quitting the subsystem, the poll will receive the joystick added event,
which it instantly handles itself, calling SDL_SYS_JoystickDetect again,
which this time calls IDirectInput8_EnumDevices with dinput = NULL (after it was released on quit).
This seems to lead to an access violation within said function, which I have no source for.
This allows us to set an explicit stack size (overriding the system default
and the global hint an app might have set), and remove all the macro salsa
for dealing with _beginthreadex and such, as internal threads always set those
to NULL anyhow.
I've taken some guesses on reasonable (and tiny!) stack sizes for our
internal threads, but some of these might turn out to be too small in
practice and need an increase. Most of them are simple functions, though.
The internal function SDL_EGL_LoadLibrary() did not delete and remove a mostly
uninitialized data structure if loading the library first failed. A later try to
use EGL then skipped initialization and assumed it was previously successful
because the data structure now already existed. This led to at least one crash
in the internal function SDL_EGL_ChooseConfig() because a NULL pointer was
dereferenced to make a call to eglBindAPI().
