Xbox Elite Series 2 back paddles not configurable with wired connection

[chaorace]

Your system information

• Steam client version (build number or date): 1646527495 (Mar 6 2022, at 00:19:25)
• Distribution (e.g. Ubuntu): Manjaro
• Opted into Steam client beta?: Yes
• Have you checked for system updates?: Yes

Please describe your issue in as much detail as possible:

I cannot map back paddles on my Xbox Elite Series 2 controller via Steam Input when using a direct USB connection, even though Steam is correctly detecting the controller type.
(with Bluetooth, the controller is merely recognized as a generic 360 gamepad)

Something seems to be missing from the Linux client's Steam Input driver, because the same computer booted to the same OS using the same Steam client does allow binding the back paddles when connecting the controller via Steam Link for Android.

Note the difference between the below screen captures

Direct USB connection to the computer:

Connected via Steam Link for Android, direct USB connection to the phone:

Steps for reproducing this issue:

1. Connect an Xbox Elite Series 2 controller to the computer via USB
2. Hold the middle profile switcher button on the controller for 3 seconds to ensure that the controller is in "profile 0"
3. Ensure that "Xbox Configuration Support" is enabled in Big Picture Controller Settings
4. Open the Controller Configuration UI for any game
5. Note the 4 missing mapping slots for the back paddles

[nanohard]

