Built-in SDL HIDAPI/XInput mappings are being overridden

This is a continuation of the discussion from 9219d19540747efca0019da69064fc65cf000db0, https://github.com/moonlight-stream/moonlight-qt/issues/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 9219d19540747efca0019da69064fc65cf000db0. 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 a ShanWan PS3/PC Wired GamePad when 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 6800 or 78XX and 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.

[cgutman]

Unless you’re talking about something else, I think I removed those in #480 (line 848 and 850)

[cgutman]

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:

00:00:27 - SDL Info (0): Gamepad 0 (player 0) is: PS4 Controller (haptic capabilities: 0x10000) (mapping: 030000004c050000cc09000000016800 -> 030000004c050000cc09000000016800,PS4 Controller,a:b1,b:b2,back:b8,dpdown:h0.4,dpleft:h0.8,dpright:h0.2,dpup:h0.1,guide:b12,leftshoulder:b4,leftstick:b10,lefttrigger:a3,leftx:a0,lefty:a1,rightshoulder:b5,rightstick:b11,righttrigger:a4,rightx:a2,righty:a5,start:b9,x:b0,y:b3,platform:Windows,)

and with it removed from gamecontrollerdb.txt, the built-in SDL mapping prevails:

00:00:09 - SDL Info (0): Gamepad 0 (player 0) is: PS4 Controller (haptic capabilities: 0x10000) (mapping: 030000004c050000cc09000000016800 -> 030000004c050000cc09000000016800,*,a:b0,b:b1,back:b4,dpdown:b12,dpleft:b13,dpright:b14,dpup:b11,guide:b5,leftshoulder:b9,leftstick:b7,lefttrigger:a4,leftx:a0,lefty:a1,rightshoulder:b10,rightstick:b8,righttrigger:a5,rightx:a2,righty:a3,start:b6,x:b2,y:b3,touchpad:b15,)

The * for the name field gives away that it’s a generic mapping. The controller works correctly with the erroneous mapping removed.