Xbox Wireless Controller rumble sometimes doesn't stop

[orbea]

Version of xpadneo

bf8a3c3

Severity / Impact

• I've read the docs and the bug reporting instructions
• 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 ...
• It's too complicated
• Fantastic work but ...
• I can code and I want to help

Describe the bug

When using an official Xbox Wireless Controller with rumble it will occasionally get stuck on a rumble on state and will not stop rumbling until the controller is turned off. During this time other input still works as expected. This can completely break gameplay depending on the game.

Steps to Reproduce

1. Play a game that regularly uses the rumble feature.
2. After roughly 5-30 minutes the rumble state will be stuck on.

Expected behavior

The rumble should not get stuck.

Screenshots/Gifs

N/A

System information

# uname -a
Linux gentoo 5.9.12-x86_64 #1 SMP Mon Dec 7 18:09:18 PST 2020 x86_64 Intel(R) Core(TM) i5-7600K CPU @ 3.80GHz GenuineIntel GNU/Linux

# xxd -c20 -g1 /sys/module/hid_xpadneo/drivers/hid:xpadneo/0005:045E:*/report_descriptor | tee >(cksum)
xxd: /sys/module/hid_xpadneo/drivers/hid:xpadneo/0005:045E:*/report_descriptor: No such file or directory
4294967295 0

I'm not sure where this file is?

# find /sys/ -iname report_descriptor
/sys/devices/pci0000:00/0000:00:14.0/usb1/1-12/1-12:1.1/0003:062A:38B3.0004/report_descriptor
/sys/devices/pci0000:00/0000:00:14.0/usb1/1-12/1-12:1.0/0003:062A:38B3.0003/report_descriptor
/sys/devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.0/0003:25A7:FA34.0009/report_descriptor
/sys/devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.1/0003:25A7:FA34.000A/report_descriptor
/sys/devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.0/0003:0079:0011.0013/report_descriptor
/sys/devices/virtual/misc/uhid/0005:045E:02FD.002B/report_descriptor

Best guess is?

# xxd -c20 -g1 /sys/devices/virtual/misc/uhid/0005:045E:02FD.002B/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 32 09 35 15 00  .....u.........2.5..
00000028: 27 ff ff 00 00 95 02 75 10 81 02 c0 05 02 09 c5 15 00 26 ff  '......u..........&.
0000003c: 03 95 01 75 0a 81 02 15 00 25 00 75 06 95 01 81 03 05 02 09  ...u.....%.u........
00000050: c4 15 00 26 ff 03 95 01 75 0a 81 02 15 00 25 00 75 06 95 01  ...&....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 0f 15 00 25 01 75 01 95 0f 81 02 15 00 25 00  ....)...%.u.......%.
000000a0: 75 01 95 01 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 85 04 05 06  U..|..&..u..........
00000140: 09 20 15 00 26 ff 00 75 08 95 01 81 02 c0 00                 . ..&..u.......
2497585015 1559

Controller and Bluetooth information

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

Additional context

With disable-ff=1 or disable-ff=2 the issue seems rarer? With trigger_rumble_mode=1 when this occurs I also lose all other input. It also does not rumble when connecting the gamepad. Please let me know if there is any other info I can provide?

[kakra]

This is a known bug of the controller firmware when using Bluetooth connections, it also happens in Windows. There's nothing we can do except poking MS about it: https://answers.microsoft.com/en-us/xbox/forum/all/xbox-elite-series-2-disconnecting-from-pc/7e5a964a-16cc-4e83-8dec-aa8c858b875c

Depending on the model, firmware version, and rumble patterns you'll experience loss of input (partially or completely), spontaneous controller reboots, or full devices freezes (with the rumble motors stopping after 30+ seconds). The Bluetooth stack may or may not detect a disconnect or connections timeout. This is most likely purely an issue with the device firmware and nothing that can be fixed or worked around from the driver.

We already deployed some work arounds, e.g. by using tighter rumble timing and intervals of at least 10ms before updating the rumble motors which prevents most instantaneous crashes. Future versions of xpadneo will work towards supporting the original controller dongle which uses Wifi instead of Bluetooth. With that, rumble is stable if we stay above the 10ms intervals. Apparently, the dongle firmware must be uploaded to the dongle during device init, and it's closed source and legal implications for shipping it aren't clear yet.

[kakra]

I'm not sure where this file is?

Yeah, this is because Steam Input steals the device and presents it under uinput. You should disable Steam controller support in big picture mode otherwise we get wrong info, and some of the work-arounds of the driver may not work.

[orbea]

Thanks for the detailed reply. It is unfortunate to learn this is a problem with the device firmware. I had the same issue with a wired xbox 360 gamepad I broke by dropping one too many times, but was never able to get a detailed explanation. :)

Future versions of xpadneo will work towards supporting the original controller dongle which uses Wifi instead of Bluetooth.

Is there a place this can be tracked?

Yeah, this is because Steam Input steals the device and presents it under uinput. You should disable Steam controller support in big picture mode otherwise we get wrong info, and some of the work-arounds of the driver may not work.

