Wrong mapping for buttons

spacecowgirl314 commented 2 years ago

Version of xpadneo

0.9.r96.g4fd620c-1 xpad-neo-dkms-git from chaotic-aur

Controller Model

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

Connection mode

[x] Bluetooth connection
[ ] Xbox Dongle connection (not yet supported)
[ ] USB cable (not yet supported)

Installed Software

[x] Steam Input (enabled by default via Steam Desktop client)
[ ] Steam Link (usually via Raspberry Pi or other micro computers)
[ ] xow (alternative driver using the Xbox dongle)
[ ] Anti-Micro (may affect button mappings)
[ ] netstick (shares input devices via network similar to Steam Link)
[ ] xboxdrv (user-space gamepad driver)

Severity / Impact

[x] I've read the docs and the bug reporting instructions
[ ] I've applied the latest firmware update to the controller
[ ] 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 ...
[x] It's too complicated
[ ] Fantastic work but ...
[ ] I can code and I want to help

Describe the Bug

The button mapping is almost entirely wrong.

Steps to Reproduce

Connect via bluetooth.

Expected Behavior

Button mapping should be the same as not using xpadneo.

Screenshots / GIFs / Videos

System Information

# uname -a
Linux Poipole 5.17.1-zen1-1-zen #1 ZEN SMP PREEMPT Mon, 28 Mar 2022 21:56:46 +0000 x86_64 GNU/Linux

# 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 24 02 15 00 25 01 95 01 75 01 81  u........$...%...u..
000000b4: 02 15 00 25 00 75 07 95 01 81 03 05 0c 09 01 85 02 a1 01 05  ...%.u..............
000000c8: 0c 0a 23 02 15 00 25 01 95 01 75 01 81 02 15 00 25 00 75 07  ..#...%...u.....%.u.
000000dc: 95 01 81 03 c0 05 0f 09 21 85 03 a1 02 09 97 15 00 25 01 75  ........!........%.u
000000f0: 04 95 01 91 02 15 00 25 00 75 04 95 01 91 03 09 70 15 00 25  .......%.u......p..%
00000104: 64 75 08 95 04 91 02 09 50 66 01 10 55 0e 15 00 26 ff 00 75  du......Pf..U...&..u
00000118: 08 95 01 91 02 09 a7 15 00 26 ff 00 75 08 95 01 91 02 65 00  .........&..u.....e.
0000012c: 55 00 09 7c 15 00 26 ff 00 75 08 95 01 91 02 c0 05 06 09 20  U..|..&..u.........
00000140: 85 04 15 00 26 ff 00 75 08 95 01 81 02 c0                    ....&..u......
3560615638 1558

Controller and Bluetooth Information

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

Additional Context

Please let me know any other way I can help.

kakra commented 2 years ago

Please check the permissions of the xpadneo rawhid device. Did you install RGB software or run qmk?

It is most likely that Steam Input has access to the raw hid device. If it does, it uses SDL to directly read the raw device bypassing xpadneo. And SDL has wrong assumptions about our HID report format.

