search

atar-axis / xpadneo

Advanced Linux Driver for Xbox One Wireless Controller (shipped with Xbox One S)
https://atar-axis.github.io/xpadneo/
GNU General Public License v3.0
1.92k stars 111 forks source link

Latency on analogue axes on Series controller #294

Closed Leaguesman closed 3 years ago

Leaguesman commented 3 years ago

Version of xpadneo

0.9.1

Severity / Impact

Describe the bug

When using the Series controller, on both the left and right analogue sticks, and the analogue triggers, there is perceptible latency between activating the stick/trigger and the action being registered. This is most evident in something like a first person shooter, when moving the right stick to look around.

I'm honestly not certain the issue doesn't also apply to the digital buttons, but it's a little harder to tell. I also have an Xbox One controller, and it does not have this issue. Controller firmware for the Series controller is fully up to date, for what it's worth.

Steps to Reproduce

Basic usage of the controller in any game.

Expected behavior

Latency at least on par with the Xbox One controller in the same scenario.

Screenshots/Gifs

System information

# uname -a
Linux x 5.12.2-1-MANJARO #1 SMP PREEMPT Fri May 7 17:53:15 UTC 2021 x86_64 GNU/Linux
# xxd -c20 -g1 /sys/module/hid_xpadneo/drivers/hid:xpadneo/0005:045E:*/report_descriptor | tee >(cksum)
This gives a no such file or directory error.

Controller and Bluetooth information

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

Additional context

The issue doesn't occur when connected wired.

kakra commented 3 years ago

Do you run KDE? Or rather do you run kdeconnectd in particular. If yes, try uninstalling kdeconnect and retry. Just disabling it may not be enough, ensure that no kdeconnectd process is running before retrying.

Leaguesman commented 3 years ago

Huh, that was totally it. Thanks! Is this a known issue? Should I report it to the KDEConnect project? I do actually use KDEConnect quite regularly, so hopefully someone can fix it.

One other question now that I have it working, is that while there's no longer any latency on the sticks, the acceleration curve on them feels quite a bit different to the Xbox One controller, much sharper starting and stopping. Do you know if this is a driver level thing or a hardware difference? Is it configurable?

Either way, thanks again for the great work on the project.

kakra commented 3 years ago

Yes, it's known, first reported here by me: https://github.com/bluez/bluez/issues/123 - This one indicates that there's a general problem with packet QoS where inquiries block or delay other HCI events, or rather controller input events in particular.

But kdeconnectd itself seems to have a bug where it constantly spams the RF environment with inquiries. This also makes pairing/connecting the controller difficult. The bug may not be in kdeconnectd itself but rather some KIO component is triggering device searches on the bluetooth:/ KIO path every 10-20s. The report is here: https://bugs.kde.org/show_bug.cgi?id=435444

Feel free to add the information to the KDE bug report which they asked for, to reopen it. I was too busy (aka lazy) to do that, I simply re-compiled kdeconnectd without Bluetooth support and the problem was gone for me. Similar problems in the KDE Bluetooth stack are known for some longer time, so it may be worth getting this fixed upstream.

Sensitivity curves: This is currently not a driver thing because we take raw values from the controller as they come in, no conversion is done. But newer controllers have a programmable interface (introduced with Xbox Elite 2) that maybe could be used to reprogram sensitivity curves in hardware. If yours seem off, it may be worth trying to connect the controller once to Windows and check the settings with the Xbox Accessories app, it may set correct initial values. But I plan to support that feature later in our driver, even as a software emulation for older controllers not having it as a hardware feature. But this needs some reverse engineering efforts first.

Leaguesman commented 3 years ago

Hmm, I suspect the KDE guys won't necessarily want to help me, as I'm actually using GSConnect, a reimplementation of the same spec as a Gnome shell extension. It seems as though that reimplementation carries across the same behaviour of overly aggressive polling. The extension is currently unmaintained, so I'll come up with a workaround.

Interesting detail about the sensitivity curves. I was just in my Windows VM to check the firmware was fully up to date, but didn't see such an option, I'll have to take another look.

Thanks again for the prompt assistance, I think this issue can be closed given it's not your bug.

kakra commented 3 years ago

but didn't see such an option, I'll have to take another look.

It may purely be an option in the Elite 2 controller. Looking at the descriptor of your controller, it doesn't look like it provides vendor extensions for programming. The Elite 2 controller does have those. OTOH, many features may be missing over Bluetooth, only using the GIP dongle from Microsoft provides full access to all controller functions.

given it's not your bug

Problems with Bluetooth are never our bug, the driver doesn't interact with the Bluetooth protocols. All we do see is a HID device. For your controller, we are even not talking to a Bluetooth device in the kernel, we are talking to a uhid device provided by the bluez daemon. All this is completely abstracted away from us, xpadneo is just a HID driver. If one would make a lldriver for USB connection that exposes the GIP protocol as a HID device (and doing nothing more), xpadneo could work as a HID input driver even for USB cable connection (that's actually what I'm planning to add next).

kakra commented 3 years ago

I've added your ticket to the tracker for known Bluetooth issues: https://github.com/atar-axis/xpadneo/projects/11

kakra commented 3 years ago

Closed as duplicate of #297 which describes the problem better.