Xbox Elite 2 controller paddles not exposed to Steam Input UI

[Juppstein]

Your system information

• Steam client version (build number or date): 1680115169
• Distribution (e.g. Ubuntu): Ubuntu 22.04 LTS, kernel 6.1.0, hid-xpadneo v0.9-131-g0150346
• Opted into Steam client beta?: [Yes/No] Yes
• Have you checked for system updates?: [Yes/No] Yes

Please describe your issue in as much detail as possible:

Xbox Elite 2 Controller connected via Bluetooth. Back paddles are not exposed to Steam Input to be configurable.

Steps for reproducing this issue:

1. Connect controller via Bluetooth
2. Start Steam in either BPM or standard view
3. Go to either Settings/Controller or to controller settings in a game. Paddles are not exposed to controller mapping config.

[kisak-valve]

Hello @Juppstein, this is most likely an upstream SDL or xpadneo issue.

Possible duplicate of #8463.

[Juppstein]

Hello @Juppstein, this is most likely an upstream SDL or xpadneo issue.

Possible duplicate of #8463.

I see, going through that linked issue I see that there is a temp workaround by giving the SDL line on steam start via terminal. But it looks like this does not work anymore as the paddles are not visible in the Controller UI even when trying to give the SDL via command prompt. Does Steam Input ignore such tweaks now? I also tried editing the config.vdf but exactly the changes I added, the paddles, are ripped out of the SDL line each time Steam is starting.

[chaorace]

But it looks like this does not work anymore as the paddles are not visible in the Controller UI even when trying to give the SDL via command prompt. Does Steam Input ignore such tweaks now?

@Juppstein That seems unlikely. By design, library config environment variables like these basically bypass the directives from the main application. Can you post the result of whereis steam from a CLI? I want to ensure that we've confirmed this is the actual executable and not a flatpak/snap.

EDIT: Also, can you confirm which xbox bluetooth driver you're using (if any)?

[Juppstein]

@chaorace Sorry for my terribly late answer. Steam is located under /usr/bin/steam. I am using xpadneo as the driver for the Elite 2 over bluetooth. I have recently upgraded to SDL 2.28.1 which should now provide full support for the Elite 2 incl. the paddles. When I look at the Steam config.vdf I can see that the paddles are there as buttons 11 to 14 and the controller is recognized correctly but when I look at the controller config in Steam the paddles are not available for configuration. jstest-gtk does show the paddles as well.

[jjpe]

Has there been any movement on this? I just ran into this issue. Weird thing is, for me the Steam GUI shows the paddles, and I can configure them, but the games don't pick them up at all. Instead they are essentially mirrors of the face buttons regardless of the mapping I create for the paddles in Steam. Meanwhile almost any other button works perfectly.

[chaorace]

Has there been any movement on this? I just ran into this issue. Weird thing is, for me the Steam GUI shows the paddles, and I can configure them, but the games don't pick them up at all. Instead they are essentially mirrors of the face buttons regardless of the mapping I create for the paddles in Steam. Meanwhile almost any other button works perfectly.

@jjpe Double-check the profile indicator lights on the front of your controller. All three should be off, indicating that no profiles are active. This "no profile" mode is the only one which exposes the paddles directly to the operating system.

[jjpe]

@jjpe Double-check the profile indicator lights on the front of your controller. All three should be off, indicating that no profiles are active. This "no profile" mode is the only one which exposes the paddles directly to the operating system.

Using the default profile means that the paddles effectively do nothing when pressed, while any other profile displays the mirroring behavior I wrote about earlier.

[chaorace]

@jjpe In this case, nothing's better than something (active profiles remap the paddles before Linux ever sees them). Obviously there's still an issue, but we're on the right track at least.

We'll do a test, but I also need a few specific questions answered as well:

• Which Linux kernel version are you on?
• Do you have any third-party xbox controller drivers installed?
• Are you using the Xbox Elite 2 or the Xbox Elite?
• Which firmware version is your controller on?
• Have you tried restarting your machine at least once since your first attempt to use the controller?

Now for the test: exit Steam, then use jstest on your controller device and try pressing the paddle buttons. Paste the results here so we can get a better idea of what's going on.

The command itself is probably going to be either jstest /dev/input/js0 or jstest /dev/input0 (assuming you have no other joysticks plugged in). If neither of those paths seem to work you can instead look for your controller by name with ls /dev/input/by-id and then plug what you find from there into jstest, for example: jstest /dev/input/by-id/usb-Microsoft_Controller_3032363330303538313432313032-joystick

[jjpe]

Which Linux kernel version are you on?

[j@lear:~]$ uname -a
Linux lear 6.1.68 #1-NixOS SMP PREEMPT_DYNAMIC Wed Dec 13 17:39:30 UTC 2023 x86_64 GNU/Linux

Do you have any third-party xbox controller drivers installed?

I have the xpadneo driver explicitly enabled:

[j@lear:~]$ lsmod | grep xpad
hid_xpadneo            24576  0
ff_memless             20480  1 hid_xpadneo
hid                   155648  7 hidp,usbhid,hid_generic,hid_xpadneo,hid_logitech_dj,hid_logitech_hidpp,hid_magicmouse

However, I also tried not enabling that driver explicitly (i.e. using whatever the default is), and that gives the exact same results, so I'm not even sure that xpadneo actually does anything either way.

Are you using the Xbox Elite 2 or the Xbox Elite?

I am using the Are you using the Xbox Elite 2 controller.

Which firmware version is your controller on?

This is a tricky one. Any idea how can I access that info? MS didn't really build in any (easily discoverable) affordances to inspect or change the firmware on Linux.

Additional background info: I have neither a bootable Windows install nor an xbox series S|X, so I tried to upgrade the firmware via a virtualbox instance. The good news: in bluetooth mode the controller is actually detected by the windows-only xbox accessories utility. The bad news: The xbox accessories utility flatly refuses to perform firmware upgrades in bluetooth mode. Worse yet, when I plug in the controller via USB, the windows vbox guest detects something being plugged in, and then it is immediately plugged out again. No idea why.

Have you tried restarting your machine at least once since your first attempt to use the controller?

After each driver install/modification I always reboot the machine, even when it technically shouldn't be necessary. The described behavior persists across reboots.

[jjpe]

Now for the test: exit Steam, then use jstest on your controller device and try pressing the paddle buttons. Paste the results here so we can get a better idea of what's going on.

