Latency and polling rate issue when booting after shutdown (not reboot)

[rexmightlag]

Version of xpadneo

xpadneo-dkms 0.9.7-1 (aur)

Controller Model

• Xbox One S controller
• Xbox Elite 2 controller
• Xbox Series X|S controller
• Other: cb stellaris (xbox style controller)

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 is installed but was not running during testing.
• 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 ...
• It's too complicated
• Fantastic work but ...
• I can code and I want to help

Describe the Bug

After installation of xpadneo followed by a reboot, the controller works as expected, same case if i reboot the system (laptop) and test again. But after powering off and turning on using the power button, the polling rate goes down and latency spikes. But then if I reboot everything goes back to normal.

Again if I shut down (not reboot) and power on again, the latency increases and polling rate goes down.

I have checked using dmesg that xpadneo is loaded and working after reboots and shutdown. The controller also vibrates on connect in both scenarios and the sensitive triggers also work.

I am testing Polling rate using Polling by Gamepadla.

Steps to Reproduce

Install xpadneo, reboot the computer and test, controller works fine and stays persistent across reboots. But after powering off the system and turning it on manually, the polling rates goes down and latency jumps from 5-6ms to ~20ms.

Expected Behavior

The Polling rate and latency should remain same even after power down the system and turning it back on.

Screenshots / GIFs / Videos

System Information

# uname -a
Linux hostname 6.12.8-arch1-1 #1 SMP PREEMPT_DYNAMIC Thu, 02 Jan 2025 22:52:26 +0000 x86_64 GNU/Linux

# xxd -c20 -g1 /sys/module/hid_xpadneo/drivers/hid:xpadneo/0005:045E:*/report_descriptor | tee >(cksum)

Controller and Bluetooth Information

I am testing using a laptop computer and using the built-in network adapter, maybe that is why i am unable to get bluetooth info from lsusb, so providing the network adapter info instead:

Network controller [0280]: Qualcomm Atheros QCA9377 802.11ac Wireless Network Adapter [168c:0042] (rev 31)
Subsystem: AzureWave Device [1a3b:2b51]

-btmon-after reboot (normal state).txt
-btmon-after manual power on.txt

-dmesg-after reboot (normal state).txt
-dmesg-after manual power on.txt

Additional Context

[kakra]

But after powering off the system and turning it on manually, the polling rates goes down and latency jumps from 5-6ms to ~20ms.

This is most likely an issue with bluez or the Bluetooth driver. So xpadneo cannot solve this but I can give a few hints:

• How do you get a good polling rate anyway when the problem seems to occur from powering on?
• Will it be fixed by a reboot then? (I think you wrote yes, may be important when reporting to bluez)
• Did you turn the controller off before power down?
• Did you hibernate/sleep the system instead of shutting it down completely?

Also check here:
https://github.com/atar-axis/xpadneo/blob/master/docs/TROUBLESHOOTING.md#high-latency-or-lost-button-events-with-bluetooth-le

There may be a problem with restoring proper latency values. For the changes to take effect, you may need to reboot your computer, completely remove your controller from bluez, then pair it again.

I'm pretty sure that is a third party problem because xpadneo itself cannot cause such problems. We are only handling events from lower driver layers (Bluetooth, HID) and do not delay any events.

But there's a hint in dmesg:

xpadneo 0005:045E:02FD.0002: buggy firmware detected, please upgrade to the latest version

Please upgrade the firmware of your controller. This often solves a lot of issues with connectivity and latency. You are still on a version that is known to have issues with various Bluetooth chipsets.

[rexmightlag]

Hello,

1. For example, my computer is turned on, doesn't matter whether the latency issue is happening or not, if I then restart it, the issue gets resolved and will stay good even if I reboot again and again. But if I decide to power off the system, doesn't matter if it the latency issue was happening on this boot or not, when I will power on the system next time, the issue will appear again.
2. Yes
3. It doesn't matter if if turn off the controller, or unpair it before shutting down, or let it turn itself off due to disconnection, result remains the same.
4. I shut it down properly.

[kakra]

Then this is most likely an incomplete proper initialization of the Bluetooth stack on cold start. May be an issue with your UEFI firmware, may be an issue with the linux-firmware package, may be an issue with the Bluetooth kernel drivers, and may actually also be an issue with older Xbox controller firmwares.

I suggest checking for firmware updates first (UEFI, linux-firmware, Xbox controller), then maybe report to the bluez project.

[kakra]

I am testing Polling rate using Polling by Gamepadla.

Re-opening just as a reminder for me: We should probably document the expecting numbers of this test so people can verify their setup.

From previous tests, the controller should be able to handle an event rate of 100 Hz: it seems to be the cycle interval the controller uses internally. This is also the minimum supported rate of the haptic programming interface. Controllers connected via Bluetooth may go as low as 20 Hz according to some bug reports (that's why our rumble programming is fixed at 20 Hz currently, otherwise the firmware may crash).

We cannot control the reporting rate, tho. Thus we cannot fix the problem initially described in this report.