alexrice999
I have a knock off wired xbox 360 controller called afterglow for xbox 360 controller. Despite there being a few afterglow controllers in the controller mapping the guid of my controller seems to map to Generic Xbox pad. This binding is as follows:
```
"030000006f0e00001304000000010000,Generic X-Box pad,a:b0,b:b1,back:b6,dpdown:h0.4,dpleft:h0.8,dpright:h0.2,dpup:h0.1,guide:b8,leftshoulder:b4,leftstick:a0,lefttrigger:a2,leftx:a0,lefty:a1,rightshoulder:b5,rightstick:a3,righttrigger:a5,rightx:a3,righty:a4,start:b7,x:b2,y:b3,",
```
When running openmw I have a strange issue that the joysticks work for up and down movements but not for side to side. I managed to track this down to the side to side events being classified as joystick events instead of gamepad events.
I believe this is due to both "leftstick" and "leftx" being bound to "a0" which seems odd to me. If I change openmw's mappings to remove these the controller works as expected. I was hoping someone who knows a lot more than me (as I have only been exploring this today trying to fix my controller) would know what is happening
daniel.c.sinclair
Hi, this patch breaks dpad/hat input on my PS4 controller. The attached patch restores functionality. Calling SDL_PrivateJoystickHat() at the end of BSD_JoystickUpdate was setting the hat state to zero on every kind of input, instead of just the HUG_DPAD events.
It causes the HIDAPI devices to always be opened on enumeration, which causes crashes in the Windows drivers when multiple applications are reading and writing at the same time. We can revisit this after 2.0.10 release.
The Nintendo USB GameCube Adapter has two USB connectors. Black for data
and grey for additional power for rumble. The Wii U and other software
require both cables to use rumble. The rumble is weaker without the
second USB cable. Other than that I don't know if there is any negative
side affects from using rumble with only one cable.
Also implemented SDL_JoystickGetDevicePlayerIndex() on iOS and tvOS, and added support for reading the new menu button state available in iOS and tvOS 13.
Matteo Beniamino
Pressing a trigger button on a Steam Controller causes a segmentation fault both with stable version and latest mercurial head on Linux. I'm using the recent hid_steam kernel module with lizard_mode disabled (that is no keyboard/mouse emulation). I suspect this is what's happening: the driver exposes two hats. The two hats have indices 0 and 2. Inside linux/SDL_sysjoystick.c two hats are allocated in allocate_hatdata for joystick->hwdata->hats. In HandleHat function the hat parameter (that can be 2) is directly used as the index of the array that only has two elements, causing an out of bounds access. SDL is not expecting to have "holes" between hats indices.
The index 2 is calculated in HandleInputEvents() as (ABS_HAT2X - ABS_HAT0X) / 2 where ABS_HAT2X is the value associated to the hat inside the hid_steam module.
This device is a copy of the Xbox Controller S and currently the one most sold
when shopping for a 'new' Xbox gamepad on eBay and AliExpress.
Except for the quirky USB ID id behaves just like a normal Xbox controller (when
ignoring the subpar build quality)
This device is a copy of the Xbox Controller S and currently the one most sold
when shopping for a 'new' Xbox gamepad on eBay and AliExpress.
Except for the quirky USB ID id behaves just like a normal Xbox controller (when
ignoring the subpar build quality)
Noam Preil
In src/joystick/linux/SDL_sysjoystick.c:
The ConfigJoystick function's axes detection starts with a for loop using an index i for Linux's axes names. When i gets to ABS_HAT0X, it's set to ABS_HAT3Y and a continue statement appears, to skip the hats. This makes sense, as SDL handles hats separately from axes.
However, in PollAllValues, *two* indices are used: a and b. Both start out the same, and remain so until the hats are reached. At that point, a becomes identical to the i from ConfigJoystick's loop, but b is equal to a - (ABS_HAT3Y - ABS_HAT0X), or a - 8.
While all the joystick->hwdata->abs_* structures in ConfigJoystick used i - which would here be a - as both the index and the ioctl argument, PollAllValues uses b for the structure index and a as the ioctl argument.
It would appear, however, that no joystick HAS such axes, and that the b index is entirely unnecessary.
I tested three separate joysticks, and while that was far from a complete listing, I was unable to find a joystick with an axis above 0x08.
Dexter Friedman
When using a Dualshock 4 controller (model numbers CUH-ZCT1U and CUH-ZCT2U), pressing anywhere on the center touchpad does not send an SDL_JOYBUTTONDOWN event. I have verified this with testjoystick:
Repro steps:
1. Plug in a DS4 over USB
2. Compile testjoystick and run: testjoystick.exe 0
3. Press and hold the touchpad. Observe that no lime green box appears
Expected behavior:
A lime green box appears while the touchpad is pressed.
Notes:
I've attached a patch here that works on my PC and produces the expected behavior in testjoystick, for both DS4 model numbers I listed earlier.
If I understand correctly, by exposing this as a joystick button, the gamecontroller API mapping can be modified with a change to gamecontrollerdb.txt in the future.
The Nintendo USB GameCube adapter has four controller ports. Return
the port number as 0 to 3 from SDL_JoystickGetPlayerIndex() and
SDL_JoystickGetDevicePlayerIndex().
Thomas Frohwein
Hi,
If a gamepad lists the Dpad as 4 buttons (Dpad Up,Down, Left, Right) like with the Xbox 360 gamepad / XInput report descriptor used by OpenBSD (https://github.com/openbsd/src/blob/master/sys/dev/usb/uhid_rdesc.h#L184), this is not recognized by the SDL BSD backend and no hat or any other listing for the D-pad exists, e.g. in sdl2-jstest (https://gitlab.com/sdl-jstest/sdl-jstest).
The attached diff fixes this and makes the D-pad on my Xbox 360 and Logitech F310 controllers usable. It adds a hat to nhats when usage HUG_DPAD_UP is found, reads the state of the D-pad buttons into array dpad[], and turns the value of dpad[] into an SDL hat direction (dpad_to_sdl()).
Tested and works with Xbox 360 controller and Logitech F310 in XInput mode. Software-side tested with sdl2-jstest and Owlboy where this worked without problems or regressions.
I don't know if this would be applicable to other *BSDs and don't have an install to test it with, therefore wrapped it in __OpenBSD__ ifdefs.
Thanks,
thfr
Note that a single USB device is responsible for all 4 joysticks, so a large
rewrite of the DeviceDriver functions was necessary to allow a single device to
produce multiple joysticks.
Daniel Gibson
Even though my game (dhewm3) doesn't use SDL_INIT_JOYSTICK, SDL_PumpEvent() calls SDL_JoystickUpdate() which ends up calling hid_enumerate() every three seconds, and sometimes on my Win7 box hid_enumerate() takes about 5 seconds, which causes the whole game to freeze for that time.
maxxus
The Dualshock 3's motion sensors don't seem to be reported by the call to EVIOCGBIT but they still send EV_ABS events. Because they're not reported by EVIOCGBIT they're not assigned a proper axis ids and the default of 0 is used, which is the valid id for the left analog sticks left/right axis.
Adds controller bindings to support the "Xbox One Wireless Controller
(Model 1708)" on Linux. The Model 1708 was released in 2016 alongside the
Xbox One S. It is the current model being sold by Microsoft as of writing.
(October 22, 2018)
src/vendor/SDL2/src/joystick/bsd/SDL_sysjoystick.c:353:5: error:
ISO C90 forbids mixed declarations and code [-Werror=declaration-after-statement]
reported by 'bch' at https://discourse.libsdl.org/t/25231
Include guards in most changed files were missing, I added them keeping
the same style as other SDL files. In some cases I moved the include
guards around to be the first thing the header has to take advantage of
any possible improvements compiler may have for inclusion guards.
If we run into problems where these events aren't dispatched (initialized on a different thread than the main thread?) we may need to create a separate thread to handle device notifications like we do with the windows joystick subsystem.
The code is now reliant on SDL_PrivateJoystickAdded() and SDL_PrivateJoystickRemoved() being called correctly when devices are added or removed on Windows
src/joystick/hidapi/SDL_hidapijoystick.c: In function 'HIDAPI_InitializeDiscovery':
src/joystick/hidapi/SDL_hidapijoystick.c:281: error: 'true' undeclared (first use in this function)
src/joystick/hidapi/SDL_hidapijoystick.c:281: error: (Each undeclared identifier is reported only once
src/joystick/hidapi/SDL_hidapijoystick.c:281: error: for each function it appears in.)
src/joystick/hidapi/SDL_hidapijoystick.c: In function 'HIDAPI_UpdateDiscovery':
src/joystick/hidapi/SDL_hidapijoystick.c:339: error: 'true' undeclared (first use in this function)
src/joystick/hidapi/SDL_hidapijoystick.c:341: error: ISO C90 forbids mixed declarations and code
These are entirely untested
Several USB ids refer to multiple packaged products. In those cases I tried to use the most common name, or a general name (e.g. PS3 Controller), or a completely generic name (e.g. USB gamepad) if it wasn't clear what type of controller it was.
Patches welcome!
ayer.3d
I have a DualShock 4 v2 controller with a GUID that's not in the database. There is an existing GUID that is almost identical, with the only difference that I can tell being the reported version string (mine being 8001, database is 8100).
Existing GUID: 050000004c050000cc09000000810000
New GUID: 050000004c050000cc09000001800000
When connected via USB, the GUID matches an existing entry: 030000004c050000cc09000011810000
Alexander Orefkov
In src\joystick\android\SDL_sysjoystick.c in SDL_SYS_JoystickDetect when SDL_GetTicks return number grater 2147483648 (after 24.85 days uptime) SDL_TICKS_PASSED(SDL_GetTicks(), timeout) return FALSE and Android_JNI_PollInputDevices is never calling.
And in JoystickByDeviceId - when search for newly added joystic - after SDL_SYS_JoystickDetect item not reinitilized, and always stay NULL, cause return NULL instead of added joystick.
Manuel
I would like this small patch merged that adds support for my GreenAsia Inc. PSX to USB converter, so SDL_IsGameController() returns true when using this adaptor.
It's interesting because PSX/PS2 controllers connected using this model won't be detected as gamecontrollers otherwise, only as joysticks.
benjamin.feng
Probable underlying cause: https://bugzilla.libsdl.org/show_bug.cgi?id=3124#c5
"If you download and build the HID Calibrator sample you can see that these are totally legitimate HID devices (except for inverting the Y-axis of joysticks, which is contrary to the HID specification but does make them more compatible with games compiled expecting XBOX controllers)."
David Brady
When I attempted to make a mapping file for Android gamepads, I quickly discovered that most of the ones that I have here show up as the same device (Broadcom Bluetooth HID), meaning that it was impossible to make mappings on Android, since every device looked the same.
This patch will check for the existence of the getDescriptor function added in Jelly Bean, and use it if it's there. The Android Dashboard says that the majority of Android phones should support this function, and doing it this way will not force us to bump up our API version.
Jimb Esser
Note: This is using DirectInput, I have to disable XInput as that causes all but the first 4 controllers to be completely ignored by SDL (I can find no way to reconcile XInput devices with DirectInput devices, otherwise I would make a patch that accepts the fifth and later controllers with DirectInput...). XInput does not seem to have the problem below, only DirectInput.
I plug in 3 identical wireless Xbox 360 controllers, call them J1, J2, J3. Direct Input shows them as having GUIDs G1, G2, G3. I unplug J1, then J2 and J3 show up as having GUIDs G1 and G2! Not so "unique"... I start my SDL app when just J2 and J3 are plugged in, and open J2 and J3. Then I plug in a new controller, SDL sees that now G3 exists, assigns that a new SDL joystick instance ID, which I request to be opened, but G3 at this point is J3, which I already had opened! So I end up with two instances of J3 opened, and none of J1. "Re-"opening G1 would get the actual handle to the newly attached controller, but there's no current way to know this. This is clearly a bug or poor design in DirectInput or my wireless receiver drivers, but is a showstopping bug for my 8-20 player games (as soon as any one controller runs out of battery or goes to sleep and gets turned back on, suddenly things are busted requiring a restart (or, at least, a reinitialization of all controllers - the game can't go on)).
The solution I found is to use HID paths instead of GUIDs to uniquely identify joysticks. GUIDs are still needed to open a controller, however I have added code to re-find the GUIDs for all joysticks whenever a new joystick is attached or removed. This does now require opening of all joysticks (instead of just enumerating them), though if your app, like mine, is opening all of them anyway so that any can press a button to join, that doesn't change much (although perhaps they joysticks should be kept open in this case, instead of closed and re-opened). If your app only ever opens one joystick, this will do more work at startup than it did previously.
Edward Rudd
Device: Logitech Rumble Gamepad F510 in Xinput mode.
Upon opening the joystick the values of the axes are queried via PollAllValues are not actually set on the device all the time.
This can easily be seen in the testjoystick or testgamecontroller test programs,as the testjoystick shows all axes in the center until one 'tickles' the triggers., and the testgamecontroller will show the triggers as 'on' until on 'tickles' the triggers.
Upon further research the culprit is the SDL_HINT_JOYSTICK_ALLOW_BACKGROUND_EVENTS hint. In the default value events are ignored until there is an active window, Thus in cases where the joystick system is initialized and controllers opened before the initial window is created & focuses, the initial values will be incorrect.
Here is my current workaround in the game I'm working on porting..
SDL_SetHint(SDL_HINT_JOYSTICK_ALLOW_BACKGROUND_EVENTS, "1");
SDL_GameController* gamepad = SDL_GameControllerOpen(index);
SDL_SetHint(SDL_HINT_JOYSTICK_ALLOW_BACKGROUND_EVENTS, "0");
Also updates the naming of these Xbox Wireless Controllers connected via USB (and thus the third-party Xbox Controller Driver) to match.
The Xbox Wireless Controller entries are now listed, in order, via USB, bia Bluetooh (with older firmware) and via Bluetooth (with firmware 3.1.1221.0).
Firmware revision 3.1.1221.0 changes the mapping of the Xbox One S
controller in Bluetooth mode. Aside from changing the layout of
other buttons, this revision also changes the triggers to act as
Accelerator and Brake axes from the simulation controls page.
The Darwin sysjoystick code didn't previously map anything at these
axes, making it impossible to detect input on these two buttons.
white.magic
The logic which decides if a device enumerated via the direct input system in the function EnumJoysticksCallback in SDL_dinputjoystick.c is processed is discarding valid joystick devices due to the assumption that devices of the type DI8DEVTYPE_SUPPLEMENTAL are not valid devices.
This change was added with 2.0.4 with this commit http://hg.libsdl.org/SDL/rev/1b9d40126645 that is linked to this bug report https://bugzilla.libsdl.org/show_bug.cgi?id=2460 which indicates that in that case devices of the type DI8DEVTYPE_SUPPLEMENTAL were not desirable as they caused a singular device to emit multiple "device added" events.
Since then there appear to have been a few fixes to handle devices that fall into various other classes in the following two commits:
http://hg.libsdl.org/SDL/rev/10ffb4787d7a and http://hg.libsdl.org/SDL/rev/6a2bbac05728
Two devices I have reports of failing to be listed when the DI8DEVTYPE_SUPPLEMENTAL type is excluded are ECS Gametric Throttle and Thrustmaster MFD Cougar.
Sam Lantinga
I verified that the OUYA controller shows up as a single device with this change, so I've reverted the change to ignore supplemental devices, leaving framework in place to easily add devices that we want to ignore.
Fixed a case where partial trigger pull could be bound to another button
There is a fundamental problem not resolved by this commit:
Some controllers have axes (triggers, pedals, etc.) that don't start at zero, but we're guaranteed that if we get a value that it's correct. For these controllers, the current code works, where we take the first value we get and use that as the zero point and generate axis motion starting from that point on.
Other controllers have digital axes (D-pad) that assume a zero starting point, and the first value we get is the min or max axis value when the D-pad is moved. For these controllers, the current code thinks that the zero point is the axis value after the D-pad motion and this doesn't work.
My hypothesis is that the first class of devices is more common and that we should solve for that, and add an exception to SDL_JoystickAxesCenteredAtZero() as needed for the second class of devices.
felix
Compiling even a simple SDL2 'hello world' program with gcc -Wstrict-prototypes (GCC 6.2.1) results in warnings like:
/usr/include/SDL2/SDL_gamecontroller.h:143:1: attention : function declaration isn't a prototype [-Wstrict-prototypes]
extern DECLSPEC int SDLCALL SDL_GameControllerNumMappings();
^~~~~~
It seems there is a missing 'void' between the parentheses.
These fixes are lumped into two categories:
1. add new file, SDL_dataqueue.c, to UWP/WinRT build-inputs (via MSVC project
files)
2. implement a temporary, hack-fix for a build error in SDL_xinputjoystick.c.
Win32's Raw Input APIs are, unfortunately, not available for use in UWP/WinRT
APIs. There does appear to be a replacement API, available in the
Windows.Devices.HumanInterfaceDevice namespace.
This fix should be sufficient to get SDL compiling again, without affecting
Win32 builds, however using the UWP/WinRT API (in UWP/WinRT builds) would
almost certainly be better (for UWP/WinRT builds).
TODO: research Windows.Devices.HumanInterfaceDevice, and use that if and as
appropriate.
x414e54
It is a bit of a pain to update the library or rely on whatever version the user has on their computer for default mappings.
So providing an easily updatable text file via SDL_GameControllerAddMappingsFromFile is still currently the most viable way. However using this replaces all mappings provided by the SDL_HINT_GAMECONTROLLERCONFIG environment variable which may have come from the user's custom Steam mapping.
There should be an easy way for games to supply extra game controller mappings to fill in the differences between SDL versions without it clobbering the SDL_HINT_GAMECONTROLLERCONFIG environment variable.
Internally the mappings could use a priority system and if the priority is lower then it will not overwrite the mappings.
For now it just assumes SDL_HINT_GAMECONTROLLERCONFIG is the highest priority, the default hardcoded are the lowest and anything set via the API is medium.
ny00
Unfortunately, simply checking the return codes of "onNativePadDown/Up" as previously done has its own issue:
If an SDL joystick is connected *and* opened, then a proper KeyEvent, say with keycode KEYCODE_BUTTON_1, should lead to an SDL joystick button event as expected.
If, however, the joystick was *not* opened, then "onNativePadDown/Up" will return a negative value, so before the commit from bug 3426, you could unexpectedly get a keyboard event. (In practice, you'll just get a log message, since KEYCODE_BUTTON_1 has no mapping to a proper SDL_ScanCode value, but it's still an problem).
What should still be done, though, is checking the key code itself. We do have the KeyEvent.isGamepadButton method, but according my test, it returns "true" exactly (and only) for the KEYCODE_BUTTON* values, and not for KEYCODE_DPAD* or any other key code.
Here is a possible solution:
- Do check the return codes of "onNativePadDown/Up" as previously done.
- In addition, in "Android_OnPadDown/Up" from src/joystick/android/SDL_sysjoystick.c, 0 should *always* be returned in case the key code can be translated to an SDL_joystick button; Even if no matching joystick can be found.
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.
Ryochan7
I have been using SDL 2 for a little project that I have been developing for a while. My project is called antimicro and it takes gamepad input and then translates gamepad events into keyboard and mouse events. SDL is used to read the input from an XInput gamepad and it works great for the most part. However, there is one glaring problem that I have encountered.
When a device is unplugged and SDL sends the centered value release events for all axes, buttons, and hats, SDL does not use the proper centered value for the triggers. It pushes an SDL_JOYAXISMOTION event onto the queue with a value of 0 for all axes. That value is converted to around 16,000 for a Game Controller. That value is incorrect for triggers and, in my program, that causes any bindings that are assigned to the triggers to get activated. With most profiles, that will typically mean that a mouse right click and left click will be activated before the device is finally seen as removed and then those bindings are released by antimicro.
Machiel van Hooren
In SDL_dxjoystick.c line 349 there is a constant c_dfDIJoystick2.
However, this constant is aparently also defined in dinput8.lib.
I encountered a linking error when statically linking to SDL:
SDL2_static.lib(SDL_dxjoystick.obj) : error LNK2005: _c_dfDIJoystick2 already defined in dinput8.lib
My application is also linking to dinput8.lib because we rolled our own joystick input and are not using the joystick functionality from SDL.
ny00
On Android, the keycodes KEYCODE_BUTTON_1..16 (actual values 188-203) are translated to SDL_Joystick buttons no. 20-35. These are currently ignored in SDL_gamecontroller.c.
The attached patch fixes this, by increasing k_nMaxReverseEntries from 20 to another arbitrary bound of 48.
Side-note: Maybe some log should be emitted in case of going over any such bound?
SFC30 controller: http://www.8bitdo.com/sfc30/
The SFC30 controller can present itself in a variety of modes and it offers up
different names in each. This patch captures data for three modes (one USB and
two Bluetooth) on three platforms (Mac OS X, Windows, Linux).
However, USB mode on Linux and Windows is missing as the button events did not
make it through to SDL's controllermap tool on Fedora 24/Linux 4.5.5 nor Steam
Big Picture mode on Windows. The two Bluetooth modes were indistinguishable on
Windows. Two modes on OS X were indistinguishable.
There exists a similar controller called the SNES30 (And some others) that are
very likely identical except for the name, but I have not verified this yet so
haven't synthesized lines for those controllers until I can.
The Apple TV remote is currently exposed as a joystick with its touch surface treated as two axes. Key presses are also generated when its buttons and touch surface are used.
A new hint has been added to help deal with deciding whether to background the app when the remote's menu button is pressed: SDL_HINT_APPLE_TV_CONTROLLER_UI_EVENTS.
Author: James Zipperer <james.zipperer@synapse.com>
Date: Sun Aug 21 01:19:19 2016 -0700
bugfix for controller / joystick add / remove being in the event queue at the same time
The Windows 10 Anniversary Update (1607) breaks the method uses that SDL uses to
detect XInput devices. That is, on Windows 10 Anniversary Update, it is no longer
possible to query RAWINPUT for HID devices, and check for "IG_" in the device name.
Presumably, this will be fixed in the future.
This patch works around the issue by adding the Xbox One controller series to the
well-known device list.
This skips the more expensive RAWINPUT check for those devices, and causes them to
be detected as XInput devices once again.
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 returned value is currently not used by the caller. The instance id would
also not be needed on Java side and providing it just complicated the function.
Partially fixes Bugzilla #3234.
I don't know if any joysticks report those usages for any buttons in practice, but other prominent Mac gaming software exposes them, so we might as well too.
This change has also been tested as buildable + runnable on Win32 + MSVC 2015,
2013, 2012, and 2010. It may fix similar build errors (in XInput code) that
are appearing in MingW builds (on buildbot).
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().
Sam Lantinga
Sylvain Becker
Ozkan Sezer
Andrew Eikum
Cameron Gutman
Ryan C. Gordon
Zack Middleton
Benjamin Valentin
Cameron Gutman
Ethan Lee
Silent
Jimb Esser
Alex Szpakowski
Charlie Birks
Steven M. Vascellaro
Micha? Janiszewski
Patrice Mandin
Philipp Wiesemann
Jessica Stokes
Misty De Meo
David Ludwig
Jonathan Dowland
Mikkel Krautz
Eric Wing
Edward Rudd