First test would be to see if the kernel layers itself see the right mappings. Use evtest to verify the mapping. Everything else (jsdev, SDL, Steam Input) goes through that layer, so it's the lowest layer that has to be correct. If it is, try disabling Steam Input next. If this doesn't affect the mapping (or rather, doesn't correct it), the problem may come from SDL.

Chances are that SDL probably works in rawhid mode. I'm pretty convinced SDL should not try to do that (or at least, only as a fallback) but still Proton et al ship with those patches. Look at dmesg to find the correct rawhid device number after connecting the gamepad, then look at the permissions of /dev/hidraw##, it's probably rw for everyone. If you run chmod a-rwx /dev/hidraw##, the problem should be fixed.

Our udev rule ships with settings to disable permissions for the rawhid device but apparently, this becomes overwritten by some software with badly integrated udev rules, the most likely candidate is OpenRGB which ships with a udev rule that makes each rawhid device world readable and writable. I actually consider that a security issue but well, it is like it is currently. The way they deploy the udev rule completely prevents us from overriding that configuration.

One other issue we discovered lately is a module loading order problem. You can also try if the problem goes away if you manually modprobe hid-xpadneo before connecting the controller. This should prevent the following line:

[  750.696073] hid-generic 0005:045E:02FD.000A: input,hidraw9: BLUETOOTH HID v9.03 Gamepad [Xbox Wireless Controller] on f8:e4:e3:d5:e6:60

which indicates that hid-generic sees the controller first before we rebind the controller to hid-xpadneo. This somehow seems to confuse button mappings recently.

bpc1 commented 2 years ago

Thank you https://github.com/atar-axis/xpadneo/issues/343#issuecomment-1082516174 i finally fixed my mapping issues.

Applying:

Look at dmesg to find the correct rawhid device number after connecting the gamepad, then look at the permissions of /dev/hidraw##, it's probably rw for everyone. If you run chmod a-rwx /dev/hidraw##, the problem should be fixed.

and:

You can also try if the problem goes away if you manually modprobe hid-xpadneo before connecting the controller. fixed it

fixed it although after reboot i had to do them both again.

Removing openRGB and applying:

Look at dmesg to find the correct rawhid device number after connecting the gamepad, then look at the permissions of /dev/hidraw##, it's probably rw for everyone. If you run chmod a-rwx /dev/hidraw##, the problem should be fixed.

fixed it permanently.

Even tho hid-generic now gets loaded 1st the mapping is correct and 2nd fix is not needed anymore after removing openRGB. I guess openRGB just keeps overwriting everything after reboot. That is some bullshit.

kakra commented 2 years ago

I guess openRGB just keeps overwriting everything after reboot.

Well, they unconditionally make all hidraw devices world read and writable... They'd rather need a udev helper which checks if it is really a RGB raw device - and if it isn't, leave the device alone. Currently, they override our own rules. The qmk project has already fixed that with a helper. I'd also suggest the current practice is security nightmare because any process may spy on your keypresses (e.g. password, banking pins).

The underlying problem, tho, is an incompatibility between xpadneo and SDL when it comes to raw HID reports. This problem just uncovers what OpenRGB is doing wrong.

kakra commented 2 years ago

If I read correctly, you made an interesting observation: Loading xpadneo first prevents the wrong permission bits. It seems like OpenRGB may actually only act on device nodes that are bound to hid-generic. This doesn't solve the security issue, tho... A lot of HID devices run through hid-generic because they can and need no special driver. Even the Xbox controller work with hid-generic out of the box, although they'll report 15 buttons instead of 10-11, and two additional axes. That can confuse games unless SDL just uses hidraw mode (which it can thanks to OpenRGB).

mr-ubik commented 2 years ago

@kakra I have the same issue of wrong mapping inside Steam games when connected via bt. I do have qmk on my machine as I work with their firmware. None of the recommended steps, changing permission or running modprobe, seems to be working.

kakra commented 2 years ago

There are two other issues that you could hit: Loading the xpadneo kernel module before connecting the controller may work around this. Also, disabling Steam Input can work around it.

mr-ubik commented 2 years ago

I have tried re-installing qmk-git, after rebooting with the controller turned off I loaded the module with modprobe hid-xpadneo, but it's still all jumbled up

kakra commented 2 years ago

@mr-ubik Then your issue may be slightly different. To get started, could you look at the permissions of the hidraw device created by xpadneo? To know which is the correct device, run dmesg -W while connecting the controller, it will tell you a hidraw device name. Now run sudo getfacl /dev/hidraw## to get all applied permissions.

spacecowgirl314 commented 2 years ago

Ok, to be clear I wasn’t using Steam Input. I got confused by the template. I simply had Steam installed. I don’t have the time to respond further at the moment but when I do I’ll provide more details.

On 10 Apr 2022, at 5:08 am, Kai Krakow @.***> wrote:

@mr-ubik Then your issue may be slightly different. To get started, could you look at the permissions of the hidraw device created by xpadneo? To know which is the correct device, run dmesg -W while connecting the controller, it will tell you a hidraw device name. Now run sudo getfacl /dev/hidraw## to get all applied permissions.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.

atar-axis / xpadneo