I don't use steam and have never installed it to this computer.

[orbea]

I wonder if it would be possible to reverse engineer the firmware and then replace it with an open source reimplementation? At the very least I doubt this would be trivial, but it would avoid having to rely on microsoft to fix this issue.

[kakra]

Is there a place this can be tracked?

https://github.com/atar-axis/xpadneo/projects/5

[kakra]

Yeah, this is because Steam Input steals the device and presents it under uinput. You should disable Steam controller support in big picture mode otherwise we get wrong info, and some of the work-arounds of the driver may not work.

I don't use steam and have never installed it to this computer.

Then this is strange... Do you use other types of similar software that moves the controller to uinput? Because this looks like uinput may be involved:

/sys/devices/virtual/misc/uhid/0005:045E:02FD.002B/report_descriptor

With disable-ff=1 or disable-ff=2 the issue seems rarer?

Looks like a placebo effect, this parameter isn't supported any longer:

[202861.316468] hid_xpadneo: unknown parameter 'disable_ff' ignored

Since you are running Gentoo and probably installed without the official installer, you may need to install the udev rules manually, along with the other files that should go to /etc. Also, there may be artifact files in /etc you may need to remove.

I'm using Gentoo myself, I should probably add some official installer for it.

[orbea]

Then this is strange... Do you use other types of similar software that moves the controller to uinput?

Not that I am aware of. This is a relatively new install with a stock 5.9.12 kernel using the source from kernel.org. The only programs I have that would use a gamepad are emulators like dolphin-emu, pcsx2, ppsspp and potentially wine.

Looks like a placebo effect, this parameter isn't supported any longer:

Thanks for pointing this out, I also noticed the logs after I wrote that. It seems sometimes it happens sooner and other times it happens later.

Since you are running Gentoo and probably installed without the official installer, you may need to install the udev rules manually, along with the other files that should go to /etc. Also, there may be artifact files in /etc you may need to remove.

Yes, I used make ; make modules_install.

Looking at the install scripts I created these files.

$ cat /etc/modprobe.d/99-xpadneo-bluetooth.conf 
options bluetooth disable_ertm=y

$ cat /etc/modprobe.d/xpadneo.conf 
alias hid:b0005g*v0000045Ep000002E0 hid_xpadneo
alias hid:b0005g*v0000045Ep000002FD hid_xpadneo
alias hid:b0005g*v0000045Ep00000B05 hid_xpadneo
alias hid:b0005g*v0000045Ep00000B13 hid_xpadneo

$ cat /etc/modprobe.d/99-xpadneo-options.conf 
options hid_xpadneo disable_deadzones=0 rumble_attenuation=0 trigger_rumble_mode=0

$ cat /etc/udev/rules.d/98-xpadneo.rules 
ACTION=="add", KERNEL=="0005:045E:02FD.*|0005:045E:02E0.*|0005:045E:0B05.*|0005:045E:0B13.*", SUBSYSTEM=="hid", DRIVER!="xpadneo", ATTR{driver/unbind}="%k", ATTR{[drivers/hid:xpadneo]bind}="%k"
ACTION=="add", DRIVERS=="xpadneo", SUBSYSTEM=="input", ENV{ID_INPUT_JOYSTICK}=="1", TAG+="uaccess", MODE="0664", ENV{LIBINPUT_IGNORE_DEVICE}="1"

And ertm is disabled.

$ cat /sys/module/bluetooth/parameters/disable_ertm
Y

Did I miss anything?

Edit:
After creating these missing files the rumble when connecting started to work.

[kakra]

After creating these missing files the rumble when connecting started to work.

Now, the rumble throttler of xpadneo should work and you may have better luck. After all, I don't think your system was actually using xpadneo before.

[orbea]

Now, the rumble throttler of xpadneo should work and you may have better luck. After all, I don't think your system was actually using xpadneo before.

I was able to rmmod hid_xpadneo and then when connecting the gamepad it would get loaded again as shown by lsmod(8) so I thought it was used at some level. Regardless you may be right that I will have better luck now, after short testing I was unable to reproduce the problem again. I'll report back after more thorough testing.

Thanks for the help!

[kakra]

I was able to rmmod hid_xpadneo and then when connecting the gamepad it would get loaded again as shown by lsmod(8) so I thought it was used at some level.

This is because the gamepad PIDs are in the driver so the kernel autoloads it, but your dmesg logs didn't show any presence that it actually initialized the controller so udev didn't bind the device to the driver. If you compare dmesg now, you'll see xpadneo actually logging device init. The connect rumble is actually a hint for that so you know it worked without looking at the logs (and it's a test if 3rd party manufacturers implemented rumble correctly).

[kakra]

@orbea As a Gentoo user, you could use my kernel patch which integrates xpadneo right into the kernel, and with it you also probably no longer need to disable ERTM:
kakra/linux#11

Clone the repository, then checkout that PR branch, now run:

git remote update --prune
git reset --hard
git format-patch --stdout origin/master | sudo tee /etc/portage/patches/sys-kernel/gentoo-sources/9300_xpadneo.patch

