Closed Leaguesman closed 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.
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.
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.
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.
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).
I've added your ticket to the tracker for known Bluetooth issues: https://github.com/atar-axis/xpadneo/projects/11
Closed as duplicate of #297 which describes the problem better.
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
Controller and Bluetooth information
xpadneo-btmon.txt xpadneo-dmesg.txt xpadneo-lsusb.txt
Additional context
The issue doesn't occur when connected wired.