atar-axis / xpadneo

Advanced Linux Driver for Xbox One Wireless Controller (shipped with Xbox One S)
https://atar-axis.github.io/xpadneo/
GNU General Public License v3.0
1.88k stars 110 forks source link

Wrong mapping after arch update #379

Closed AlexNomadrg closed 1 year ago

AlexNomadrg commented 1 year ago

Version of xpadneo

Controller Model

Connection mode

Installed Software

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:

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

Severity / Impact

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 commented 1 year ago

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 commented 1 year ago

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

SpidFightFR commented 1 year ago

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 commented 1 year ago

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

SpidFightFR commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

@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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

RTbecard commented 1 year ago

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 commented 1 year ago

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

kakra commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

IvanDobysh commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

googleson78 commented 1 year ago

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

Nope, same thing.

Snomwan commented 1 year ago

Yeah I've been having this exact issue.

RTbecard commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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:

IvanDobysh commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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.

IvanDobysh commented 1 year ago

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.

I've tried everything: both AUR packages, manual git cloning, lts kernel - nothing helps.

SpidFightFR commented 1 year ago

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.

Welp, i’m gonna try it later on. What distro do you use?

Snomwan commented 1 year ago

I use Arch Linux.

SpidFightFR commented 1 year ago

I use Arch Linux.

What kernel then ? That's weird...

SpidFightFR commented 1 year ago

i just tried and recompiled the module from the sources, reinstalled it, rebooted just in case. But it's not use, inputs are still broken. (the left trigger acts like the right joystick, the start button acts like the Right button, nothing makes sense...)

Lacentix commented 1 year ago

Can confirm, everything works fine now.

SpidFightFR commented 1 year ago

I’m going to try this later on today, anyways: if it indeed works, nice!

kakra commented 1 year ago

I didn't try yet if it also fixes usage with Steam Input enabled because the one game I tried, didn't detect the controller at all if Steam Input was enabled.

Lacentix commented 1 year ago

Which game? Can try and help

kakra commented 1 year ago

Which game? Can try and help

I tried Assassin's Creed Odyssey with Proton Experimental 7.

Lacentix commented 1 year ago

welp, for starters, my controller is detected as xbox 360 controller in steam now (It should be series x|s controller) is it the same for you?

kakra commented 1 year ago

welp, for starters, my controller is detected as xbox 360 controller in steam now (It should be series x|s controller) is it the same for you?

That's expected but it shouldn't matter to games because the Steam virtual controller (that one you're using through Steam Input) itself is offered to games as Xbox 360 controller (in Windows and in Proton). Currently, that's tagged as a hack in Proton but at least it should work. As the virtual controller also supports the Elite 2 paddles, these should work, too - but we may need some remapping then, I didn't investigate that yet.

See: https://github.com/ValveSoftware/wine/commit/7ea1cc2581b35b6d630d0399a0e230b3f57a2014

According to that commit, I decided to go with the same PID - and to my surprise, it fixed the Chrome gamepad API, too. SDL also works fine with this. It should also fix the controller for all users of retro emulators. So everyone should be happy.

SpidFightFR commented 1 year ago

does it affects Triggers haptic feedback ? Or will it be the same as before ?

kakra commented 1 year ago

It should be the same because we do not support explicit trigger feedback yet (the kernel does not support this yet). This has to be retested after the kernel got the new API. Please consider that rumble through Steam Input doesn't seem to work properly for a lot of users, so don't expect it to work while Steam Input is enabled for a game.

SpidFightFR commented 1 year ago

in global settings, do you advise us to enable or disable steam input ?

Lacentix commented 1 year ago

in global settings, do you advise us to enable or disable steam input ?

disable it unless the game isn't working properly or detecting the controller for example, then you force it on for this game, because steam is really random with controller configs and often breaks haptics mostly

Speaking of games that needs steam input forced, ETS works fine with steam input.

SpidFightFR commented 1 year ago

okay, thanks for the tip !

kakra commented 1 year ago

@Lacentix Personally, I'm not offended - but: language please. Thanks. :-)

Evidence shows, tho, that your statement is true.

Lacentix commented 1 year ago

@Lacentix Personally, I'm not offended - but: language please. Thanks. :-)

Evidence shows, tho, that your statement is true.

My bad, edited. Anyways steam input is fine

SpidFightFR commented 1 year ago

I can confirm that the issue has been solved, good job everyone !