Xbox Series X|S controller recognized as 360 controller and no inputs detected in games

[QuickArgentum]

Version of xpadneo

0.9.5

Controller Model

• Xbox One S controller
• Xbox Elite 2 controller
• Xbox Series X|S controller
• Other:

Connection mode

• Bluetooth connection
• USB cable (not yet supported)
• Xbox Dongle connection (not yet supported)

Installed Software

• Anti-Micro (may affect button mappings)
• OpenRGB (may mess up mappings and rumble stability)
• Steam Input (enabled by default via Steam Desktop client)
• Steam Link (usually via Raspberry Pi or other micro computers)
• devices with QMK firmware (may affect udev rules, similar to OpenRGB)
• netstick (shares input devices via network similar to Steam Link)
• xboxdrv (user-space gamepad driver)
• xone (kernel-space gamepad driver using the Xbox dongle or USB)
• xow (alternative driver using the Xbox dongle)

Protocol Information

Please help us identify at which layer the problem can be found if you want
to report mapping errors or if the controller fails to be detected:

• Steam Proton games are having issues
• Steam Linux-native games are having issues
  • I don't use Steam or did not try
• games running through Lutris, wine and/or Bottles are having issues
  • I don't use Lutris, Bottles, wine or did not try
• Linux-native games are having issues
  • I don't use native games or did not try
• Other software is having issues (describe software and issues below)
• Running evtest is showing issues (describe the issues below)
  • Keep in mind that BTN_NORTH and BTN_WEST are intentionally swapped
• Running jstest is showing issues (describe the issues below)
  • I don't have this tool or don't know how to use it
• Running gamepad-tool is showing issues (post console output below)
  • I don't have this tool

Please describe how it is failing below in the next sections.

Severity / Impact

• I've read the docs and the bug reporting instructions
• I've applied the latest firmware update to the controller
• I've tried disabling or running without above mentioned software
• It does not work at all
• It used to work in a previous version
• It mostly works but sometimes it doesn't
• I found a work-around
• I probably didn't figure it all out but it's too early to give up
• I don't know how to ...
• It's too complicated
• Fantastic work but ...
• I can code and I want to help

Describe the Bug

Xbox Series X|S controller with updated firmware is connected via a Bluetooth adapter.
evtest and jstest identify the controller and recognize its inputs correctly, however gamepad-tool, Steam settings, Retroarch and other software identifies it as an "Xbox 360 Controller" and does not react to any of its buttons or axis.
Steam Input is disabled for everything.
In fact, the only game that works that I've tried is PICO-8

Steps to Reproduce

Turn on, pair and connect an Xbox Wireless Controller (with up to date firmware) via a Bluetooth adapter. Launch a game or software which supports controllers.

Expected Behavior

Games and software which support controllers identify the controller as the proper model and/or at least recognize its inputs (so you can navigate the interface, play the game, etc.)

Would really appreciate any help, thank you

Screenshots / GIFs / Videos

System Information

# uname -a
Linux luna-pc 6.1.0-17-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.69-1 (2023-12-30) x86_64 GNU/Linux

# neofetch
       _,met$$$$$gg.          luna@luna-pc 
    ,g$$$$$$$$$$$$$$$P.       ------------ 
  ,g$$P"     """Y$$.".        OS: Debian GNU/Linux 12 (bookworm) x86_64 
 ,$$P'              `$$$.     Kernel: 6.1.0-17-amd64 
