Add Xbox Series X controller bluetooth profile

[jelly]

My Xbox Series X controller has a different guid then the existsing SDL entry which means the buttons are mappend wrong.

Description

My Xbox series X controller runs the latest firmware and the only difference is the last part of the guid:

Existing entry's guid: 050000005e040000130b000011050000
My guid: 050000005e040000130b000009050000

This mapping requires a kernel patch to be applied as well as it fixes the mapping of some axes so they are correctly displayed in evemu-record. I haven't sent the patch upstream yet as it most likely will break the existing SDL entry and I would love to figure out what the difference is between the existing and my guid.

[cgutman]

The kernel patch might be dicey if you're breaking other userspace applications that expect the old mapping.

What happens without the patch?

[jelly]

The kernel patch might be dicey if you're breaking other userspace applications that expect the old mapping.

What happens without the patch?

The axes are mapped incorrectly currently from a Linux point of view. The driver could in theory have a module option to retain the old behaviour but that does not sound ideal either. I can't really test the difference here for the existing binding, do you know why the guid is different?

[cgutman]

The axes are mapped incorrectly currently from a Linux point of view.

Can you elaborate? Which axes? What is your expected mapping vs the actual mapping?

do you know why the guid is different?

It looks like that's the version part of the GUID (likely related to the firmware of the controller).

SDL/src/joystick/linux/SDL_sysjoystick.c

Lines 236 to 247 in dfbe1f7

	/* We only need 16 bits for each of these; space them out to fill 128. */
	/* Byteswap so devices get same GUID on little/big endian platforms. */
	*guid16++ = SDL_SwapLE16(inpid.bustype);
	*guid16++ = 0;
	if (inpid.vendor && inpid.product) {
	*guid16++ = SDL_SwapLE16(inpid.vendor);
	*guid16++ = 0;
	*guid16++ = SDL_SwapLE16(inpid.product);
	*guid16++ = 0;
	*guid16++ = SDL_SwapLE16(inpid.version);
	*guid16++ = 0;

What firmware version is your controller running?

[jelly]

The axes are mapped incorrectly currently from a Linux point of view.

Can you elaborate? Which axes? What is your expected mapping vs the actual mapping?

The right trigger is mapped to ABS_GAS which is for flight sim joysticks
The left trigger is mapped to ABS_BRAKE which is also for flight sim/racing joysticks. When connecting over USB this is mapped as ABS_Z/ABS_RZ which the userland expects for normal controllers.

The right joystick is mapped to ABS_Z/RZ while it should be the right X/Y axes. The kernel driver corrects this.

So without my kernel driver and profile, SDL maps the right trigger to the right joystick's Y axis:

The left trigger is mapped to the right trigger and the right joystick axes are also incorect.

[cgutman]

The right trigger is mapped to ABS_GAS which is for flight sim joysticks. The left trigger is mapped to ABS_BRAKE which is also for flight sim/racing joysticks.

Using ABS_GAS and ABS_BRAKE for triggers and ABS_Z and ABS_RZ for the right stick is quite standard in the Android world. It is even documented in the Android gamepad docs. This was very likely a conscious choice by Microsoft to be compatible with Android conventions (and therefore, existing Android games too).

I don't think it's a good idea to try to artificially change that. It creates a scenario where certain kernels will have one mapping and other kernels will have a different mapping, causing havoc for userspace. Consider SDL itself, where the mapping GUID for patched and non-patched kernels would be identical, and we couldn't tell which mapping to use.

It also risks causing behavior to change unexpectedly when Microsoft releases a new firmware (if the fixup is only done for certain firmware versions), or potentially interfering with legitimate HID descriptor changes (if the fixup is done for all firmware versions).

So without my kernel driver and profile, SDL maps the right trigger to the right joystick's Y axis:

We can probably improve SDL's heuristic in LINUX_JoystickGetGamepadMapping() to account for these "Android-style" gamepads that use ABS_BRAKE, ABS_GAS, or ABS_THROTTLE instead of ABS_Z and ABS_RZ.

[slouken]

We can probably improve SDL's heuristic in LINUX_JoystickGetGamepadMapping() to account for these "Android-style" gamepads that use ABS_BRAKE, ABS_GAS, or ABS_THROTTLE instead of ABS_Z and ABS_RZ.

Yep, that's a great idea.

[smcv]

It would be useful to add test data for this Xbox Series X controller using an unpatched kernel (in Bluetooth mode, and also in USB mode if different) to test/testevdev.c, to make sure our heuristic for recognising gamepads works correctly for it.

The easiest thing to convert into testevdev format is the output of evemu-describe /dev/input/eventX for each device node eventX associated with this controller.

Another thing that can be useful when investigating new controllers is the steam-runtime-input-monitor tool that comes with Steam, which will list all the device nodes associated with the controller (including any raw HID device nodes, accelerometers, gyros etc. that it might have). The easiest way to use that is to run

~/.steam/root/ubuntu12_32/steam-runtime/run.sh steam-runtime-input-monitor

with this device not connected, and wait for it to finish describing all your other devices (it should say {"all-for-now": true} at the end). Then connect this device, and copy/paste whatever new information is displayed after the {"all-for-now": true} marker. Press Ctrl+C to stop the input monitor when it has finished displaying the new device(s).

[smcv]

It would be useful to add test data for this Xbox Series X controller using an unpatched kernel (in Bluetooth mode, and also in USB mode if different) to test/testevdev.c, to make sure our heuristic for recognising gamepads works correctly for it.

#7791 added test data for a "Microsoft Xbox Series S|X Controller model 1914" which is a slightly different device: the one my colleague examined is reported as product 0b12 version 050f via USB or version 0515 via Bluetooth, while @jelly's is reported as product 0b13 version 0509 via Bluetooth (and an unknown product/version via USB).

My colleague's device has different input mappings via USB and Bluetooth. Via USB, it has the typical Xbox-360-style axes (X, Y, Z, RX, RY, RZ), which are presumably X/Y for the left stick, RX/RY for the right stick, Z for the left trigger and RZ for the right trigger, but via Bluetooth, it has X, Y, Z, RZ, GAS and BRAKE, which are presumably the Android-style layout that @cgutman describes.

@jelly's comments suggest that the same could be true for their controller. It would be useful to confirm that via evemu-describe.

We can probably improve SDL's heuristic in LINUX_JoystickGetGamepadMapping() to account for these "Android-style" gamepads that use ABS_BRAKE, ABS_GAS, or ABS_THROTTLE instead of ABS_Z and ABS_RZ.

I think that would be a better solution than merging this PR, particularly if this PR requires a patched kernel. I've proposed #7797.

[slouken]

Fixed by #7797