Closed AlexNomadrg closed 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
It is firefox on my video. I've already disabled steam input
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.
I was able to fix my button mappings on Arch by adding SDL_JOYSTICK_HIDAPI=0
to my environment variables as described here.
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...
@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.
@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.
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).
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…
Crazy thing: when i connect the controller with bluetooth, it goes crazy, but when i connect it in usb, it goes normal again…
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).
For me xpandeo stop working after an upgrade Kubuntu from 20.04 to 22.04.01 With kernel driver mapping is OK.
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*
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.
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.
If that can help, i use SDL2 version 2.24.0-1
.
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.
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
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.
Does the behavior change if you load the xpadneo module after a reboot but before connecting the controller?
Does the behavior change if you load the xpadneo module after a reboot but before connecting the controller?
Nope, same thing.
Yeah I've been having this exact issue.
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
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.
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 isv0.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...
But your version looks awkward:
hid-xpadneo/v0.9-123-g94cf8f1
isn't current master, which isv0.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
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:
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
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!
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.
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.
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?
I use Arch Linux.
I use Arch Linux.
What kernel then ? That's weird...
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...)
Can confirm, everything works fine now.
I’m going to try this later on today, anyways: if it indeed works, nice!
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.
Which game? Can try and help
Which game? Can try and help
I tried Assassin's Creed Odyssey with Proton Experimental 7.
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?
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.
does it affects Triggers haptic feedback ? Or will it be the same as before ?
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.
in global settings, do you advise us to enable or disable steam input ?
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.
okay, thanks for the tip !
@Lacentix Personally, I'm not offended - but: language please. Thanks. :-)
Evidence shows, tho, that your statement is true.
@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
I can confirm that the issue has been solved, good job everyone !
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:
evtest
is showing issues (describe the issues below)BTN_NORTH
andBTN_WEST
are intentionally swappedjstest
is showing issues (describe the issues below)gamepad-tool
is showing issues (post console output below)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
Controller and Bluetooth Information
https://termbin.com/dk4d
https://termbin.com/xhjf
Additional Context