',$$P       ,ggs.     `$$b:   Uptime: 30 mins 
`d$$'     ,$P"'   .    $$$    Packages: 3342 (dpkg), 44 (flatpak) 
 $$P      d$'     ,    $$P    Shell: bash 5.2.15 
 $$:      $$.   -    ,d$$'    Resolution: 2560x1440 
 $$;      Y$b._   _,d$P'      DE: GNOME 43.9 
 Y$$.    `.`"Y$$$$P"'         WM: Mutter 
 `$$b      "-.__              WM Theme: Adwaita 
  `Y$$                        Theme: Adwaita [GTK2/3] 
   `Y$$.                      Icons: Adwaita [GTK2/3] 
     `$$b.                    Terminal: gnome-terminal 
       `Y$$b.                 CPU: AMD Ryzen 7 3700X (16) @ 4.050GHz 
          `"Y$b._             GPU: NVIDIA GeForce RTX 2060 SUPER 
              `"""            Memory: 4783MiB / 31991MiB 

# xxd -c20 -g1 /sys/module/hid_xpadneo/drivers/hid:xpadneo/0005:045E:*/report_descriptor | tee >(cksum)
00000000: 05 01 09 05 a1 01 85 01 09 01 a1 00 09 30 09 31 15 00 27 ff  .............0.1..'.
00000014: ff 00 00 95 02 75 10 81 02 c0 09 01 a1 00 09 33 09 34 15 00  .....u.........3.4..
00000028: 27 ff ff 00 00 95 02 75 10 81 02 c0 05 01 09 32 15 00 26 ff  '......u.......2..&.
0000003c: 03 95 01 75 0a 81 02 15 00 25 00 75 06 95 01 81 03 05 01 09  ...u.....%.u........
00000050: 35 15 00 26 ff 03 95 01 75 0a 81 02 15 00 25 00 75 06 95 01  5..&....u.....%.u...
00000064: 81 03 05 01 09 39 15 01 25 08 35 00 46 3b 01 66 14 00 75 04  .....9..%.5.F;.f..u.
00000078: 95 01 81 42 75 04 95 01 15 00 25 00 35 00 45 00 65 00 81 03  ...Bu.....%.5.E.e...
0000008c: 05 09 19 01 29 0c 15 00 25 01 75 01 95 0c 81 02 15 00 25 00  ....)...%.u.......%.
000000a0: 75 01 95 04 81 03 05 0c 0a b2 00 15 00 25 01 95 01 75 01 81  u............%...u..
000000b4: 02 15 00 25 00 75 07 95 01 81 03 05 0f 09 21 85 03 a1 02 09  ...%.u........!.....
000000c8: 97 15 00 25 01 75 04 95 01 91 02 15 00 25 00 75 04 95 01 91  ...%.u.......%.u....
000000dc: 03 09 70 15 00 25 64 75 08 95 04 91 02 09 50 66 01 10 55 0e  ..p..%du......Pf..U.
000000f0: 15 00 26 ff 00 75 08 95 01 91 02 09 a7 15 00 26 ff 00 75 08  ..&..u.........&..u.
00000104: 95 01 91 02 65 00 55 00 09 7c 15 00 26 ff 00 75 08 95 01 91  ....e.U..|..&..u....
00000118: 02 c0 c0                                                     ...
2986910699 1363

Controller and Bluetooth Information

xpadneo-btmon.txt
xpadneo-dmesg.txt
xpadneo-lsusb.txt

[kakra]

evtest and jstest identify the controller and recognize its inputs correctly, however gamepad-tool, Steam settings, Retroarch and other software identifies it as an "Xbox 360 Controller" and does not react to any of its buttons or axis.

gamepad-tool correctly sees the controller here, the "Xbox 360 Controller" is not meaningful, the only thing that counts is the features SDL detects.

Steam settings also works correctly here, although what you see here is only meaningful to Steam Input.

This covers all the usual input layers: joydev, evdev, SDL2 (Steam Input is actually SDL2 for Proton games, mapped via a virtual controller ID).

So I wonder what the difference is on your computer. It looks like the SDL2 layer is broken for you.

Please check the permissions of /dev/hidraw6 (taken from your dmesg, it changes every time you re-connect the controller), it should look like this:

getfacl /dev/hidraw6

# file: dev/hidraw6
# owner: root
# group: root
user::rw-
group::---
other::---

If it doesn't and assigns ownership to a different user or group, or assigns different read/write permissions, or adds ACLs for your desktop user, then your udev rules are broken because they ignore xpadneo's own rules. We've seen issues like that in the past with OpenRGB and QMK which happily assign write permissions to "other" for all hidraw devices, no matter if they manage it or don't.

If this is the case, try revoking any permissions from the device and test again (chmod a-rwx /dev/hidraw6). If this fixes the problem for you, we need to figure out which udev rules are causing the problem.

OTOH, even if SDL2 uses the hidraw device, you should still see input although some buttons may be swapped or not working - but at least some buttons would work. Without hidraw, SDL2 uses the evdev device.

evdev works (and for that matter, joydev does too because the kernel builds it from the evdev device), so it's not a kernel issue and not an xpadneo issue, there's a problem in user-space on your system.

Chances are that gamepad-tool found some broken legacy mappings. You didn't post the terminal output of the tool, so I cannot say what the difference may be. Using xpadneo with SDL2 expects that no custom mapping has been defined, unfortunately, there have been many forum guides in the past which suggested exactly this without even asking if the controller works properly without any mappings.

[kakra]

Can you retry with the latest git version?

[CaptainCoward]

I stumbled over this since my "share" button doesn't seem to work as it should (doesn't take screenshots). Steam also claims it is a 360 Pad though i have the pad working.
I ran getfacl and would get

# file: dev/hidraw6
# owner: root
# group: root
user::---
group::---
other::---

When checking the journal i get the message
linux (udev-worker)[15843]: 0005:045E:0B13.0007: /usr/lib/udev/rules.d/60-xpadneo.rules:1 Failed to write ATTR{/sys/devices/virtual/misc/uhid/0005:045E:0B13.0007/[drivers/hid:xpadneo]bind}>

I have ignored this for a long time since i thoughtt it wouldn't really matter. Is this still related?

[kakra]

I have ignored this for a long time since i thoughtt it wouldn't really matter. Is this still related?

This warning is okay if the kernel automatically binds the driver to xpadneo... Then binding won't work because the device is already bound to the correct driver.

If this shows a result, binding worked correctly:

ls -ald /sys/module/hid_xpadneo/drivers/hid:xpadneo/0005:045E:*/report_descriptor

For "F12" to work, you need the Git version of xpadneo. The v0.9 branch reports the button in a way which is not compatible with Steam, and games will probably ignore it.

You can use evtest to check if the button works and how it works. With v0.9.x, you will see a single device for your controller, and the button reports as a gaming button. With upcoming v0.10 (git master), evtest will see three devices for your gamepad, one is a keyboard. Choose the keyboard device, press "Share", it should say "F12" in the log.

pre-v0.10 is mostly stable, you can use it, if your distribution offers a git version of xpadneo. But some more time is needed for code redesign and some feature integration (mouse mode, to use your controller on desktop from the couch). But you can already use the functions that are there.

[mystchonky]

Hello! I am facing the same issues. The only difference being that I run Arch and not Debian. How would I find out what is causing problems ?

[WaffleLapkin]

I'm also an Arch Linux and since a couple months I seem to be getting wrong permissions on the hidraw file:

: ~; getfacl /dev/hidraw4
getfacl: Removing leading '/' from absolute path names
# file: dev/hidraw4
# owner: root
# group: root
user::---
user:waffle:rw-
group::---
mask::rw-
other::---

(hidraw4 taken from dmesg)

sudo chmod a-rwx /dev/hidraw4 indeed fixes the issue.

If this fixes the problem for you, we need to figure out which udev rules are causing the problem.

How would one do at?

[kakra]

@WaffleLapkin This may be caused by OpenRGB... Try uninstalling it and see if the issue persists. OpenRGB is one known software which overrides our udev rule fixing permissions. But this seems to be different from the previous comments, so you're likely seeing a different issue if driver binding works for you.

[kakra]

How would one do at?

Before connecting the controller, run udevadm monitor -p, then connect the controller. You'll see which parameters get changed during the udev enum process. You should try it with and without the xpadneo module already loaded.

You can find more information about the udev rules and debugging here: #461

[WaffleLapkin]

@kakra sadly those debugging suggestions did not help (I couldn't see anything suspicions). In the end I did find out that it was QMK's udevrules -- disabling those fixed the permission issue (sorry for spamming in an unrelated issue and thanks for help 💜 ).

[kakra]

Yeah, QMK is a known suspect. I actually thought they've fixed that meanwhile by looking at the device with a udev helper... I'd still be interested if we could find a way to override their rules for the devices we support.

[WaffleLapkin]

I just checked with a fresh checkout of qmk, and the rules they suggest to copy still cause problems with the controller. If it helps here is the file they suggest to add:

/etc/udev/rules.d/50-qmk.rules

# Atmel DFU
### ATmega16U2
SUBSYSTEMS=="usb", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2fef", TAG+="uaccess"
### ATmega32U2
SUBSYSTEMS=="usb", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2ff0", TAG+="uaccess"
### ATmega16U4
SUBSYSTEMS=="usb", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2ff3", TAG+="uaccess"
### ATmega32U4
SUBSYSTEMS=="usb", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2ff4", TAG+="uaccess"
### AT90USB64
SUBSYSTEMS=="usb", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2ff9", TAG+="uaccess"
### AT90USB162
SUBSYSTEMS=="usb", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2ffa", TAG+="uaccess"
### AT90USB128
SUBSYSTEMS=="usb", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2ffb", TAG+="uaccess"

# Input Club
SUBSYSTEMS=="usb", ATTRS{idVendor}=="1c11", ATTRS{idProduct}=="b007", TAG+="uaccess"

# STM32duino
SUBSYSTEMS=="usb", ATTRS{idVendor}=="1eaf", ATTRS{idProduct}=="0003", TAG+="uaccess"
# STM32 DFU
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="df11", TAG+="uaccess"

# BootloadHID
SUBSYSTEMS=="usb", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="05df", TAG+="uaccess"

# USBAspLoader
SUBSYSTEMS=="usb", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="05dc", TAG+="uaccess"

# USBtinyISP
SUBSYSTEMS=="usb", ATTRS{idVendor}=="1782", ATTRS{idProduct}=="0c9f", TAG+="uaccess"

# ModemManager should ignore the following devices
# Atmel SAM-BA (Massdrop)
SUBSYSTEMS=="usb", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="6124", TAG+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1"

# Caterina (Pro Micro)
## pid.codes shared PID
### Keyboardio Atreus 2 Bootloader
SUBSYSTEMS=="usb", ATTRS{idVendor}=="1209", ATTRS{idProduct}=="2302", TAG+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1"
## Spark Fun Electronics
### Pro Micro 3V3/8MHz
SUBSYSTEMS=="usb", ATTRS{idVendor}=="1b4f", ATTRS{idProduct}=="9203", TAG+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1"
### Pro Micro 5V/16MHz
SUBSYSTEMS=="usb", ATTRS{idVendor}=="1b4f", ATTRS{idProduct}=="9205", TAG+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1"
### LilyPad 3V3/8MHz (and some Pro Micro clones)
SUBSYSTEMS=="usb", ATTRS{idVendor}=="1b4f", ATTRS{idProduct}=="9207", TAG+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1"
## Pololu Electronics
### A-Star 32U4
SUBSYSTEMS=="usb", ATTRS{idVendor}=="1ffb", ATTRS{idProduct}=="0101", TAG+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1"
## Arduino SA
### Leonardo
SUBSYSTEMS=="usb", ATTRS{idVendor}=="2341", ATTRS{idProduct}=="0036", TAG+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1"
### Micro
SUBSYSTEMS=="usb", ATTRS{idVendor}=="2341", ATTRS{idProduct}=="0037", TAG+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1"
## Adafruit Industries LLC
### Feather 32U4
SUBSYSTEMS=="usb", ATTRS{idVendor}=="239a", ATTRS{idProduct}=="000c", TAG+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1"
### ItsyBitsy 32U4 3V3/8MHz
SUBSYSTEMS=="usb", ATTRS{idVendor}=="239a", ATTRS{idProduct}=="000d", TAG+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1"
### ItsyBitsy 32U4 5V/16MHz
SUBSYSTEMS=="usb", ATTRS{idVendor}=="239a", ATTRS{idProduct}=="000e", TAG+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1"
## dog hunter AG
### Leonardo
SUBSYSTEMS=="usb", ATTRS{idVendor}=="2a03", ATTRS{idProduct}=="0036", TAG+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1"
### Micro
SUBSYSTEMS=="usb", ATTRS{idVendor}=="2a03", ATTRS{idProduct}=="0037", TAG+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1"

# hid_listen
KERNEL=="hidraw*", MODE="0660", GROUP="plugdev", TAG+="uaccess", TAG+="udev-acl"

# hid bootloaders
## QMK HID
SUBSYSTEMS=="usb", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2067", TAG+="uaccess"
## PJRC's HalfKay
SUBSYSTEMS=="usb", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="0478", TAG+="uaccess"

# APM32 DFU
SUBSYSTEMS=="usb", ATTRS{idVendor}=="314b", ATTRS{idProduct}=="0106", TAG+="uaccess"

# GD32V DFU
SUBSYSTEMS=="usb", ATTRS{idVendor}=="28e9", ATTRS{idProduct}=="0189", TAG+="uaccess"

# WB32 DFU
SUBSYSTEMS=="usb", ATTRS{idVendor}=="342d", ATTRS{idProduct}=="dfa0", TAG+="uaccess"

Maybe xpadneo could override them with more specific rules...

[kakra]

# hid_listen
KERNEL=="hidraw*", MODE="0660", GROUP="plugdev", TAG+="uaccess", TAG+="udev-acl"

Looks like this may be problematic because it doesn't check if the hidraw device is actually a supported device. It assigns the tag uaccess (and I'm not sure what udev-acl does), and this probably allows read/write access to your session for the device. Also, it assigns the plugdev group to the device which should not be needed at all for session access: udev handles this via ACLs nowadays.

Our hidraw device is not compatible with SDL currently, see #286. Thus, we have a rule in place that assigns MODE:="0600" (allowing only root to access the device, preventing later overrides).

Maybe, if changing our mode to 0000, it could prevent any ACLs from working?

Monitoring the udev events should show if a previous rule also uses := for mode, thus preventing xpadneo from setting it the way we need it.

We could also try to use TAG-="uaccess and/or TAG-="udev-acl" to actually remove those tags again.

If you find a proper way around it that we can implement in our rules, let me know. I'm planning another 0.9 release (currently mostly to finalize documentation), it would be nice if we could deploy such a fix.