Strange rumble issues... (failed to send rumble report -5)

[mr-falafel]

Version of xpadneo

v0.10.4

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 by xpadneo)
• Xbox Dongle connection (not yet supported by xpadneo)

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, not used for Bluetooth)
• xone (kernel-space gamepad driver for using USB or the Xbox Dongle)
• xow (obsolete user-space driver for using the wireless Xbox Dongle)
• Nobara Linux (you will most likely have to report your bug there because it uses a custom version of xpadneo)

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 ...
• It's too complicated
• Fantastic work but ...
• I can code and I want to help

Describe the Bug

When using RPCS3 or ShadPS4, I am experiencing very strange and unpleasant issues with rumble. During play, controller vibration is initially stronger than expected, especially in the triggers. After maybe 30 seconds of play, some vibrations begin to last longer than expected, sometimes for intervals of roughly 10 seconds, even after pausing the game. Sometimes this vibration, especially in the triggers, is strong enough to elicit concern for the hardware. Alternatively, the controller can fail to vibrate at all, for similar intervals. Once this behaviour has started, it persists through disconnecting/reconnecting the controller and unloading/reloading the xpadneo sysmodule. When reconnecting the controller, it does not vibrate as usual. Instead, a soft vibration can be felt on one side of the controller only. Also, the controller will vibrate randomly, sometimes intensely, just by browsing the controller settings in RPCS3, even when a game is not running...

Upon rebooting my PC, I noticed the kernel messages included many (>10) entries from xpadneo, stating:
failed to send rumble report -5

Steps to Reproduce

Open RPCS3 or ShadPS4 and play a game for >30 seconds. Behaviour might be present in other applications with rumble but these are the only ones I've tested. Rumble works normally when connected via USB.

Expected Behavior

Controller should vibrate normally.

Screenshots / GIFs / Videos

N / A

System Information

# uname -a
Linux (user) 6.12.101+deb13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.101-1 (2026-08-05) x86_64 GNU/Linux

# dmesg -H | egrep -i 'bt|bluetooth|hci|l2cap|att|xbox|045e|hid|input|xpadneo' | tee xpadneo-dmesg.txt

xpadneo-dmesg.txt

Controller and Bluetooth Information

xpadneo-btmon.txt
xpadneo-lsusb.txt

[mr-falafel]

Update:

Just tried playing Doom Eternal (the GOG version, so no Steam), through UMU Launcher (aka Proton). Behavior was exactly the same as RPCS3 and ShadPS4. Initially normal rumble, if maybe a little stronger than usual in the triggers. Then, after maybe 1-2 minutes of play, rumbles begin to get "stuck" for roughly 10 seconds and/or the controller fails to register rumble for roughly 10 seconds. Controller no longer vibrates normally when re-pairing. I don't know how to reset/"fix" it without rebooting.

I think I only didn't experience this behaviour in RetroArch because I was playing a game without rumble.

[kakra]

This sounds a lot like there are issues with your Bluetooth driver, dongle or connection. You can try to work around it by using the module parameter force_disable_hogp=1 but this only means that the rumble packet queue is no longer in control of xpadneo, and it can cause other side effects like crashing the controller firmware.

If you disable HOGP, you should limit your games to 60 fps, otherwise too many rumble packets may queue up and crash the controller or Bluetooth connection stability. The controller cannot handle more than around 100-125 rumble commands per second, which seems to be its internal rate: It also won't report more than that many input updates per second. HOGP is meant to create back pressure from the controller if it can no longer accept rumble packets fast enough: With HOGP, for each rumble packet, xpadneo waits to receive an ACK, stating that the rumble packet has been properly received. But if your Bluetooth dongle or driver is flaky, this mechanism doesn't work. the ACK will go missing, you will see delays or rumble stop working, together with error -5. Most likely, it also doesn't send rumble packets properly to your controller. This is out of control of xpadneo, it cannot magically fix bugs in the controller or the Bluetooth driver. If you disable HOGP, xpadneo just assumes rumble to be successful without knowing if something queued up or the controller is ready to handle it. xpadneo tries to wait 20ms before sending the next rumble packet in this mode, but this is not reliable, and it results in lost rumble resolution. You probably won't see error -5 then, but this is only because xpadneo no longer knows if the rumble packet even arrived in time.

If you have a Realtek-based Bluetooth dongle, you can try downgrading its firmware files which ships with the linux-firmware package. Some versions have known bugs with BLE HOGP connections.

Looking at your logs, you are using a Realtek chipset:

= Index Info: AC:A7:F1:B.. (Realtek Semiconductor Corporation)  [hci0] 0.255712

[mr-falafel]

This sounds a lot like there are issues with your Bluetooth driver, dongle or connection.

The random signal drops I get would also indicate that, wouldn't they. Having, at this point, tried multiple operating systems and bluetooth dongles, I'm at a bit of a loss on how to improve my Bluetooth situation. The result is the same whether I'm sitting 5 metres away or < 50cm. Doesn't appear to be an issue with the controller, either, as it functions fine when connected to my laptop.

If you disable HOGP, you should limit your games to 60 fps

This could be an acceptable band-aid for me, since I use a 60Hz monitor. Not ideal, though, as you say. I'll try it and report the results.

If you have a Realtek-based Bluetooth dongle, you can try downgrading its firmware files which ships with the linux-firmware package. Some versions have known bugs with BLE HOGP connections.

I'd be happy to try this, too. I'll look into how to do that in Debian. Perhaps installing a newer firmware from Debian backports could also help.

Update:
After some testing with RPCS3, it appears that the force_disable_hogp=1 parameter is helping. The controller no longer gets stuck vibrating or misses vibrations. It also vibrates normally when re-pairing.

I'll also look into downgrading/upgrading the firmware version and consider procuring a dongle with a different chipset. Perhaps the same or similar as the one in my laptop. Perhaps that could eliminate my connectivity issues, as well. Thanks for all the help.

Further update:
Removed discussion on trigger vibration. I see there is an existing issue about trigger vibration/impulse triggers.

[kakra]

The result is the same whether I'm sitting 5 metres away or < 50cm. Doesn't appear to be an issue with the controller, either, as it functions fine when connected to my laptop.

I don't think that is the problem. Modern Bluetooth should reach multiple meters. I'm about 3m away from the dongle when playing on the couch. It works just fine. Does your mainboard has onboard Bluetooth? If it does, try disabling it. This way you ensure you're not paired with the wrong radio, and it reduces interefence. We has reports here where people just forgot to attach the antenna to the onboard Bluetooth. :-D

Perhaps installing a newer firmware from Debian backports

Current reports suggest that the latest firmware package of the Realtek chipset might be the problem. OTOH, Debian is known for shipping almost no firmware packages by default. Maybe try extracting firmware from another distribution and place it in /lib/firmware. You need to get the subdirectory correct and probably also set some symlinks. On my system, there's /lib/firmware/rtl_bt/ with a lot of firmware blobs. It doesn't look like any symlinks point to these files.

After some testing with RPCS3, it appears that the force_disable_hogp=1 parameter is helping.

Glad you found a work-around. You'll see a throttling message in dmesg if rumble comes in too fast. Currently its limited to one package each 20ms, which is the lowest timing resolution the kernel allows without busy waiting. Those waiting timers are not very precise, it'll probably wait between 15-25ms on avarage, which is still above the safe lowest value of 10ms. 60fps should try to send a rumble packet every 16.6ms.

Using this mode of operation reduces the time resultion of rumble and may lag 1-2 frames behind. You probably won't notice it. xpadneo just discards rumble packets instead of queuing them, ensuring that "rumble off" is always the final rumble packet (last rumble packet wins and overrides all waiting packets) so the controller doesn't continue to rumble if the game stops sending it.

I'm pretty sure it is a firmware bug handling HOGP properly.

[mr-falafel]

With xpadneo unloaded/uninstalled, the rumble also functions normally (USB and Bluetooth), without developing any issues. On the other hand, it seems that I don't get impulse trigger support, which I personally might prefer, or an accurate battery reading. I'm not sure exactly what driver Debian is falling back on but it must lack these features.

It also doesn't resolve whatever is causing my general connectivity issues, which I think must be hardware related.

[kakra]

The default kernel driver does not use HOGP and no rumble throttling. Most of the times this works because SDL itself also implements throttling, but games that use rumble directly without throttling by SDL may crash your controller firmware. I think modern controller firmware versions may be more robust. Tests showed that even the native Windows drivers throttle rumble to 10ms intervals, so this is why we implemented it in xpadneo, except that the kernel cannot reliably go below 20ms intervals unless we use much more expensive high precision timers.

As pointed out in the other issue, trigger rumble doesn't exist in Linux. xpadneo synthesizes it from existing game rumble and your input on the triggers. This makes it actually work with any game, but it ignores what a game may support on native Windows. There's currently no chance for xpadneo to get such information from wine or Proton.

Without xpadneo, Debian will most likely use hid-microsoft, which is the only driver for Microsoft HID peripherals which supports rumble. The default hid-generic driver cannot support rumble. If rumble works even with hid-generic, then because SDL uses hidraw and bypasses the kernel drivers.

[mr-falafel]

The default kernel driver does not use HOGP and no rumble throttling.

That would explain it then! Perhaps HOGP will no longer cause issues for my controller if I can find a better-behaving Bluetooth dongle.