Wireless Xbox 360 controller d-pad broken on Linux 6.17+

[turmoni]

Since updating my kernel to 6.17, the D-pad on my Xbox 360 controllers have been misaligned. I'm fairly sure this is related to the kernel changes mentioned in #13305 , so there is more context in there.

I currently have the following mapping:

Button pressed	Button reported
Up	Left
Right	Down
Down	Right
Left	Up

The linked PR references the following custom mapping:

SDL/src/joystick/SDL_gamepad.c

Lines 2256 to 2258 in ac0915b

	mapping = SDL_PrivateAddMappingForGUID(guid,
	"none,X360 Wireless Controller,a:b0,b:b1,back:b6,dpdown:b14,dpleft:b11,dpright:b12,dpup:b13,guide:b8,leftshoulder:b4,leftstick:b9,lefttrigger:a2,leftx:a0,lefty:a1,rightshoulder:b5,rightstick:b10,righttrigger:a5,rightx:a3,righty:a4,start:b7,x:b2,y:b3,",
	&existing, SDL_GAMEPAD_MAPPING_PRIORITY_DEFAULT);

Fixing the mapping in testcontroller gives me the following (modified to fit the same format):

none,X360 Wireless Controller,b0,b:b1,back:b6,dpdown:h0.4,dpleft:h0.8,dpright:h0.2,dpup:h0.1,guide:b8,leftshoulder:b4,leftstick:b9,lefttrigger:a2,leftx:a0,lefty:a1,rightshoulder:b5,rightstick:b10,righttrigger:a5,rightx:a3,righty:a4,start:b7,x:b2,y:b3,

Since the existing special case is specifically referencing the D-pad, I'm thinking it could be just made conditional on having an older version of the xpad module loaded, rather than updating the mapping. I'm currently struggling a bit with testing this, since even if I delete the #ifdef block entirely and do a fresh build of SDL, testcontroller still reports the (now-incorrect) mapping and I'm not sure where it's coming from.

I've now dug into this more and see that the mapping is in SDL_gamepad_db.h, which makes things a bit more complicated. I'm not sure how you'd go about allowing for different configurations based on different versions of the driver there; any ideas?

I'm happy to work on this myself (it feels pretty simple, and I'm the one who cares about it), but don't want to break things; I suppose the questions I have are:

• Is there an acceptable way in SDL, in this function, to get the version of a kernel module (or the kernel itself, I suppose)?
• Is there some reason why my freshly built SDL3 and testcontroller might still be picking up the mapping I deleted/changed from somewhere else? strace does seem to show that it is loading my SDL3 and not one provided by my distro.
• Given SDL_gamepad_db.h, is there actually a way to fix this without breaking users of older kernels?

I'm assuming this also needs to be fixed in SDL2, but it looks like it would be pretty much the same change in there.

Edit: updated with more things I discovered (which make this a more challenging prospect)

[turmoni]

Thinking about it, I suspect the way around this is either to make controllers using the old driver report the same buttons that controllers using the new driver do, or vice versa. I assume this is possible, I don't have a deep enough knowledge of SDL to know whether it would be wanted behaviour, and if so, in which direction

[turmoni]

OK, I'm definitely confused because I now see that the GUID of my controller isn't in the SDL_gamepad_db.h file, nor is the GUID listed in testcontroller --mappings, and I should probably stop guessing at what's going on and where this bad mapping is coming from.

[slouken]

It's probably coming from here:

SDL/src/joystick/linux/SDL_sysjoystick.c

Lines 2248 to 2254 in acaf539

	/*
	This is based on the Linux Gamepad Specification
	available at: https://www.kernel.org/doc/html/v4.15/input/gamepad.html
	and the Android gamepad documentation,
	https://developer.android.com/develop/ui/views/touch-and-input/game-controllers/controller-input
	*/
	static bool LINUX_JoystickGetGamepadMapping(int device_index, SDL_GamepadMapping *out)

[turmoni]

Ah, I now see that the match is fuzzy - getting rid of all of the Xbox 360 wireless controller entries from SDL_gamepad_db.h and removing the special case from SDL_gamepad.c makes the controller work fine in SDL3 testcontroller, using that code you pointed me at there.

I think I see two possible ways to fix this for SDL3 (before looking at SDL2):

• Update the mappings for the 360 wireless controller to use the hat inputs, which seem to have been reported for at least a decade (see: https://github.com/torvalds/linux/blame/a43a503df996739ae34f179f6b73b0ae91000c5c/drivers/input/joystick/xpad.c#L2002 ), and are unaffected by the other changes
• Get rid of the mappings entirely and rely on the autoconfiguration getting it right

The latter will need testing with an older version of xpad, but that's fine. Are there any preferences between the two options?

[slouken]

Getting rid of the mappings is probably the best long term fix, but will need lots of testing first.

[turmoni]

I suppose the question is which is riskier, updating a bunch of seemingly-duplicate entries, or removing them all and relying on falling back to the default behaviour? I'm genuinely unsure.

I've built an old version of xpad.ko and the default mapping works here too. It doesn't see the d-pad buttons as individual buttons, but it does use the hat axes, i.e.: dpup:h0.1,dpdown:h0.4,dpleft:h0.8,dpright:h0.2.

Now that I understand a bit more of the history here, I think this is old compatibility stuff that hasn't been needed for a decade breaking with what's now been done in the kernel. My understanding is:

1. With xpad, official original wired Xbox 360 controllers used to report the d-pad as a hat, and controllers using the official Xbox 360 wireless dongle reported it as buttons, for some reason that doesn't seem to have been very deliberate
2. A decade ago this was updated so that wireless controllers would always report both a hat and buttons. Wired original Xbox 360 controllers would still just report a hat.
3. For Linux 6.17, xpad was updated to change the buttons reported for controllers where the D-pad is exposed as buttons, which entirely consists of dance mats, and, for backwards compatibility reasons, the Xbox 360 wireless dongles

The custom mapping in SDL_gamepad.c became unneeded after point 2 above, and (in combination with the entries in SDL_gamepad_db.h) completely broke the d-pad's orientation when the kernel changes in point 3 were made.

[slouken]

That sounds like correct archaeology to me, and I think you're right that we don't need the custom mappings anymore. Let's try that and see?

I can test on Steam Link, which uses Linux kernel 3.8, which is the oldest kernel we'd need to worry about.

[turmoni]

Ah damn, if 3.8 is still important then that predates point 2, and also means that just mapping the d-pad to the hat won't work because it's not reporting that.

Might it be worth keeping the special case mapping in SDL_gamepad.c but somehow changing it to narrow down the cases in which it is applied depending on what features the pad has as reported by the kernel? Unfortunately I'm not seeing how you'd do that in this specific case without some rearchitecting.

[slouken]

Ah damn, if 3.8 is still important then that predates point 2, and also means that just mapping the d-pad to the hat won't work because it's not reporting that.

Might it be worth keeping the special case mapping in SDL_gamepad.c but somehow changing it to narrow down the cases in which it is applied depending on what features the pad has as reported by the kernel? Unfortunately I'm not seeing how you'd do that in this specific case without some rearchitecting.

I have some custom SDL changes for Steam Link, so I can add a mapping specifically for that. I think we're fine removing it in the general case.