The command itself is probably going to be either jstest /dev/input/js0 or jstest /dev/input0 (assuming you have no other joysticks plugged in). If neither of those paths seem to work you can instead look for your controller by name with ls /dev/input/by-id and then plug what you find from there into jstest, for example: jstest /dev/input/by-id/usb-Microsoft_Controller_3032363330303538313432313032-joystick

Ok so there's no log being created or anything, and no CLI version of jstest in the NixOS repo I'm using as far as I can see, so I'll just write out the results of executing jstest-gtk /dev/input/js0:

• The paddles register as the following buttons:

  • P1 -> button 11
  • P2 -> button 12
  • P3 -> button 13
  • P4 -> button 14

• The face buttons register as follows:

  • A -> button 0
  • B -> button 1
  • X -> button 2
  • Y -> button 3

• In case it matters, the view and menu buttons register as button 6 and button 7, respectively.

I checked the face buttons too because I've seen those activate 2 buttons at a time each before. Fortunately that's not the case now.

I also checked the same without the xpadneo driver, and there the paddles don't register at all. So there is in fact something that xpadneo does.

It might also be worth mentioning that I'm trying to use the controller via Bluetooth rather than USB, if that matters.

EDIT: Using USB does work a lot better, including the paddles. But it still seems to me that Bluetooth mode shouldn't be a problem.

[chaorace]

@jjpe Ah, that explains a lot. Please see this section of the xpadneo readme.

SDL 2.28 has since been officially released, however since you are using NixOS it is possible that you may be using a channel (23.05) which does not feature a sufficiently new release of the library. Can you confirm for me which release channel you're currently using?

EDIT: I actually experienced the same thing when upgrading my own controller in a VM environment! Eventually I was able to bypass the issue with qemu by giving it ownership of a specific host USB port and only plugging in the controller after launching the VM. IIRC I also had to temporarily disable the kernel's xpad module via sudo modprobe -r xpad (revert via sudo modprobe xpad)

[jjpe]

Can you confirm for me which release channel you're currently using?

Sure thing:

[j@lear:~]$ nix-channel --list
nixos https://nixos.org/channels/nixos-unstable

In addition, I just tried nix-shell -p SDL2, which yielded this:

[j@lear:~]$ nix-shell -p SDL2
these 6 paths will be fetched (0.84 MiB download, 8.38 MiB unpacked):
  /nix/store/byphvb2ylrc059nd90zdw7q3qf6xm7r6-SDL2-2.28.5-dev
  /nix/store/51781vy0yy8r17x6x2f1r6hcx3lp3a2c-libGL-1.7.0-dev
  /nix/store/qyqghh5k3dxlnwhhvrxvjx0yqd1zvicy-libX11-1.8.7-dev
  /nix/store/g284bl6g61mbdr1zrmyp1bl4nzhqaly7-libglvnd-1.7.0-dev
  /nix/store/swlk5ksgjrfp9i5mx2gcqxl9rr3ifyn4-libxcb-1.16-dev
  /nix/store/bp4a3z0drfr8s0dxw69wrsnxhk78psa8-xorgproto-2023.2
copying path '/nix/store/bp4a3z0drfr8s0dxw69wrsnxhk78psa8-xorgproto-2023.2' from 'https://cache.nixos.org'...
copying path '/nix/store/g284bl6g61mbdr1zrmyp1bl4nzhqaly7-libglvnd-1.7.0-dev' from 'https://cache.nixos.org'...
copying path '/nix/store/swlk5ksgjrfp9i5mx2gcqxl9rr3ifyn4-libxcb-1.16-dev' from 'https://cache.nixos.org'...
copying path '/nix/store/51781vy0yy8r17x6x2f1r6hcx3lp3a2c-libGL-1.7.0-dev' from 'https://cache.nixos.org'...
copying path '/nix/store/qyqghh5k3dxlnwhhvrxvjx0yqd1zvicy-libX11-1.8.7-dev' from 'https://cache.nixos.org'...
copying path '/nix/store/byphvb2ylrc059nd90zdw7q3qf6xm7r6-SDL2-2.28.5-dev' from 'https://cache.nixos.org'...

Note the libSDL2 version: SDL2-2.28.5-dev, which should meet the >= 2.28 target.

EDIT: I actually experienced the same thing when upgrading my own controller in a VM environment! Eventually I was able to bypass the issue with qemu by giving it ownership of a specific host USB port and only plugging in the controller after launching the VM. IIRC I also had to temporarily disable the kernel's xpad module via sudo modprobe -r xpad (revert via sudo modprobe xpad)

I'll give this a shot a little later then circle back with the results. Either way thanks for the tip! :slightly_smiling_face:

[chaorace]

@jjpe Interesting. What does Steam report for the paddle inputs in the device test menu?

[jjpe]

So I can't get passthrough to work for me. Maybe it's PEBKAC, so just to check:

[nix-shell:~]$ lsusb -t
/:  Bus 001.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/12p, 480M
    |__ Port 004: Dev 014, If 0, Class=Vendor Specific Class, Driver=xpad, 12M
    |__ Port 004: Dev 014, If 1, Class=Vendor Specific Class, Driver=[none], 12M
    |__ Port 004: Dev 014, If 2, Class=Vendor Specific Class, Driver=[none], 12M
/:  Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/5p, 20000M/x2
/:  Bus 003.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/12p, 480M
    |__ Port 006: Dev 002, If 0, Class=Human Interface Device, Driver=usbhid, 12M
    |__ Port 007: Dev 003, 12M
    |__ Port 008: Dev 004, If 0, Class=Wireless, Driver=btusb, 12M
    |__ Port 008: Dev 004, If 1, Class=Wireless, Driver=btusb, 12M
    |__ Port 009: Dev 005, If 0, Class=Human Interface Device, Driver=usbhid, 12M
    |__ Port 009: Dev 005, If 1, Class=Human Interface Device, Driver=usbhid, 12M
    |__ Port 009: Dev 005, If 2, Class=Human Interface Device, Driver=usbhid, 12M
/:  Bus 004.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/5p, 20000M/x2
/:  Bus 005.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/2p, 480M
/:  Bus 006.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/2p, 10000M
/:  Bus 007.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/2p, 480M
/:  Bus 008.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/2p, 10000M
/:  Bus 009.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/1p, 480M
    |__ Port 001: Dev 002, If 0, Class=Hub, Driver=hub/4p, 480M
        |__ Port 001: Dev 003, If 0, Class=Human Interface Device, Driver=usbhid, 12M
        |__ Port 001: Dev 003, If 1, Class=Human Interface Device, Driver=usbhid, 12M
        |__ Port 001: Dev 003, If 2, Class=Human Interface Device, Driver=usbhid, 12M
