steam-for-linux
steam-for-linux copied to clipboard
ValveSoftware
Xbox Elite 2 controller paddles not exposed to Steam Input UI
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:
- Connect controller via Bluetooth
- Start Steam in either BPM or standard view
- Go to either Settings/Controller or to controller settings in a game. Paddles are not exposed to controller mapping config.
Hello @Juppstein, this is most likely an upstream SDL or xpadneo issue.
Possible duplicate of #8463.
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.
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)?
@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.
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.
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 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.
@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
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.
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.
@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)
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:
@jjpe Interesting. What does Steam report for the paddle inputs in the device test menu?
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?
@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.
@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?
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.
@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.
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 :)
@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
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?
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.
@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
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?
@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?
It's been a little while since the previous post. If at all possible would you mind taking a look @kisak-valve ?
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
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.
Steam Support Requested I post here
https://steamcommunity.com/app/1675200/discussions/1/4208120159995460102/
I just hope it gets fixed soon