Wrong mapping after arch update

[AlexNomadrg]

Version of xpadneo

Controller Model

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

Connection mode

• [x] Bluetooth connection
• [x] 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:

• [x] Steam Proton games are having issues
• [x] 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
  • [x] I don't use Lutris, Bottles, wine or did not try
• [ ] Linux-native games are having issues
  • [x] 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
• [x] Running gamepad-tool is showing issues (post console output below)
  • [ ] I don't have this tool everything works fine except down button

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

Severity / Impact

• [x] I've read the docs and the bug reporting instructions
• [ ] I've applied the latest firmware update to the controller
• [x] I've tried disabling or running without above mentioned software
• [ ] It does not work at all
• [x] 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

My gamepad's mapping is wrong after i updated my system. I have xpadneo installed as aur package. I also tried installing it from source but that didn't fix the issue.

Steps to Reproduce

Install xpadneo connect xbox series x controller

Expected Behavior

Screenshots / GIFs / Videos

Video demonstrating the issue

System Information

# uname -a
Linux alexpc 5.18.16-arch1-1 #1 SMP PREEMPT_DYNAMIC Wed, 03 Aug 2022 11:25:04 +0000 x86_64 GNU/Linux

# xxd -c20 -g1 /sys/module/hid_xpadneo/drivers/hid:xpadneo/0005:045E:*/report_descriptor | tee >(cksum)

Controller and Bluetooth Information

https://termbin.com/dk4d

https://termbin.com/xhjf

Additional Context

[kakra]

Gamepad Tester in Chrome is known broken, it should work in Firefox. For games, please disable Steam Input. There will come a fix in v0.10 or v0.11, see #286

[AlexNomadrg]

It is firefox on my video. I've already disabled steam input

[SpidFightFR]

I also have this issue with my Xbox Series X/S controller.

With cable connection it works great, but when i switch to bluetooth, mappings go crazy. I also tried to unpair re-pair the controller, reinstalling the module and disabling steam input.

Nothing worked: it comes from xpadneo.

[joickle]

I was able to fix my button mappings on Arch by adding SDL_JOYSTICK_HIDAPI=0 to my environment variables as described here.

[SpidFightFR]

I was able to fix my button mappings on Arch by adding SDL_JOYSTICK_HIDAPI=0 to my environment variables as described here.

hello, thanks for your replay, tho it doesn't seem to work on my pc...

[kakra]

@SpidFightFR Try disabling Steam Input for Xbox controllers in Steam. Almost no game explicitly needs Steam Input to detect the controller (there are only a very few). Also, check if the hidraw device created by xpadneo has read permissions - it should not. It seems there are some rogue udev rules out there that enable hidraw permissions unconditionally.

[SpidFightFR]

@kakra hello, steam input is plain disabled for the game i’m trying (Devil may cry 5), it changed nothing… Tho for the second part, i didn’t try it yet.

[kakra]