/:  Bus 010.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/0p, 5000M

[nix-shell:~]$ lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 014: ID 045e:0b00 Microsoft Corp. Xbox Elite Series 2 Controller (model 1797)
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 002: ID 048d:5702 Integrated Technology Express, Inc. RGB LED Controller
Bus 003 Device 003: ID 0bda:0852 Realtek Semiconductor Corp. Bluetooth Radio
Bus 003 Device 004: ID 0b05:190e ASUSTek Computer, Inc. ASUS USB-BT500
Bus 003 Device 005: ID 046d:c52b Logitech, Inc. Unifying Receiver
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 007 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 008 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 009 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 009 Device 002: ID 05e3:0608 Genesys Logic, Inc. Hub
Bus 009 Device 003: ID 29ea:0102 Kinesis Corporation Advantage2 Keyboard
Bus 010 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub

From that I infer that this should work (windows is already installed to the QCOW file):

sudo modprobe -r hid_xpadneo xpad  &&
qemu-system-x86_64 \
        -enable-kvm                                                    \
        -m 16G                                                         \
        -smp 4                                                         \
        -hda /media/teradisk/qemu.vms/windows-10-test.qcow2            \
        -boot d                                                        \
        -usb                                                           \
        -device usb-ehci,id=ehci \
        -device qemu-xhci \
        -device usb-host,hostbus=1,hostport=1 \
        -device usb-host,hostbus=1,hostport=4 \
        -vga qxl                                                       \
        -device AC97

Now, Windows boots up, but it doesn't detect the xbox controller; only the USB host controller I think.

@jjpe Interesting. What does Steam report for the paddle inputs in the device test menu?

When using USB: The controller is named Xbox One Elite 2 Controller. I have highlighted the paddle entries with red:

Each of the values flips to true when I press the corresponding paddle.

When using Bluetooth: I just noticed an important difference here: The controller is named Xbox 360 Controller.

Given that it might not be a surprise that none of the paddles register.

So it seems like a detection issue - once properly detected (as with the USB case) it seems to work correctly. But why would Steam detect it as an xbox 360 controller?

[chaorace]

@jjpe Are you using the Steam Beta client or stable? I installed xpadneo and the Steam package via nix and I'm able to see paddles registering in the input test window on the beta client:

The reason that Steam calls it an Xbox 360 Controller is because SDL calls it an Xbox 360 Controller. SDL calls it an Xbox 360 Controller because that's how xpadneo represents it to SDL. The whole "thing" with the SDL 2.28 change was that it allowed for SDL to detect paddle capabilities on the controller regardless of how xpadneo represents the controller model so long as the xpadneo driver is providing the button events to SDL.

Funnily enough, now that I'm testing it for myself, Steam will not allow me to configure the paddle buttons even though the paddles are totally shown and functional in the client's input test UI. That seems to be a distinct problem, so let's keep focusing on figuring out why your Steam client is not detecting the paddle capabilities.

[chaorace]

@jjpe Regarding the qemu issue, it turns out I misremembered the solution. You actually need to blacklist the module via the modprobe config (source). I'm not actually sure if that's functionally any different from unloading the module at runtime but I suppose it's worth a shot?

[jjpe]

Are you using the Steam Beta client or stable?

Due to this issue I'm using this solution for now. It pulls a semi-recent version of Steam from nixpkgs without installing it. But it should be a stable version; nowhere have I requested a Beta version, and if it weren't for the issue I mentioned, I'd just be using the latest (stable) version.

From Steam's about menu:

Steam Version:  1702079146
Steam Client Build Date:  Fri, Dec 8 01:33 UTC -08:00
Steam Web Build Date:  Sat, Dec 9 00:30 UTC -08:00
Steam API Version:  SteamClient021

The reason that Steam calls it an Xbox 360 Controller is because SDL calls it an Xbox 360 Controller.

Okay, but then shouldn't the same be true for USB mode as well?
I'm assuming SDL is used regardless of whether the controller is connected via Bluetooth or USB.

Regarding the qemu issue, it turns out I misremembered the solution. You actually need to blacklist the module via the modprobe config (source). I'm not actually sure if that's functionally any different from unloading the module at runtime but I suppose it's worth a shot?

I'll go try this now; if the kernel does an auto-modprobe when plugging in a device if drivers are available, then blacklisting could make a difference here.

[chaorace]

@jjpe You should be able to opt into the beta from inside of the steam client settings under the "Interface" submenu. I believe this should work even if you're using an older nix package, since Steam is one of the few nix packages that mostly manages its own updates. It worked for me but FWIW I installed Steam via the home-manager module.

Okay, but then shouldn't the same be true for USB mode as well?

No, xpad, built-in module, reports the device based on what the USB PID tells it as seen here. xpadneo is a different project which currently only handles bluetooth (though there are eventually plans to support USB there as well). xpadneo is different from the USB xpad driver because it always reports the same device regardless of the controller model. This difference in operation is necessary for reasons which I am not very good at explaining.

NOTE: I am not actively involved with the xpadneo project and my main knowledge is mostly limited to a few small parts of the kernel xpad module which I've personally worked on in the past.

[jjpe]

You should be able to opt into the beta from inside of the steam client settings under the "Interface" submenu.

I just switched to Steam beta, but the results are unchanged I'm afraid. I also ran it through jstest-gtk again, and again the paddles are detected there; just not in Steam (beta).

No, xpad, built-in module, reports the device based on what the USB PID tells it as seen here

I see. Well, at least the vendorid and productid for the Elite 2 controller look familiar from my lsusb output.

Is there anything else we could try? I'm kind of invested :)

[chaorace]

@jjpe Let's check what the SDL config is within the config.vdf file at ~/.steam/config/config.vdf. If you could share here the value of SDL_GamepadBind within the file that might give us a better idea of what's going on

[jjpe]

Let's check what the SDL config is within the config.vdf file at ~/.steam/config/config.vdf

So... The ~/.steam/config dir doesn't exist:

[j@lear:~]$ ls -ahl ~/.steam/
total 24K
drwxr-xr-x  2 j users 4,0K 22 dec 23:12 .
drwx------ 34 j users 4,0K 22 dec 23:12 ..
lrwxrwxrwx  1 j users   20 22 dec 23:12 bin -> /home/j/.steam/bin32
lrwxrwxrwx  1 j users   38 22 dec 23:12 bin32 -> /home/j/.local/share/Steam/ubuntu12_32
lrwxrwxrwx  1 j users   38 22 dec 23:12 bin64 -> /home/j/.local/share/Steam/ubuntu12_64
-rwxr-xr-x  1 j users 4,9K 22 dec 23:12 registry.vdf
lrwxrwxrwx  1 j users   26 22 dec 23:12 root -> /home/j/.local/share/Steam
lrwxrwxrwx  1 j users   34 22 dec 23:12 sdk32 -> /home/j/.local/share/Steam/linux32
lrwxrwxrwx  1 j users   34 22 dec 23:12 sdk64 -> /home/j/.local/share/Steam/linux64
lrwxrwxrwx  1 j users   26 22 dec 23:12 steam -> /home/j/.local/share/Steam
-rw-r--r--  1 j users    6 22 dec 23:12 steam.pid
prw-------  1 j users    0 22 dec 22:14 steam.pipe
-r--------  1 j users   16 22 dec 23:12 steam.token

Perhaps that's a clue?

[chaorace]

Perhaps that's a clue?

Ah, sorry I meant .steam/steam/config

[jjpe]

That does exist :)

"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,paddle3:b12,paddle4:b14,leftx:a0,lefty:a1,rightx:a3,righty:a4,lefttrigger:a2,righttrigger:a5,
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,leftstick: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,
03000000de280000fc11000001000000,Steam Controller,a:b0,b:b1,back:b6,dpdown:b14,dpleft:b15,dpright:b13,dpup:b12,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,platform:Linux,
030000005e040000a102000000010000,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,platform:Linux,
,platform:Linux
050000005e040000050b000002090000,Xbox One Elite 2 Controller,a:b0,b:b1,x:b3,y:b4,back:b10,guide:b12,start:b11,leftstick:b13,rightstick:b14,leftshoulder:b6,rightshoulder:b7,dpup:h0.1,dpdown:h0.4,dpleft:h0.8,dpright:h0.2,paddle1:b21,paddle2:b23,paddle3:b22,paddle4:b24,leftx:a0,lefty:a1,rightx:a2,righty:a3,lefttrigger:a6,righttrigger:a5,crc:085d,platform:Linux,
050000005e0400008e02000030110000,Xbox 360 Controller,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,leftx:a0,lefty:a1,rightx:a3,righty:a4,lefttrigger:a2,righttrigger:a5,crc:f003,platform:Linux,
030000005e040000000b000007040000,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,"

Looks like there are a couple of double entries; not sure if that matters here. In addition, that ,platform:Linux entry in the middle looks a little sus.

[chaorace]

@jjpe That's not concerning. We expect to see one entry per unique controller kind but there's all kinds of things that affect it (bluetooth vs. wired, controller firmware version, 3rd party drivers). As long as the first part with the ID is not duplicated it's going to work without issue.

When using xpadneo your controller should use the profile associated with 050000005e0400008e02000030110000. For whatever reason we can see that this profile lacks the paddle configuration even though SDL is supposed to handle that correctly now. Let's launch steam with an option that forces an accurate SDL configuration and see what happens in the Steam input test menu:

SDL_GAMECONTROLLERCONFIG="050000005e0400008e02000030110000,Xbox 360 Controller,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,platform:Linux," steam

[jjpe]

That works in the way you described it should:

Marked as an x360 controller, with paddle support, and they even flip the values when pressed.

However, when I try map the paddles with Steam Input for Dyson Sphere Program (a game without controller support), the paddles are nowhere to be found:

Any idea what could be causing that?

[chaorace]

@jjpe Well, that pretty much settles it then. SDL as of 2.28 is correctly handling paddles without gating that behind specific controller GUIDs like it used to. We can even confirm that Steam itself is indeed correctly receiving and interpreting these paddle events from SDL. By all appearances, Steam Input seems to be failing to present the correct controller type GUI at the very last step in the chain.

If I had to guess, this is happening because Steam Input decides which controller type it's looking at based upon the SDL GUID rather than the capabilities SDL reports for that device. If that's the case then I think our only remaining option is to beg on Valve for better capability detection, since the bluetooth controller driver has to use an unusual GUID. Thoughts, @kisak-valve?

[jjpe]

It's been a little while since the previous post. If at all possible would you mind taking a look @kisak-valve ?

[StormyIceLeopard]

There is a discussion forum about this on Steam as well.

So there is attention

https://steamcommunity.com/app/1675200/discussions/0/3761104682798845388/?tscn=1705452510

[krasmazov483]

If I had to guess, this is happening because Steam Input decides which controller type it's looking at based upon the SDL GUID rather than the capabilities SDL reports for that device. If that's the case then I think our only remaining option is to beg on Valve for better capability detection, since the bluetooth controller driver has to use an unusual GUID.

If that's the case, I hope this is fixed soon. I know this is specifically about the Xbox Elite 2 controller, but this exact same issue also happens on my Flydigi Vader 3 Pro, so I thought it would be useful to comment here.

I had to use an unmerged PR for xpad to expose the extra buttons and after that had to setup a SDL mapping for the controller. The mapping is properly recognized by Steam on the controller's testing page and it also recognizes the paddles being pressed, but it doesn't show up for binding when editing the controller profile of any game, just like the screenshots posted 4 comments above. Also, this controller have 2 other additional buttons, C and Z, mapped to misc1 and touchpad that are not visible on the controller's test page, but works when configuring there. Both buttons are also not exposed when editing the controller settings for any game.

[StormyIceLeopard]

Steam Support Requested I post here

https://steamcommunity.com/app/1675200/discussions/1/4208120159995460102/

I just hope it gets fixed soon

[Juppstein]

Based on this here:

https://steamcommunity.com/app/1675200/discussions/0/3761104682798845388/?tscn=1709013196#c4295942652153460218

As of one of the last betas I can now see L4/R4 and L5/R5, which respresent the four paddles in Settings/Controler/Test Device Input. When pulling the paddles I can see that Steam recognizes the input.

Now, the big question is, how do I come to the point that I am able to assign those paddles in an actual game? I have yet to find a way to see the paddles in a layout so that I can put them to good use.

[chaorace]

Quick update for anyone watching this issue: it looks like something changed in the beta client starting back in March. I tested this today by connecting my Elite 2 to an unmodded Steam Deck via the stock bluetooth HID driver and confirmed that the rear paddles were configurable in Steam Input.