Xbox Elite 2 does not yet have support in Linux for the back paddles via its built-in driver xpad and what you're doing is going through Android's drivers. Though someone is currently working on it and you can build xpad from source with the patch to have the OS recognize the back paddles, Steam will still not recognize them unfortunately (in the patch's current state).

[chaorace]

To whom it may concern...

I've built out a new PR for paddle support in the xpad driver. If you happen to own an Elite controller and have some free time, I would greatly appreciate any help in testing the changes: paroj/xpad#195

The faster we can test this and work out the kinks, the sooner this PR can make its way upstream and someday make paddles in Linux's Steam Input a reality!

[Gurkoel]

I have the same issue with steam on windows, so it's not os related, maybe they messed something up in last upgrade...

[chaorace]

@Gurkoel I'm not really sure if these have the same root cause, since Elite controller paddle support has never worked on Linux. This is a known limitation of the Linux-included driver, whereas the Windows Steam client actually installs its own custom driver.

If it's not working for you, you should try troubleshooting this custom driver. First, make sure that advanced XB controller support is enabled in settings (this installs the driver) -- try toggling it if you already had it enabled. If the issue still persists, try restarting your machine to hopefully reload the driver.

[Esras]

Tried to do some debugging, I used the paroj/xpad repo and have the module loaded (@chaorace, thanks for the work on it). I can use jstest and see the paddles triggering just fine. In Windows, I can see the paddles and rebind them happily. I have the "Xbox Configuration Support" set in Controller Settings, and I am on the older 4.8.xxx firmware.

I've been trying to figure out how to continue debugging in Steam, since it sees it as an Elite controller, it just doesn't see the paddles in Linux.

Is there something I can do to continue debugging Steam's view of my controller? I did find the config.vdf and localconfig.vdf file on my Windows installation and I don't notice anything meaningfully different with those. Happy to provide more info on what I've looked into.

Steam client version (build number or date): 1661825435 (Aug 20, 2022, at 01:17:25)
Distribution (e.g. Ubuntu): Fedora 36
Opted into Steam client beta?: Yes
Have you checked for system updates?: Yes

[chaorace]

@Esras I believe this is now in Valve's hands. The buttons are exposed on the driver-level, but Steam Input doesn't yet know to listen for them. Even if you tinker with the SDL vdfs in Steam to have knowledge of the paddle inputs, the binding UI still won't make the paddles available for binding on Linux.

This leads me to think that there must be some kind of basic OS check happening in the Steam client which can probably now be changed to instead gate behind a kernel version check once the next kernel version drops. The supporting commit is still in the next branch at the moment: e23c69e3324892f7420686b3aaa0403df6cf152c.

[paroj]

probably SDL needs an update too. See https://github.com/gabomdq/SDL_GameControllerDB

you can generate the according entry by building SDL from source and using SDL/built/test/controllermap

edit: forget this - steam is supposed to generate this by itself

[Esras]

@paroj, No, you're right! I did a controller map from building SDL tests from source (current master, edfb00c25) and got this string:

030000005e040000000b000008040000,Xbox One Elite 2 Controller,platform:Linux,crc:085d,a:b0,b:b1,x:b2,y:b3,back:b6,guide:b8,start:b7,leftstick:b9,rightstick:b10,leftshoulder:b4,rightshoulder:b5,dpup:h0.1,dpdown:h0.4,dpleft:h0.8,dpright:h0.2,paddle1:b11,paddle2:b13,paddle3:b12,paddle4:b14,leftx:a0,lefty:a1,rightx:a3,righty:a4,lefttrigger:a2,righttrigger:a5,

Dropping that in place in the SDL_GamepadBind option in config.vdf got it to show up with those buttons in the Steam Controller configuration interface. It did regenerate the full strings, which produced this:

1581     "SDL_GamepadBind"       "030000005e040000000b000008040000,Xbox One Elite 2 Controller,platform:Linux,crc:085d,a:b0,b:b1,x:b2,y:b3,back:b6,guide     :b8,start:b7,leftstick:b9,rightstick:b10,leftshoulder:b4,rightshoulder:b5,dpup:h0.1,dpdown:h0.4,dpleft:h0.8,dpright:h0.2,paddle1:b11,paddle2:b13,pa     ddle3:b12,paddle4:b14,leftx:a0,lefty:a1,rightx:a3,righty:a4,lefttrigger:a2,righttrigger:a5,
1582 03000000de280000ff11000001000000,Steam Virtual Gamepad,a:b0,b:b1,back:b6,dpdown:h0.4,dpleft:h0.8,dpright:h0.2,dpup:h0.1,guide:b8,leftshoulder:b4,le     ftstick:b9,lefttrigger:a2,leftx:a0,lefty:a1,rightshoulder:b5,rightstick:b10,righttrigger:a5,rightx:a3,righty:a4,start:b7,x:b2,y:b3,platform:Linux
1583 03000000de280000fc11000001000000,Steam Controller,a:b0,b:b1,back:b6,dpdown:h0.4,dpleft:h0.8,dpright:h0.2,dpup:h0.1,guide:b8,leftshoulder:b4,leftsti     ck:b9,lefttrigger:a2,leftx:a0,lefty:a1,rightshoulder:b5,rightstick:b10,righttrigger:a5,rightx:a3,righty:a4,start:b7,x:b2,y:b3,platform:Linux"

But, more importantly, it let me bind things in the Controller config. I haven't tested it out with too many things (the first thing I tried was not great with the combo of keyboard and controller bindings), but Steam totally translated the buttons correctly.

My only request at this point would be for there to just be more arbitrary "controller buttons" that could be bound to things, rather than having stuff think it's a specific key, but I think that's asking to rewrite 40+ years of input history.

[chaorace]

Oh! I get what's going on now... I was using the stable Steam client when I tested the SDL thing. I switched over to the beta client just now and it's now showing the paddles after manually setting the SDL config. Huzzah!

For those looking for the quick solution, follow these steps:

1. Install the latest xpad DKMS driver (see xpad README or install xpad-dkms-git from AUR) OR simply wait for the driver to arrive in the next kernel version
2. Verify you are opted into the Steam client beta in Steam settings
3. Close Steam completely
4. Launch Steam from the CLI with the following command SDL_GAMECONTROLLERCONFIG="030000005e040000000b000008040000,Xbox One Elite 2 Controller,platform:Linux,crc:085d,a:b0,b:b1,x:b2,y:b3,back:b6,guide:b8,start:b7,leftstick:b9,rightstick:b10,leftshoulder:b4,rightshoulder:b5,dpup:h0.1,dpdown:h0.4,dpleft:h0.8,dpright:h0.2,paddle1:b11,paddle2:b13,paddle3:b12,paddle4:b14,leftx:a0,lefty:a1,rightx:a3,righty:a4,lefttrigger:a2,righttrigger:a5," steam
5. Paddles should now be available for binding in the Steam Input UI!

Using the SDL_GAMECONTROLLERCONFIG variable causes Steam to save the layout to config.vdf, which is actually what @Esras recommends above -- this is just an easier way to do that without directly fiddling with the VDF. You should only need to do this once and it'll stick forever without needing to supply the custom environment variable ever again (hypothetically, at least... depending on if the config ever happens to get lost or clobbered for some reason).

[chaorace]

FWIW: I don't know if the variable method works on the flatpak version of Steam.

Also, the given config string is for the Elite 2 controller. It'd be cool if someone with the OG Elite controller could generate and share their controller map string as well.

[maverick1872]

@chaorace I'm stoked about this so thanks for taking the time to open the PRs to get this in. Is there anything I can help with?

[chaorace]

@maverick1872 In terms of help, the last thing we really need is for the Linux Steam client to generate SDL game controller configs that include the new buttons exposed by the new xpad change on the Elite & Elite 2 controllers.

It's not currently clear to me how we can achieve this, however. It's possible this either needs to be resolved in an upstream dependency or in Steam itself. IMO, it's likely that Steam is just using the community SDL_GameControllerDB project, which would mean that a PR needs to be submitted there updating the Elite controller entries to include paddles. (Pinging @kisak-valve for confirmation if this is the right route to take)

Assuming that's how this works, we should update these lines (Edit: Nope. See comment thread below for details) to include bindings for paddle1, paddle2, paddle3, and paddle4. These are the two profiles specifically tied to the controllers when operating in a WIRED LINUX configuration, so they're the only two we strictly need to update. It should be as simple as inserting paddle1:b11,paddle2:b13,paddle3:b12,paddle4:b14 into the existing mapping for both lines.

While I'd like to get bluetooth working as well, I don't believe that editing the Elite bluetooth bindings will have any tangible effect because the only bluetooth driver that supports paddles -- xpadneo -- always reports Elite controllers as GUID 050000005e040000fd02000030110000 (AKA: a normal Xbox One Controller). That presents an issue because I'm pretty sure that adding paddle button mapping to the 050000005e040000fd02000030110000 entry would cause Steam (and other games) to mistakenly think that normal Xbox One controllers also have paddles. Pinging @kakra in case he has any input regarding the SDL binding or how Steam Input can potentially work around the issue with some bespoke support.

[chaorace]

One more note regarding bluetooth paddles via xpadneo since it may turn up in Google searches: Just like with the wired SDL mapping, you can make paddles work by manually setting a variable when launching steam.

This specifically worked for me with an Elite 2 controller on bluetooth (haven't tested if I got the exact paddle order right yet, though):
SDL_GAMECONTROLLERCONFIG="050000005e040000fd02000030110000,Xbox One Controller,a: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,paddle1:b11,paddle2:b13,paddle3:b12,paddle4:b14,platform:Linux," steam

Keep in mind that this workaround will probably cause normal Xbox One controllers to also think that they have paddle buttons when connected via Bluetooth, which is a consequence of the issue noted in the previous comment.

[kisak-valve]

Hello @chaorace, I don't have insight into the internals, but I'd expect the right course of action here is to see if the upstream SDL project can be made to work as intended, and Steam should pick up the changes at some point as a downstream project. If xpadneo needs to be more accurate with the controller ID, then that's something to discuss with that project's maintainer(s).

[mhalano]

It would be nice to have Bluetooth support, but I don't know for sure where changes have to be made. xpad driver is just for when you are using cable.

[chaorace]

Hello @chaorace, I don't have insight into the internals, but I'd expect the right course of action here is to see if the upstream SDL project can be made to work as intended, and Steam should pick up the changes at some point as a downstream project.

Understood. Who can we reach out to for more input? (Pun intended). Even if we know it's an upstream project, it's not necessarily guaranteed to be SDL_GameControllerDB (which is not included with SDL library by default and is, as mentioned, a community project). Since the Steam client is closed source, we're completely blind on this and need to rely on an insider to be sure we're not wasting effort on updating the wrong library.

If xpadneo needs to be more accurate with the controller ID, then that's something to discuss with that project's maintainer(s).

That would be kakra, who has been pinged. IIRC, there's a very good reason for the controller ID thing that may be impossible to work around at the driver layer. This is why I brought up the possibility of a bespoke workaround at the application layer, even if only to understand the cost/benefit. FWIW: I do believe there is already precedent for Steam Input doing such bespoke workarounds for the generic bluetooth controller driver.

[kisak-valve]

Upstream SDL: https://github.com/libsdl-org/SDL

[chaorace]

Thanks Kisak. I'm going to assume that means you're not currently touching the bindings for the Elite controllers in a custom "gameccontrollerdb.txt" file and that you're using the bindings 100% as-is from the stock SDL controller DB.

In that case... @maverick1872 if you're interested in contributing, the place to make the change is roughly here in the SDL project. I believe both the OG Elite and Elite 2 will require new lines for their respective wired GUIDs. These should basically be the same as their respective bluetooth versions (The ones starting with 05) but with the addition of paddle bindings (same extra binding as the prior comment). Let me know if you'd rather not and I'll try my hand at the PR instead -- just wanted to give you a chance to pitch in since you asked.

[kakra]

@chaorace The general problem with SDL is that it re-implements kernel driver logic in user-space but using fixed hardware description tables (controllerdb) instead of HID descriptors (which it could easily obtain at least from xpadneo). I wish SDL would prefer HID descriptors if available. This also has the downside of people submitted SDL button layouts before paddles were even a thing in SDL - and we ended up with GUIDs that are missing those paddles.

The current implementation of using one single fixed GUID is a work-around for early SDL versions. I'm in the process of redoing that but lacking some time (xpadneo HID reports aren't compatible with SDL expectations, xpadneo GUIDs should not be submitted to SDL controllerdb at all).

The best course of action is probably submitting updated GUIDs with paddles to SDL - once the kernel implementation settled so we don't end up with incompatible bitmaps across different models and devices. As written before, I'd prefer if SDL would make HID descriptors a first class citizen and only fall back to controllerdb if it is not a HID device.

One other thing is that SDL doesn't support all the proper device fixups we have, e.g., in xpadneo (like the rumble crash adapted for newer firmwares). But things are probably like things are and it's too late to change anything or hope anything. It's just duplicate efforts, and things are partially incompatible between what SDL expects and what low-level joydev expects so we always end up with fitting either the one or the other. BTW: Chrome does a similar thing as SDL but in a completely messed up way.

Currently, the best way is to disable Steam Input when using xpadneo: The wine layer of Proton with its new HID implementation should properly support the paddles of xpadneo. Of course, this will disable the remapping feature of Steam. Also, xpadneo is incompatible with the overlay hotkey feature of Steam currently as we don't expose the guide button as a gamepad button (we rather use it as a shift button for mode switching).

But I'm planning to change a lot of details during v0.10 and v0.11, so don't put too much effort in adjusting any application layer to xpadneo. Just disable Steam Input, or disable hidraw access permissions, and don't add controllerdb entries - the latter one will only add to the mess that's been there since the beginning around 5 years ago.

Take note that, when wired, these controllers are not HID devices. Using the controller wired will completely remove xpadneo from the supply chain as xpadneo is a HID-only driver (it's not a Bluetooth driver).

[chaorace]

Good to know. For now I suppose we'll stick to working on making SDL play nice with the paddles on a wired connection via xpad.

It's definitely worth addressing SDL someday down the line once you revisit xpadneo's GUID reporting, though. That's not a pressing concern in the meantime, of course, since most people who really want wireless paddle binding in Steam Input can get by through manually tweaking the config.vdf. The aforementioned side-effect of seeing useless paddles with regular Xbox One controllers is probably quite harmless, after all.

Good point regarding delaying the SDL PR until those xpad changes are in a numbered kernel release, by the way! I was probably being a little overeager to suggest otherwise... though I don't see any harm in submitting a draft PR in the meantime, just to get the gears turning.

[WillsterJohnson]

In big picture mode I seem to be able to map all four paddles to any other controller button, including use of gestures such as double-press, long press, chords, etc. Not sure about outside of big picture, tbh I never use Steam's browser-like windowed mode and have no idea where the Steam Input config is in there (if it even is there).
OS info;

Pop!_OS 22.04 LTS x86_64 
6.2.6-76060206-generic

Steam info;

Steam API: v020
Steam package versions: 1685488080

This is on an Xbox Elite Series 2 which was delivered this moring. No additional config beyond turning it on and pairing via bluetooth (settings UI, uses bluetoothctl v5.64).

After confirming I can map P1-4, I installed xpadneo by atar-axis as SkyrimSE wasn't picking up my trigger button presses (may be possible to solve this with just Steam Input, I didn't bother to check as I've read a lot of good things about xpadneo beyond just trigger button fixes).

---

Would be really nice if P1-4 were exposed as generic other buttons like with keyboard keys, but I don't know enough about game dev to know if that's possible (I'm just a web dev). Could be done by lying to the computer about the nature of the device to map P1-4 to F20-24 at the driver level? I'm not smart enough to tinker with that.