DMC-5 worked fine for me: Steam Input disabled and hidraw permissions revoked - just revoking the permissions is probably enough as it disabled the broken hidraw path in SDL (SDL doesn't honor our HID descriptor when bypassing the driver via hidraw).

[SpidFightFR]

DMC-5 worked fine for me: Steam Input disabled and hidraw permissions revoked - just revoking the permissions is probably enough as it disabled the broken hidraw path in SDL (SDL doesn't honor our HID descriptor when bypassing the driver via hidraw).

Well DMC5 worked just fine until now, i’m really confused…

[SpidFightFR]

Crazy thing: when i connect the controller with bluetooth, it goes crazy, but when i connect it in usb, it goes normal again…

[RTbecard]

I'm also suffering from this exact issue. Everything worked great until I installed an update that must have come out within the past 2 weeks I believe. I'm on pop_os, Kernel version 5.19.0-76051900-generic. Setting SDL_JOYSTICK_HIDAPI=0 did not help, and as far as I can tell, the hidraw device created after my controller connects with bluetooth does not have read permissions (I just did la /dev/hidraw*, and the new hidraw entry had no read permissions).

[cHunter789]

For me xpandeo stop working after an upgrade Kubuntu from 20.04 to 22.04.01 With kernel driver mapping is OK.

[kakra]

I just did la /dev/hidraw*, and the new hidraw entry had no read permissions

This may not be sufficient, the devices may have ACLs applied instead of just plain unix permissions only: Try getfacl /dev/hidraw*

[RTbecard]

getfacl /dev/hidraw* also reports no read permissions for the new device (3) which appears after turning on my controller.

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

Let me know if there's anything else I can pass along to help trouble shoot this.

[kakra]

For me xpandeo stop working after an upgrade Kubuntu from 20.04 to 22.04.01 With kernel driver mapping is OK.

It's probably not a kernel issue because I'm using kernel 5.15 LTS (as you asked especially for kernel 5.13+ before the edit). I think it's rather a udev rule issue, Kubuntu may ship with Steam Input udev rules which enable hidraw access.

The original file is here: https://github.com/ValveSoftware/steam-devices/blob/master/60-steam-input.rules

But it seems like some distributions add more controllers to it although those actually don't need hidraw access. So you could inspect your udev rules to inspect if they add hidraw access for Xbox controllers.

Another pitfall may be RGB and QMK software which (at least in versions a few months old) adds hidraw permissions to all HID devices unconditionally. Uninstalling such software (at least for the sake of confirming a conflict) could help, too.

For the issue of @RTbecard I am not sure what actually may be happening.

@RTbecard Please confirm, the hidraw device you're inspecting is actually the one created by xpadneo by looking at the dmesg output after turning the controller on.

Please also let me know which SDL version you are running so I can check if there are any incompatible changes in SDL.

[SpidFightFR]

If that can help, i use SDL2 version 2.24.0-1.

[IvanDobysh]

Same issue for me on Arch. Please let me know what I can do to help with finding the problem.

Edit: Connecting by USB isn't fixing the issue. Edit2: SDL_JOYSTICK_HIDAPI=0 also not helping. Edit3: SDL2 version 2.24.0-1.

[googleson78]

Same issue as OP (seems to be the exact same "swapped mapping")

Disabling steam input, SDL_JOYSTICK_HIDAPI=0 don't help. The new hidraw device that appears after connecting has rw- --- ---. Disabling the rw doesn't help either.

I'd be happy to provide any additional information.

Info:

> blademaster :: ~ » uname -a
Linux blademaster 5.15.63 #1-NixOS SMP Thu Aug 25 09:40:49 UTC 2022 x86_64 GNU/Linux

> blademaster :: ~ » 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

[RTbecard]

Here's a confirmation of the no read access hidraw listing. Also my libsdl2 is version is 2.0.20

$ sudo dmesg | grep hidraw
[   12.347731] hid-generic 0003:04D9:A06B.0001: input,hidraw0: USB HID v1.10 Keyboard [E-Signal GIGABYTE Keyboard] on usb-0000:00:14.0-4.2/input0
[   12.407947] hid-generic 0003:04D9:A06B.0002: input,hiddev0,hidraw1: USB HID v1.10 Device [E-Signal GIGABYTE Keyboard] on usb-0000:00:14.0-4.2/input1
[   12.467746] hid-generic 0003:04D9:A06B.0003: input,hidraw2: USB HID v1.10 Keyboard [E-Signal GIGABYTE Keyboard] on usb-0000:00:14.0-4.2/input2
[  284.187346] hid-generic 0005:046D:B025.0004: input,hidraw3: BLUETOOTH HID v0.15 Mouse [MX Anywhere 3] on 84:c5:a6:75:94:54
[  344.152185] hid-generic 0005:045E:0B13.0005: input,hidraw4: BLUETOOTH HID v5.13 Gamepad [Xbox Wireless Controller] on 84:c5:a6:75:94:54
[  344.249498] xpadneo 0005:045E:0B13.0005: input,hidraw4: BLUETOOTH HID v11.30 Gamepad [Xbox Wireless Controller] on 84:c5:a6:75:94:54
[  345.405421] xpadneo 0005:045E:0B13.0005: input,hidraw4: BLUETOOTH HID v11.30 Gamepad [Xbox Wireless Controller] on 84:c5:a6:75:94:54
$ getfacl /dev/hidraw4                    
getfacl: Removing leading '/' from absolute path names
# file: dev/hidraw4
# owner: root
# group: root
user::---
group::---
other::---
$ apt list libsdl2-2.0-0 
Listing... Done
libsdl2-2.0-0/jammy-updates,now 2.0.20+dfsg-2ubuntu1.22.04.1 amd64 [installed,automatic]
libsdl2-2.0-0/jammy-updates,now 2.0.20+dfsg-2ubuntu1.22.04.1 i386 [installed,automatic]

My swapped controls are the exact same as in the video posted, notably, the left trigger is mapped to x axis of r-stick. This issue is both in all steam games and web-based gamepad testers in firefox.

[kakra]

Does the behavior change if you load the xpadneo module after a reboot but before connecting the controller?

[googleson78]

Does the behavior change if you load the xpadneo module after a reboot but before connecting the controller?

Nope, same thing.

[Snomwan]

Yeah I've been having this exact issue.

[RTbecard]

Does the behavior change if you load the xpadneo module after a reboot but before connecting the controller?

Just tried manually loading with modprobe before connecting with bluetooth (see below, let me know if I'm doing this wrong). The issue still persists.

$ dkms status      
hid-xpadneo/v0.9-123-g94cf8f1, 5.19.0-76051900-generic, x86_64: installed
nvidia/515.48.07, 5.18.10-76051810-generic, x86_64: installed
nvidia/515.48.07, 5.19.0-76051900-generic, x86_64: installed
system76/1.0.14~1643391291~22.04~78ede46, 5.17.5-76051705-generic, x86_64: installed
system76/1.0.14~1643391291~22.04~78ede46, 5.18.10-76051810-generic, x86_64: installed
system76/1.0.14~1643391291~22.04~78ede46, 5.19.0-76051900-generic, x86_64: installed
system76_acpi/1.0.2~1659568831~22.04~a88dcce, 5.18.10-76051810-generic, x86_64: installed (original_module exists)
system76_acpi/1.0.2~1659568831~22.04~a88dcce, 5.19.0-76051900-generic, x86_64: installed (original_module exists)
system76-io/1.0.2~1655490480~22.04~0217576, 5.17.5-76051705-generic, x86_64: installed
system76-io/1.0.2~1655490480~22.04~0217576, 5.18.10-76051810-generic, x86_64: installed
system76-io/1.0.2~1655490480~22.04~0217576, 5.19.0-76051900-generic, x86_64: installed
virtualbox/6.1.36, 5.18.10-76051810-generic, x86_64: installed
virtualbox/6.1.36, 5.19.0-76051900-generic, x86_64: installed
$ lsmod | grep xpad
$ sudo modprobe hid-xpadneo
[sudo] password for james: 
$ lsmod | grep xpad        
hid_xpadneo            24576  0
ff_memless             24576  1 hid_xpadneo
hid                   155648  4 usbhid,hid_generic,hid_xpadneo,uhid

[kakra]

So we should not be seeing the udev bug which was previously seen (and fixed in https://github.com/atar-axis/xpadneo/commit/b6c070831e418b0cfc4e604e4f6687530d66da0a).

But your version looks awkward: hid-xpadneo/v0.9-123-g94cf8f1 isn't current master, which is v0.9-121-g727a84f. So you are on a completely different branch, and I don't even know if you're ahead or behind commit https://github.com/atar-axis/xpadneo/commit/b6c070831e418b0cfc4e604e4f6687530d66da0a.

Where did you get this xpadneo version from? Doesn't look like any of the pull requests, and probably neither one of the forks here on Github.

[SpidFightFR]

So we should not be seeing the udev bug which was previously seen (and fixed in b6c0708).

But your version looks awkward: hid-xpadneo/v0.9-123-g94cf8f1 isn't current master, which is v0.9-121-g727a84f. So you are on a completely different branch, and I don't even know if you're ahead or behind commit b6c0708.

Where did you get this xpadneo version from? Doesn't look like any of the pull requests, and probably neither one of the forks here on Github.

my version of xpadneo is hid-xpadneo/0.9.r121.g727a84f, i got it from the xpadneo-dkms-git aur package. I hope it can help...

[RTbecard]

But your version looks awkward: hid-xpadneo/v0.9-123-g94cf8f1 isn't current master, which is v0.9-121-g727a84f. So you are on a completely different branch, and I don't even know if you're ahead or behind commit b6c0708.

Ah, sorry. Yes, I was using a local fork which had merged with the latest master. When I originally cloned the master branch from here, the VERSION file was missing which broke the install script. I manually made this on my local repo, commited the change, and ran the install script. When updating xpadneo later on, I just merged the latest changes into my modified local repo. This should explain any weird version changes in my console output.

To eliminate any confusion, I've removed my local repo and installed the current master. I reran the exercise, and the issue still persists.

$ dkms status | grep xpad    
hid-xpadneo/v0.9-121-g727a84f, 5.19.0-76051900-generic, x86_64: installed
$ lsmod | grep xpad
$ sudo modprobe hid-xpadneo
[sudo] password for james: 
$  lsmod | grep xpad    
hid_xpadneo            24576  0
ff_memless             24576  1 hid_xpadneo
hid                   155648  4 usbhid,hid_generic,hid_xpadneo,uhid

[kakra]

I reran the exercise, and the issue still persists.

The installer script will generate the version file on demand - as long as you added the trust path option. The current installer script will tell you which command to run to make the version file generation work again. It's an issue with newer git versions which fixed a security flaw in git:

• https://github.com/atar-axis/xpadneo/commit/d6b35a58f51c75bb2bbd7db0b195edfce52ddaeb

[IvanDobysh]

Well, is there anything at all we can do to help to locate the issue? Don't get me wrong, I'm not trying to push at all, but it's kinda sucks to live without gamepad :D

[SpidFightFR]

Well we can still use it, with an USB cable… but that’s so annoying…

so yeah, if i can help, too: don’t hesitate to ask!

[Snomwan]

For me I fixed it by git cloning it. Maybe it was an update that fixed it IDK I just know that something fixed it for me.