Rumble lasts too long with some games

[lights0123]

Version of xpadneo

73be2eb

Controller Model

• Xbox One S controller
• Xbox Elite 2 controller
• Xbox Series X|S controller
• Other:

Connection mode

• Bluetooth connection
• USB cable (not yet supported)
• Xbox Dongle connection (not yet supported)

Installed Software

• Anti-Micro (may affect button mappings)
• OpenRGB (may mess up mappings and rumble stability)
• Steam Input (enabled by default via Steam Desktop client)
• Steam Link (usually via Raspberry Pi or other micro computers)
• devices with QMK firmware (may affect udev rules, similar to OpenRGB)
• netstick (shares input devices via network similar to Steam Link)
• xboxdrv (user-space gamepad driver)
• xone (kernel-space gamepad driver using the Xbox dongle or USB)
• xow (alternative driver using the Xbox dongle)

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:

• Steam Proton games are having issues
• Steam Linux-native games are having issues
  • I don't use Steam or did not try
• games running through Lutris, wine and/or Bottles are having issues
  • I don't use Lutris, Bottles, wine or did not try
• Linux-native games are having issues
  • I don't use native games or did not try
• Other software is having issues (describe software and issues below)
• Running evtest is showing issues (describe the issues below)
  • Keep in mind that BTN_NORTH and BTN_WEST are intentionally swapped
• Running jstest is showing issues (describe the issues below)
  • I don't have this tool or don't know how to use it
• Running gamepad-tool is showing issues (post console output below)
  • I don't have this tool

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

Severity / Impact

• I've read the docs and the bug reporting instructions
• I've applied the latest firmware update to the controller
• I've tried disabling or running without above mentioned software
• 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 capture the force feedback commands from the game to see if it's sending incorrect commands or if this driver is interpreting them incorrectly—although this doesn't happen over USB at least
• It's too complicated
• Fantastic work but ...
• I can code and I want to help

Describe the Bug

When playing Ghost of Tsushima, the game will rumble the controller. However, these effects last much longer than they should, and are queued up—often, the controller will rumble at one speed, stop, rumble at another for a second, stop, and then repeat this process several times. Entering the pause menu where no more vibrations should be queued causes this pattern to repeat ~15 times for ~20 seconds. This does not happen over USB.

Steps to Reproduce

1. Launch Ghost of Tsushima via Steam with Proton Experimental
2. Enter combat or another activity that generates significant vibration
3. Enter the pause menu and experience continued vibration

Expected Behavior

Individual vibrations should be much shorter, and they should stop once entering the pause menu.

Screenshots / GIFs / Videos

IMG_5069.mp4

System Information

# uname -a
Linux PC 6.9.9-arch1-1 #1 SMP PREEMPT_DYNAMIC Fri, 12 Jul 2024 00:06:53 +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 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

Controller and Bluetooth Information

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

Additional Context

[kakra]

This is probably caused by the aliasing effects occurring between the update frequency we have to use to prevent the firmware from crashing, and the update frequency we get pushed from ff-memless. I'm planing to bypass ff-memless with one of the next versions.

Currently, we have 20ms as the shortest interval before the firmware crashes, and we get 1-50ms intervals (with a strong tendency towards 50ms) from ff-memless. In the worst case, we get the last update at 50ms while the previous has been at 40ms. This means, we are allowed to update the rumble at the 60ms mark earliest but we will see the next update from ff-memless only at 100ms mark - this is 50ms late in the worst case. This is probably what you are seeing.

If you compile from source, you can tweak this define:

#define XPADNEO_RUMBLE_THROTTLE_DELAY   msecs_to_jiffies(50)

It has been set to 50ms because users have reported crashing firmware with lower values. The previous default has been 20ms. The original XB1S firmware allowed 10ms without crashing. This also depends on your Bluetooth adapter. The firmware uses 100hz internally (thus 10ms is the shortest interval allowed). This also matches the resolution of the rumble haptics parameters.

I'm pretty sure we can go back to 20ms or faster when we remove ff-memless and do rumble directly.

[kakra]

often, the controller will rumble at one speed, stop, rumble at another for a second, stop, and then repeat this process several times.

BTW: This queuing should not occur at all. It cannot be caused by xpadneo because we especially designed the rumble throttling to never ever queue any rumble effects. We only delay them until the next interval, and if anything comes in before that event, we will update our pre-queued event and discard the current one - except it is meant to stop a rumble, in which case we ensure that a rumble stop is always queued last.

This looks a lot like what we were seeing with the 5.x firmwares before rumble throttling was established in xpadneo: Rumble effects queued up in Bluetooth because the firmware couldn't accept it fast enough, and then it would either crash the firmware, or 2-3 rumble effects were playing late.

So your issue may also well be that rumble doesn't run through xpadneo at all and uses SDL hidraw access instead. OTOH, SDL uses the same rumble throttling technique we suggested.

Please try disabling Steam Input for this game (disable controller input) and try again. If this is a game ported from Playstation, it may very well not work at all with a controller if Steam Input is disabled.

In this case ensure that xpadneo's hidraw device cannot be read or written by anyone. See dmesg to find the raw device, then chmod a-rwx it, then try again. If you reconnect the controller, the raw device will be recreated under a new name. If it does have any access permissions, you're likely using OpenRGB or qmk and that messes with our device permissions.

[lights0123]

Changing the delay to 20ms worked great!

[kakra]

Thanks for confirming. I'm queuing this to review before v0.11.

[guoyunhe]

I happen to reproduce this issue with my system.

1. I have uninstalled xpadneo and reboot system for testing some other bug. So it should NOT be caused by xpadneo.
2. I have uninstalled kde-connect which is said to cause some issue. So it should NOT be caused by kde-connect.
3. I checked journal log, and found tons of repetitive error messages of bluetoothd[1283]: profiles/input/hog-lib.c:output_written_cb() Write output report failed: Request attribute has encountered an unlikely error
4. I tried to unplug and re-plug the Bluetooth receiver, and it solved the issue.
5. I have used my PC + Controller setup for a year and it used to work fine. Only recently, it become unplayable with tons of disconnecting issue. And today, new issue with rambling...

I guess it has something to do with either kernel, bluez, or my bluetooth receiver...

[kakra]

Yeah, there may be an issue with the linux-firmware package lately which shipped an update for some Bluetooth chipsets. Can you try reverting that to a previous version?

[NerosTie]

I bought my Xbox Series controller last week and I had this 2 times, one without xpadneo in Prodeus and the second time with xpadneo in Prey (2017).

So, I would say it's unrelated to xpadneo and it happens randomly. Disconnect and reconnect the controller or rebooting the computer solves the issue. Sounds like a problem with the Bluetooth driver.

linux-firmware has been updated today in Arch, maybe this issue is fixed.

EDIT: it's not fixed

[kakra]

Yeah this happens due to overloading the firmware with rumble commands in some situations. It's very common with Bluetooth but can also happen with the Xbox radio dongle (non-bluetooth), and very rarely with USB. The latter two connection modes do not run through xpadneo. And we found that the original Windows drivers put at least 10ms between each rumble command. Both xpadneo and xone mimic that behavior and it fixed a lot of issues. With Bluetooth, we needed to go to at least 20ms, for some chipsets even 50ms. SDL mimics the 20/50ms intervals to solve it if it bypasses xpadneo via hidraw.

xpadneo currently using ff-memless is more likely triggering this hardware behavior due to timing aliasing, and I will remove ff-memless from future releases which could improve the situation. xone already doesn't use ff-memless.