I can't seem to find where my USB bluetooth dongle went, so I'm unable to test on a proper desktop machine right now. I would be very interested to hear if anyone here can test and see if they now have working paddles when connecting via bluetooth on a Linux machine!

Some tips to anyone looking to try this:

1. Verify that you have the latest Steam beta client installed
2. Verify that the controller is set to the default profile (press the profile switcher button until all three profile lights are off)
3. Manually reset SDL configuration. To do this, first close Steam, then remove any config lines including "Xbox" from ~/.steam/steam/config/config.vdf (avoid deleting any " quotation marks & do NOT delete "SDL_GamepadBind").
4. Disable/uninstall xpadneo (if previously installed) & reboot. I'm unsure if doing this is actually necessary... but it's something to try if you aren't seeing results (I did not have xpadneo installed on my Steam Deck during the successful test)
5. Try reseting & redoing bindings via Steam (Settings > Controller > Test Device Inputs)

[robled]

I'm dual-booting HoloISO and Bazzite, and in the last month or so my paddles appeared and are configurable in the Steam Input UI when connected via Bluetooth. I don't know if those distros default to the stable or beta client.

[Juppstein]

Cannot confirm this on my side here in Ubuntu 22.04. I went through the steps provided by chaorace with no success. By the way I have to have xpadneo loaded or the paddles are not shown in Steam at all. So, while the paddles do appear in Options / Settings / Controller / Test Device Input since quite a few weeks now, I have yet to find a way, or a game, where I can go to name of game Controller Settings / Edit Layout and assign something to one of the paddles. They are simply not listed for me here.

[chaorace]

@Juppstein Huh... I tried it on my desktop and had the same issue. It took me a little tinkering, but I did eventually manage to make it work.

First, make sure xpadneo is still uninstalled and/or blacklisted, close out Steam, and reset the SDL configuration as previously described. Then, add the following udev rule to /etc/udev/rules.d/ in a file named something like 70-hid.rules:

KERNEL=="hidraw*", TAG+="uaccess"

Once you've done that, disconnect the controller, reload the rules using sudo udevadm control --reload-rules, then finally do sudo udevadm trigger before plugging the controller back in.

You should find after doing this that Steam Input now shows the the paddle buttons on the configurator screen.

[chaorace]

Did you get a chance to try that udev rule with your controller? @Juppstein

[Juppstein]

Did you get a chance to try that udev rule with your controller? @Juppstein

Yup just tried it, and it did not work. In fact when I have the xpadneo driver blacklisted the controller is not even recognized in Steam. It appears in configured bluetooth devices but that's just about it. When I unblock the module and remove the udev rule everything works again , sans paddles of course :)

Based on how you wrote your post you have the controller connected by cable? Perhaps that is the difference between your system and mine?

[chaorace]

Based on how you wrote your post you have the controller connected by cable? Perhaps that is the difference between your system and mine?

I tested it with a wireless bluetooth adapter, with the controller in bluetooth mode. And yes, the paddles are recognized, mappable, and working when using it like this even with no USB cable connected at all.

Yup just tried it, and it did not work. In fact when I have the xpadneo driver blacklisted the controller is not even recognized in Steam. It appears in configured bluetooth devices but that's just about it. When I unblock the module and remove the udev rule everything works again , sans paddles of course :)

Steam is using the hidraw device to interface with the controller and, based on what you're saying, it sounds like Steam can't see the hidraw device. We can find out more about why that might be the case via the udevadm info --tree command. Here's what the controller device should look like in the tree if the hidraw device is recognized and available:

udevadm output

``` │ └─0005:045E:0B22.0110 │ ┆ P: /devices/virtual/misc/uhid/0005:045E:0B22.0110 │ ┆ M: 0005:045E:0B22.0110 │ ┆ R: 0110 │ ┆ U: hid │ ┆ V: microsoft │ ┆ E: DEVPATH=/devices/virtual/misc/uhid/0005:045E:0B22.0110 │ ┆ E: SUBSYSTEM=hid │ ┆ E: DRIVER=microsoft │ ┆ E: HID_ID=0005:0000045E:00000B22 │ ┆ E: HID_NAME=Xbox Wireless Controller │ ┆ E: HID_PHYS=5c:f3:70:a4:3c:8d │ ┆ E: HID_UNIQ=44:16:22:3b:b1:99 │ ┆ E: MODALIAS=hid:b0005g0001v0000045Ep00000B22 │ ├─hidraw/hidraw17 │ │ ┆ P: /devices/virtual/misc/uhid/0005:045E:0B22.0110/hidraw/hidraw17 │ │ ┆ M: hidraw17 │ │ ┆ R: 17 │ │ ┆ U: hidraw │ │ ┆ D: c 243:17 │ │ ┆ N: hidraw17 │ │ ┆ L: 0 │ │ ┆ E: DEVPATH=/devices/virtual/misc/uhid/0005:045E:0B22.0110/hidraw/hidraw17 │ │ ┆ E: SUBSYSTEM=hidraw │ │ ┆ E: DEVNAME=/dev/hidraw17 │ │ ┆ E: MAJOR=243 │ │ ┆ E: MINOR=17 │ │ ┆ E: USEC_INITIALIZED=1413683175849 │ │ ┆ E: TAGS=:uaccess:seat: │ │ ┆ E: CURRENT_TAGS=:uaccess:seat: │ └─input/input521 │ ┆ P: /devices/virtual/misc/uhid/0005:045E:0B22.0110/input/input521 │ ┆ M: input521 │ ┆ R: 521 │ ┆ U: input │ ┆ E: DEVPATH=/devices/virtual/misc/uhid/0005:045E:0B22.0110/input/input521 │ ┆ E: SUBSYSTEM=input │ ┆ E: PRODUCT=5/45e/b22/513 │ ┆ E: NAME="Xbox Wireless Controller" │ ┆ E: PHYS="5c:f3:70:a4:3c:8d" │ ┆ E: UNIQ="44:16:22:3b:b1:99" │ ┆ E: PROP=0 │ ┆ E: EV=30001b │ ┆ E: KEY=7fff000000000000 1000000000000 8000000000 e080ffdf01cfffff fffffffffffffffe │ ┆ E: ABS=30627 │ ┆ E: MSC=10 │ ┆ E: FF=107030000 0 │ ┆ E: MODALIAS=input:b0005v045Ep0B22e0513-e0,1,3,4,14,15,k77,7D,7E,7F,A7,F0,130,131,132,133,134,135,136,137,138,139,13A,13B,13C,13D,13E,ra0,1,2,5,9,A,10,11,m4,lsf50,51,58,59,5A,60,w │ ┆ E: USEC_INITIALIZED=1413683175736 │ ┆ E: ID_INPUT=1 │ ┆ E: ID_INPUT_KEY=1 │ ┆ E: ID_INPUT_KEYBOARD=1 │ ┆ E: ID_BUS=bluetooth │ ┆ E: TAGS=:seat: │ ┆ E: CURRENT_TAGS=:seat: │ ├─event257 │ │ ┆ P: /devices/virtual/misc/uhid/0005:045E:0B22.0110/input/input521/event257 │ │ ┆ M: event257 │ │ ┆ R: 257 │ │ ┆ U: input │ │ ┆ D: c 13:257 │ │ ┆ N: input/event257 │ │ ┆ L: 0 │ │ ┆ E: DEVPATH=/devices/virtual/misc/uhid/0005:045E:0B22.0110/input/input521/event257 │ │ ┆ E: SUBSYSTEM=input │ │ ┆ E: DEVNAME=/dev/input/event257 │ │ ┆ E: MAJOR=13 │ │ ┆ E: MINOR=257 │ │ ┆ E: USEC_INITIALIZED=1413683175781 │ │ ┆ E: ID_INPUT=1 │ │ ┆ E: ID_INPUT_KEY=1 │ │ ┆ E: ID_INPUT_KEYBOARD=1 │ │ ┆ E: ID_BUS=bluetooth │ │ ┆ E: LIBINPUT_DEVICE_GROUP=5/45e/b22:5c:f3:70:a4:3c:8d │ │ ┆ E: TAGS=:power-switch: │ │ ┆ E: CURRENT_TAGS=:power-switch: │ └─js1 │ ┆ P: /devices/virtual/misc/uhid/0005:045E:0B22.0110/input/input521/js1 │ ┆ M: js1 │ ┆ R: 1 │ ┆ U: input │ ┆ D: c 13:1 │ ┆ N: input/js1 │ ┆ L: 0 │ ┆ E: DEVPATH=/devices/virtual/misc/uhid/0005:045E:0B22.0110/input/input521/js1 │ ┆ E: SUBSYSTEM=input │ ┆ E: DEVNAME=/dev/input/js1 │ ┆ E: MAJOR=13 │ ┆ E: MINOR=1 │ ┆ E: USEC_INITIALIZED=1413683175813 │ ┆ E: ID_INPUT=1 │ ┆ E: ID_INPUT_KEY=1 │ ┆ E: ID_INPUT_KEYBOARD=1 │ ┆ E: ID_BUS=bluetooth ```

[Juppstein]

@chaorace udevadm info --tree does not work for me unfortunately since the --tree function only got added in version 251 and my 22.04 has version 249. But doing an --attribute-walk for /dev/input/js0 brings this:

Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

  looking at device '/devices/virtual/misc/uhid/0005:045E:0B22.0011/input/input57/js0':
    KERNEL=="js0"
    SUBSYSTEM=="input"
    DRIVER==""
    ATTR{power/control}=="auto"
    ATTR{power/runtime_active_time}=="0"
    ATTR{power/runtime_status}=="unsupported"
    ATTR{power/runtime_suspended_time}=="0"

  looking at parent device '/devices/virtual/misc/uhid/0005:045E:0B22.0011/input/input57':
    KERNELS=="input57"
    SUBSYSTEMS=="input"
    DRIVERS==""
    ATTRS{capabilities/abs}=="3003f"
    ATTRS{capabilities/ev}=="20001b"
    ATTRS{capabilities/ff}=="107030000 0"
    ATTRS{capabilities/key}=="f0 0 0 0 0 0 0 7cdb000000000000 0 0 0 0"
    ATTRS{capabilities/led}=="0"
    ATTRS{capabilities/msc}=="10"
    ATTRS{capabilities/rel}=="0"
    ATTRS{capabilities/snd}=="0"
    ATTRS{capabilities/sw}=="0"
    ATTRS{id/bustype}=="0005"
    ATTRS{id/product}=="028e"
    ATTRS{id/vendor}=="045e"
    ATTRS{id/version}=="1130"
    ATTRS{inhibited}=="0"
    ATTRS{name}=="Xbox Wireless Controller"
    ATTRS{phys}=="5c:f3:70:9b:af:3c"
    ATTRS{power/control}=="auto"
    ATTRS{power/runtime_active_time}=="0"
    ATTRS{power/runtime_status}=="unsupported"
    ATTRS{power/runtime_suspended_time}=="0"
    ATTRS{properties}=="0"
    ATTRS{uniq}=="44:16:22:03:5d:c3"

  looking at parent device '/devices/virtual/misc/uhid/0005:045E:0B22.0011':
    KERNELS=="0005:045E:0B22.0011"
    SUBSYSTEMS=="hid"
    DRIVERS=="xpadneo"
    ATTRS{country}=="00"
    ATTRS{power/control}=="auto"
    ATTRS{power/runtime_active_time}=="0"
    ATTRS{power/runtime_status}=="unsupported"
    ATTRS{power/runtime_suspended_time}=="0"

  looking at parent device '/devices/virtual/misc/uhid':
    KERNELS=="uhid"
    SUBSYSTEMS=="misc"
    DRIVERS==""
    ATTRS{power/control}=="auto"
    ATTRS{power/runtime_active_time}=="0"
    ATTRS{power/runtime_status}=="unsupported"
    ATTRS{power/runtime_suspended_time}=="0"

[chaorace]

@Juppstein Here's a substitute command that should work if --tree is unavailable: tree -L 3 /sys/devices/virtual/misc/uhid/

What we need to see is if there is a hidraw device available. For example:

[chao@chao-desktop ~]$ tree -L 3 /sys/devices/virtual/misc/uhid/ 
/sys/devices/virtual/misc/uhid/
├── 0005:045E:0B22.002F
│   ├── country
│   ├── driver -> ../../../../../bus/hid/drivers/microsoft
│   ├── hidraw
│   │   └── hidraw15
│   ├── input
│   │   └── input64
│   ├── modalias
│   ├── power
│   │   ├── autosuspend_delay_ms
│   │   ├── control
│   │   ├── runtime_active_time
│   │   ├── runtime_status
│   │   └── runtime_suspended_time
│   ├── report_descriptor
│   ├── subsystem -> ../../../../../bus/hid
│   └── uevent
├── dev
├── power
│   ├── autosuspend_delay_ms
│   ├── control
│   ├── runtime_active_time
│   ├── runtime_status
│   └── runtime_suspended_time
├── subsystem -> ../../../../class/misc
└── uevent

11 directories, 16 files

If the hidraw device is available, please use udevadm info on the path so we can see what udev tags are assigned to it. For example:

[chao@chao-desktop ~]$ udevadm info /sys/devices/virtual/misc/uhid/0005:045E:0B22.002F/hidraw/hidraw15
P: /devices/virtual/misc/uhid/0005:045E:0B22.002F/hidraw/hidraw15
M: hidraw15
R: 15
U: hidraw
D: c 243:15
N: hidraw15
L: 0
E: DEVPATH=/devices/virtual/misc/uhid/0005:045E:0B22.002F/hidraw/hidraw15
E: SUBSYSTEM=hidraw
E: DEVNAME=/dev/hidraw15
E: MAJOR=243
E: MINOR=15
E: USEC_INITIALIZED=1041086729874
E: TAGS=:uaccess:seat:
E: CURRENT_TAGS=:uaccess:seat:

[Juppstein]

/sys/devices/virtual/misc/uhid/
├── 0005:045E:0B22.001A
│   ├── country
│   ├── driver -> ../../../../../bus/hid/drivers/xpadneo
│   ├── hidraw
│   │   └── hidraw11
│   ├── input
│   │   ├── input84
│   │   ├── input85
│   │   └── input86
│   ├── modalias
│   ├── power
│   │   ├── autosuspend_delay_ms
│   │   ├── control
│   │   ├── runtime_active_time
│   │   ├── runtime_status
│   │   └── runtime_suspended_time
│   ├── report_descriptor
│   ├── subsystem -> ../../../../../bus/hid
│   └── uevent
├── 0005:05AC:024F.0018
│   ├── country
│   ├── driver -> ../../../../../bus/hid/drivers/apple
│   ├── hidraw
│   │   └── hidraw12
│   ├── input
│   │   └── input79
│   ├── modalias
│   ├── power
│   │   ├── autosuspend_delay_ms
│   │   ├── control
│   │   ├── runtime_active_time
│   │   ├── runtime_status
│   │   └── runtime_suspended_time
│   ├── power_supply
│   │   └── hid-dc:2c:26:e3:bd:54-battery
│   ├── report_descriptor
│   ├── subsystem -> ../../../../../bus/hid
│   └── uevent
├── dev
├── power
│   ├── autosuspend_delay_ms
│   ├── control
│   ├── runtime_active_time
│   ├── runtime_status
│   └── runtime_suspended_time
├── subsystem -> ../../../../class/misc
└── uevent

udevadm info /sys/devices/virtual/misc/uhid/0005:045E:0B22.001A/hidraw/hidraw11
P: /devices/virtual/misc/uhid/0005:045E:0B22.001A/hidraw/hidraw11
N: hidraw11
L: 0
E: DEVPATH=/devices/virtual/misc/uhid/0005:045E:0B22.001A/hidraw/hidraw11
E: DEVNAME=/dev/hidraw11
E: MAJOR=241
E: MINOR=11
E: SUBSYSTEM=hidraw

[chaorace]

@Juppstein Looks like all we see is the hidraw device provided by the xpadneo driver. That's a problem because what we need is the hidraw device that hid-microsoft provides. The hid-microsoft kernel module comes enabled out-of-box, even on the older kernels used by Ubuntu 22.04 LTS. If we can solve the mystery preventing hid-microsoft from loading the driver for your controller, then we can make the controller be properly configured with Steam Input.

Let's start with the most natural explanation: the hid-microsoft module might not be loaded. We can test this using the following two commands:

• ls /sys/bus/hid/drivers/
• lsmod | grep hid_microsoft.

If the module is loaded as expected, we would expect to see results similar to below:

[chao@chao-desktop ~]$ ls /sys/bus/hid/drivers/
hid-generic  hid-steam  microsoft
[chao@chao-desktop ~]$ lsmod | grep hid_microsoft
hid_microsoft          12288  0
ff_memless             20480  2 hid_steam,hid_microsoft

If the module appears to be loaded, then we'll need to assume that other kernel modules are precluding the microsoft-hid module from providing an hidraw device with your controller. I'm aware you previously confirmed that unloading xpadneo did not resolve the issue, so let's assume that multiple drivers are installed which take precedence over microsoft-hid. If that's the case, we can fix the issue using the following process:

1. Blacklist whichever module provides the current hid driver (you can safely ignore "apple")
2. Reboot
3. Invoke tree -L 3 /sys/devices/virtual/misc/uhid/ | grep driver
4. If the driver is not microsoft or "generic", repeat starting from step 1

If you make it to this point, you should repeat the check from my prior comment with tree -L 3 /sys/devices/virtual/misc/uhid/ & udevadm info [PATH]. This is what we want to see in the output of the udevadm command:

CURRENT_TAGS=:uaccess:seat:

This tag is necessary so that steam can access the hidraw device without having to be run as a different user. If you do not see this tag, you will need to create a udev rule which adds the tag to the hidraw device (example: https://github.com/ValveSoftware/steam-for-linux/issues/9310#issuecomment-2099416521). Once the rule is configured, rerun the udevadm command again -- if the tag is still missing, reboot your machine now.

Once you've verified that the hidraw device is being provided by the hid-microsoft module AND can confirm that the uaccess tag is applied to it, you should run Steam and check if the paddles are available in Steam Input. If the issue persists, then we next need to rule out SDL as a potential issue. Do this with the following steps:

1. Open Steam
2. In the toolbar, navigate to: Steam > Settings > Controller
3. In the controller menu, click "Begin Test"
4. Note the name which appears in the test menu. It should say: "Xbox One Elite 2 Controller"

Expand for example screenshot...

If you instead see something else (e.g.: Xbox 360 Controller), then the SDL configuration may need to be reset. Do this with the following steps:

1. Completely close Steam (verify w/ pgrep steam)
2. In a text editor, open ~/.steam/steam/config/config.vdf
3. Locate the line which begins in "SDL_GamepadBind"
4. Completely delete the line & save
5. Start Steam
6. Repeat previous check involving the controller test menu

If at this point you either see the wrong controller name OR you see the correct controller name but paddles remain missing from the main Steam Input UI, then your steam package is most likely using an out of date SDL. If you're using flatpak steam, try the Ubuntu Package. If you're already using the Ubuntu package, try switching between Steam update channels (it shouldn't matter which channel you switch into, but try both before giving up).

If at this point the controller paddles are still not being shown by the main Steam Input UI, then it's most likely a Steam issue which we can use this thread to bring Valve's attention to.

[Juppstein]

@chaorace There were a few additional files in modprobe.d that were placed by xpadneo that I didnt know about and I didn't see the first time around which had to be commented out. The hid_microsoft module was also not being loaded per default for me. Not sure if that is because I am using a liquorix kernel.

So I went and I forced a load via /etc/modules and the controller was now recognised as an input device. jstest-gtk also listed it as an XBOX Wireless Controller with 8 axis and 15 buttons although the paddles were not listed as working or responding.

Going through the log I found the following stuff:

syslog:

Jun 11 12:04:31 HTPC systemd-modules-load[649]: Inserted module 'hid_microsoft'

Jun 11 12:54:19 HTPC kernel: input: Xbox Wireless Controller as /devices/virtual/misc/uhid/0005:045E:0B22.000E/input/input41 Jun 11 12:54:19 HTPC kernel: microsoft 0005:045E:0B22.000E: input,hidraw12: BLUETOOTH HID v5.15 Gamepad [Xbox Wireless Controller] on 5c:f3:70:9b:af:3c Jun 11 12:54:19 HTPC systemd-udevd[5165]: js0: Process '/usr/bin/jscal-restore /dev/input/js0' failed with exit code 1.

Kernel Log:

Jun 11 12:54:19 HTPC kernel: input: Xbox Wireless Controller as /devices/virtual/misc/uhid/0005:045E:0B22.000E/input/input41 Jun 11 12:54:19 HTPC kernel: microsoft 0005:045E:0B22.000E: input,hidraw12: BLUETOOTH HID v5.15 Gamepad [Xbox Wireless Controller] on 5c:f3:70:9b:af:3c

The result of the udevadm queries

~$ tree -L 3 /sys/devices/virtual/misc/uhid/ & udevadm info /sys/devices/virtual/misc/uhid/0005:045E:0B22.000D/hidraw/hidraw12
[1] 4883
/sys/devices/virtual/misc/uhid/
├── 0005:045E:0B22.000D
│   ├── country
│   ├── driver -> ../../../../../bus/hid/drivers/microsoft
│   ├── hidraw
│   │   └── hidraw12
│   ├── input
│   │   └── input40
│   ├── modalias
│   ├── power
│   │   ├── autosuspend_delay_ms
│   │   ├── control
│   │   ├── runtime_active_time
│   │   ├── runtime_status
│   │   └── runtime_suspended_time
│   ├── report_descriptor
│   ├── subsystem -> ../../../../../bus/hid
│   └── uevent
├── 0005:05AC:024F.000C
│   ├── country
│   ├── driver -> ../../../../../bus/hid/drivers/apple
│   ├── hidraw
│   │   └── hidraw11
│   ├── input
│   │   └── input39
│   ├── modalias
│   ├── power
│   │   ├── autosuspend_delay_ms
│   │   ├── control
│   │   ├── runtime_active_time
│   │   ├── runtime_status
│   │   └── runtime_suspended_time
│   ├── power_supply
│   │   └── hid-dc:2c:26:e3:bd:54-battery
│   ├── report_descriptor
│   ├── subsystem -> ../../../../../bus/hid
│   └── uevent
├── dev
├── power
│   ├── autosuspend_delay_ms
│   ├── control
│   ├── runtime_active_time
│   ├── runtime_status
│   └── runtime_suspended_time
├── subsystem -> ../../../../class/misc
└── uevent

20 directories, 25 files
P: /devices/virtual/misc/uhid/0005:045E:0B22.000D/hidraw/hidraw12
N: hidraw12
L: 0
E: DEVPATH=/devices/virtual/misc/uhid/0005:045E:0B22.000D/hidraw/hidraw12
E: DEVNAME=/dev/hidraw12
E: MAJOR=241
E: MINOR=12
E: SUBSYSTEM=hidraw

[1]+  Done                    tree -L 3 /sys/devices/virtual/misc/uhid/

With that I went into Steam and the controller was recognized as an XBOX One controller, but still no paddles to configure. So I went and reactivated the uaccess tag rule in udev/rules.d and removed the SDL lines in the steam config again. Now when I switch on the controller and start Steam the controller is still shown as an XBox One controller but lo and behold the paddles are there in both the layout view as well as in the game config page for the controller.

I then took the game Dustforce for a spin and assigned some keyboard commands to the paddles, which worked as intended in-game.

[chaorace]

@Juppstein Joy! In that case, shall we consider this issue closed?

[Juppstein]

@chaorace we shall

[chaorace]

Err... I didn't say that to be snarky @Juppstein. I was suggesting clicking on the "Close issue" button which is available to you as the original author of this issue :sweat_smile:

[Juppstein]

@chaorace 😂 I didn't forget about it, but I got dragged away and didn't have time to close afterwards. But thanks for reminding me 😁

[Juppstein]

We can close this. The controller is now functional including the back paddles in steam beta following the instructions given in the thread.

[jjpe]

Can confirm. After performing the analog of requisite steps on NixOS, the paddles work for me as well.

Those analog steps on NixOS are:

1. Add this to /etc/nixos/configuration.nix:

   boot.kernelModules = [
   "hid_microsoft" # Xbox One Elite 2 controller driver preferred by Steam
   ];
   boot.blacklistedKernelModules = [ "hid_xpadneo" ]; # This might interfere with the preferred driver if not blocked
   
   services.udev.packages = [
   (pkgs.writeTextFile {
    name = "xbox-one-elite-2-udev-rules";
    text = ''KERNEL=="hidraw*", TAG+="uaccess"'';
    destination = "/etc/udev/rules.d/60-xbox-elite-2-hid.rules";
   })
   ];

The normal way (via services.udev.extraRules) won't work because the udev rule will be loaded too late to matter. The 60- filename prefix is intended to match /etc/udev/rules.d/60-steam-input.rules, which means that those rules will be loaded at roughly the same time as the one just added.

2. Follow the part in this comment about ~/.steam/steam/config/config.vdf, as any old configs might interfere.

3. Reboot your machine

4. Start Steam

5. At this point it the controller should be properly recognized as Xbox One Elite 2 Controller and have, among other things, the 4 back paddles available for remapping and use in games.

[chaorace]

On NixOS, blacklisting hid_xpadneo might be overkill because it's an external module and not included in config.boot.kernelModules (see also: hardware.xpadneo.enable). It certainly can't hurt... just worth pointing out to hopefully avoid starting a cargo cult