Built-in SDL HIDAPI/XInput mappings are being overridden #478
Comments
|
sounds good to me.
significantly less rare than you'd think, unfortunately
there are a few exceptions but we generally intend to omit these anyway |
|
As luck would have it, I pulled my PS4 controller out of my drawer and it happens to be one of the affected ones. When I have the broken mapping in place, Moonlight prints: and with it removed from gamecontrollerdb.txt, the built-in SDL mapping prevails: The |
|
Should we do something about this in controllermap as well? We should probably detect XInput/HIDAPI devices and point out that they're already mapped, but at the same time why are we having to make mappings at all if the joystick drivers are supposed to do that in the first place... presumably someone hit a bug and these busted mappings fixed the issue. |
I think a warning at least would be a good idea !
Good question, overzealousness possibly? Once one understands maps are for normalizing pads it may be motivation to throw in whatever device is at hand even if the default mapping works fine. The only potential problem besides a bad name (eg. Shanwan clone) are those that fail to match a subset of the default mapping ( Most of the above-mentioned maps in the DB already do match, and for those that don't we need a better binary to recommend with a more recent SDL to test properly as this was presumably the problem that led to the PS4 map that started this discussion. |
|
Every one of the For Several of the
|
- Mappings for XInput devices with a non-gamepad subtype - Mappings present in upstream SDL Fixes mdqinc#478
|
Feel free to remove the DualSense mappings in #480 as well, those maps are mine and the newer driver in SDL has them covered. |
|
Unless you're talking about something else, I think I removed those in #480 (line 848 and 850) |
|
Gonna reopen this for posterity until we have a better up-to-date mapping binary to distribute as per #476. The 'issue' is tentatively solved but we need to keep an eye for incoming PRs of similar format. |
|
can we pinpoint when this started in SDL2? do we have an issue to report over on their github? same controller different systems: ubuntu 18.04 x86_64
raspberry pi debian 11
|
this is working as intended — the first mapping is presumably benefitting from the hid-nintendo kernel driver and so is being handled in SDL with HIDAPI, while the pi running debian doesn’t have the driver and so will benefit from a db mapping. |
interesting answer to this in #702: if a user wants to configure their own device-specific remapping of something covered by a joystick driver through this interface (not the intended use case, but may work nonetheless) additionally i've noticed a number of projects consuming this data directly for their own dinput/udev/etc handling, even if they do not implement SDL itself. depending on how GUID parsing and matching is implemented by these, mappings with the driver hint suffix would normally not apply, but using an SDL-based mapping tool in an (untested) attempt to "fix" this will produce the SDL GUID |
This is a continuation of the discussion from 9219d19, moonlight-stream/moonlight-qt#620, and #477. I took a look at the SDL code to figure out what's going on.
Some of the mapping GUIDs have special suffixes that mean they are associated with a particular API:
https://github.com/libsdl-org/SDL/blob/c59d4dcd38c382a1e9b69b053756f1139a861574/src/joystick/windows/SDL_xinputjoystick.c#L279-L280
https://github.com/libsdl-org/SDL/blob/b63cb822bf02ffa53e7a25755ff4606af0417389/src/joystick/hidapi/SDL_hidapijoystick.c#L918-L920
The trouble is that these special APIs almost always have an existing mapping built into SDL like this one for HIDAPI. Allowing mappings for these special APIs here creates the possibility for error like we've seen here.
For HIDAPI joysticks, this suffix is
6800(0x68 = 'h') which is exactly what the suffix of the broken mapping is from 9219d19. The mistake there seems to be that they assumed it would be equivalent to the non-HIDAPI mapping for a PS4 Controller. This is not the case, since HIDAPI does not necessarily expose all axes and buttons in the same order that DirectInput does.There is a similar case for XInput joysticks, where
78XX(0x78 = 'x', XX is the XInput subtype) is the magic suffix. Due to the unnecessary mapping in here, an ordinary Xbox 360 controller shows up as aShanWan PS3/PC Wired GamePadwhen using the XInput API. We should definitely remove this mapping, because it's unnecessary and causes the much more common official Microsoft Xbox 360 controller to be mistaken for some knock-off PS3 controller (though at least the mapping is correct).Due to these issues, I propose we remove all existing mappings where the last 2 bytes are
6800or78XXand closely scrutinize any attempts to add more. Mappings for these special controllers should only be necessary in the extremely rare case of a third-party Xbox/PlayStation/Nintendo gamepad that doesn't behave like the standard ones or very specialized hardware like a dance pad, guitar, or something that isn't used like a "normal" controller.The text was updated successfully, but these errors were encountered: