atar-axis
xbox one controller is being initialized twice(?)
Version of xpadneo
pacman -Q xpadneo-dkms-git
xpadneo-dkms-git 0.9.r102.ga279cc4-1
Current master commit
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
Steam installed but not launched yet.
- [ ] 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
- [ ] 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
- [x] It mostly works but sometimes it doesn't
- [ ] I found a work-around
- [x] 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
Upon connecting the controller does welcome rumble twice and dmesg logs show that it is being initialized twice.
This happens on first connect after fresh system boot. Every subsequent reconnect yields one rumble and one initialization.
Steps to Reproduce
- Reboot system.
- Turn on bluetooth
- Turn on controller and let it connect
Expected Behavior
Controller should be initialized once and should produce one welcome rumble.
Screenshots / GIFs / Videos
System Information
% uname -a
Linux marble 5.17.5-arch1-1 #1 SMP PREEMPT Wed, 27 Apr 2022 20:56:11 +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
Additional Context
There may be two issues:
- You are using the original buggy firmware of the controller. You should upgrade that to the latest version using an Xbox or the Windows Xbox Accessories app from the store.
- There may be an issue with driver rebinding in the udev rules. If this happens, you would only see it on the first connect after booting the system, successive connects won't show this behavior (you actually described that behavior). You can probably work around this by loading the module at boot.
- Updated the firmware from 4.8.x to 5.1.x (current) and result is the same so moving on to # 2
- Pre-loading the
hid_xpadneokernel module works:
% sudo modprobe hid_xpadneo
% sudo lsmod | grep xpad
hid_xpadneo 36864 0
ff_memless 20480 1 hid_xpadneo
Afterwards when I connect the controller it rumbles once and dmesg logs only show a single initialization.
Can we fix this in udev rules somehow?
-
% grep ACTION xpadneo-first-connect.log | sort | uniq -c 46 ACTION=add 6 ACTION=bind 20 ACTION=remove 4 ACTION=unbind -
% grep ACTION xpadneo-second-connect.log| sort | uniq -c 16 ACTION=add 2 ACTION=bind
So it initially binds it to the hid-generic as expected driver:
KERNEL[78.074814] bind /devices/virtual/misc/uhid/0005:045E:0B20.0007 (hid)
ACTION=bind
DEVPATH=/devices/virtual/misc/uhid/0005:045E:0B20.0007
SUBSYSTEM=hid
DRIVER=hid-generic
HID_ID=0005:0000045E:00000B20
HID_NAME=Xbox Wireless Controller
HID_PHYS=e0:d4:e8:53:40:9d
HID_UNIQ=98:7a:14:81:f5:93
MODALIAS=hid:b0005g0001v0000045Ep00000B20
SEQNUM=3940
but we don't get information that this will get a re-bind automatically within the kernel as your dmesg shows. Then of course, our udev rule will unbind the device from hid-generic, then rebind it to xpadneo (which already happened behind the scenes invisibile for us), which forces a second init from xpadneo.
If the module is already loaded, the kernel will directly bind to xpadneo and our udev rules don't try to correct that.
I'm not sure if this is a bug in udev, a bug in the kernel, or wanted behavior. But if the kernel can rebind the device by dynamically loading a module, why does udev see the "wrong" driver? I'd expect to either see both events for the first (hid-generic) and second (hid-xpadneo) drivers, or I'd expect to see only the last event.
This seems to differ from the 4.x kernel series when we initially added these udev rules.
The first-connect behavior you're seeing is actually mostly a cosmetic issue. You could just disable the welcome rumble and probably won't notice a double init then. Or you auto-load the module at boot so the kernel will re-bind to xpadneo early enough for the udev rule to not trigger.
I was thinking about delaying the welcome rumble but that is probably a bad idea because it may interfere with user-space rumble then. Currently, we rumble on init before user-space can send rumble data to us.
The best idea may be to just auto-load the module at boot. If we have a modern kernel that does automatic re-bind for HID devices, it will do so. If we have an older kernel, it will use the udev re-bind rule. And otherwise, we would get the double-init.
Thanks @kakra for the explanaition, I guess I can try to workaround it or live with it :) not a big issue for me
Mine too rumble 2 times when connect 1-st time. But no problem when using. Xbox One S
After update kernel to 5.17.5, no more 2 times rumble for connection. (lastest updates on Pop!_OS 22.04) Also no need to reinstall xpadneo after kernel update. Because last times when i got kernel update i need reinstall xpadneo to get rumble support. Maybe that is causing some bug with 2 installs of xpadneo. Or 2-nd install does not clean all files. To be clear: i always install xpadneo wih dkms. Or maybe some kernel bug.. Anyway now is working as should. And this is mean: perfect. Thank you.
The double rumble is caused by some interaction between the kernel and udev, not by double installs, and only on first module load. Because even when two versions are installed, only one instance can be active per kernel. Preloading the module on boot works around the issue.
Yes problem is solved with non-git versions. Just download lastest version archive from here and install from it.