(9300 is just a number to order this after Gentoo kernel patches, any number 9000-9999 should work)

This will export a patch above my current master (which points to the base version of the kernel I'm using) for xpadneo. The branch names include the kernel branch which is 5.10 currently.

Then re-emerge gentoo-sources. You may need to sudo mkdir -p /etc/portage/patches/sys-kernel/gentoo-sources once first. Also, you may need to unmask sys-kernel/gentoo-sources-5.10*. The build log should say "User patches applied". To remove a patchset, delete the file from the patches folder and re-emerge gentoo-sources again.

After installing that kernel, you should have xpadneo built right into the kernel - just enable it in make menuconfig, no udev rules needed, and hopefully also no Bluetooth adjustments.

There are a few other pull requests that track several other performance patchsets useful for gaming with the gentoo-sources kernel (MuQSS + full CK patchset, Intel's kernel performance patches from ClearLinux, support for Valve's Proton fsync.

At some point I'll rebase those patches when they become incompatible with the latest kernel version. If you're having problem with one of those, consider asking your question there and not here. Thanks.

[orbea]

Thanks for pointing that out. I'll give it a try soon when I move to 5.10 kernels. I am currently on 5.9.15 using sources from kernel.org, but I am fairly familiar with compiling the kernel manually that I should manage. In gentoo genkernel does most of the tedious work.

Regarding this issue it still enters the infinite rumble, but sometimes it never seems to happen. Maybe some games reproduce it easier? I haven't found the time to try to debug it further yet.

[kakra]

Regarding this issue it still enters the infinite rumble

Yeah, using the 10ms intervals is only half of the solution. The other crash condition seems to be deeply hidden in the Bluetooth implementation of the controller firmware itself and can also be observed in Windows. There's no known work-around. You can try disabling the trigger rumble (if your controller has those rumble motors) with parameter trigger_rumble_mode=2 but to me it looks mostly like a placebo effect: If anything, it may reduce the issue but doesn't fix it either.

[kakra]

I am currently on 5.9.15 using sources from kernel.org, but I am fairly familiar with compiling the kernel manually that I should manage. In gentoo genkernel does most of the tedious work.

I unmasked =sys-kernel/gentoo-sources-5.10* - it's mostly identical to kernel.org with a few Gentoo-specific security fixes. You should really use that one. Also, I'm not using genkernel, I'm using make menuconfig with migrating the .config over each time, as you would by manually compiling the kernel. The nice side-effect of this is that I can add various patches and slipstream them automatically into the installation via /etc/portage/patches but still have full control over the kernel configuration.

[orbea]

I am pretty stuck in my ways after manually installing my own kernel in Slackware for so long. I am rather new to Gentoo, but found genkernel does away with lot of the tedium of updating the kernel, it is still able of using arbitrarily modified source trees, using menuconfig, custom config files and offers more control on the kernel version.

genkernel --luks --lvm --bootloader=grub2 --mountboot --menuconfig --kernel-config=/usr/src/config --makeopts=-j4 --no-zfs all

[orbea]

I compiled a 5.10.5 kernel, applied PR kakra/linux#11 as a patch and enabled xpadneo in menuconfig. Then I removed all of the modifications listed in comment #264 (comment).

It seems to work just as well as it did before.

$ cat /sys/module/bluetooth/parameters/disable_ertm
N

Also you can just add .patch or .diff at the end of PR and commit links to get a patch. :)

https://github.com/kakra/linux/pull/11.patch

[kakra]

Yes, this is how I'm using xpadneo in Gentoo: Compiled right into the kernel as a patch (but still as a loadable module). Updating xpadneo from the xpadneo source itself still works (if compiled as a module), if you use make -C hid-xpadneo reinstall from the xpadneo project root (it will re-compile as user, then use sudo for installation).

BTW: Yep, appending .patch to PR URLs is a lesser known but very useful feature. ;-)

[orbea]

Just curious, but are there any known similar controllers with working bluetooth and rumble?

[kakra]

We should be supporting any controller that claims to be compatible with Xbox controller HID mode. I think most 8BitDo controllers in xinput mode are supported. Some of them have rumble support, tho, their implementation is buggy/limited sometimes. The driver has work-arounds for it via quirk flags.

Maybe we should start compiling a list of known-compatible controllers in the docs.

[lights0123]

@orbea stretching "similar" (if you're looking for anything that works), PS2-PS4 controllers have in-tree Linux drivers written by Sony, and PS5 controller support is waiting to be merged.

[kakra]

The interesting bit is that PS5 controllers started discussion about how to properly support the trigger rumble natively via kernel APIs. Our driver currently synthesizes the rumble values from the strong and weak motor values because we only get two values from the kernel rumble API.

This will be interesting and I'll be watching the development once merging is complete.

[orbea]

@lights0123 I have various official and non-official PS3 controllers, but they all fail with bluetooth in the same way.

https://bugzilla.kernel.org/show_bug.cgi?id=210595

[kakra]

This may be a duplicate of #272.

[kakra]

Please re-open if it is still an issue.