choppy/steppy input of analoge (delayed refresh of digital buttons as well)

T3cube commented 3 years ago

Version of xpadneo

xpadneo-dkms-git 0.9.r63.gf17a4e2-1

Severity / Impact

basically makes it unusible

[x] I've read the docs and the bug reporting instructions
[x] I don't know how to troubleshoot this further.

Describe the bug

the input apears to be choppy and refresh a several times a second instead of have fluid motions for analog inputs

Steps to Reproduce

connect the controller via wireless, monitor the controller via any program (reproducable for event and js)

Expected behavior

the analog controlls should be smoother instead of steppy

Screenshots/Gifs

how it feels and looks (this is wireless). this is rather choppy https://user-images.githubusercontent.com/70706789/120945645-d2302080-c707-11eb-87c1-88ca71deee07.mp4

how it should feel and look (this is wired). this is very smooth https://user-images.githubusercontent.com/70706789/120945653-d9572e80-c707-11eb-901b-e24bcd7113ac.mp4

System information

# Linux Valicity 5.12.9-arch1-1 #1 SMP PREEMPT Thu, 03 Jun 2021 11:36:13 +0000 x86_64 GNU/Linux

# xxd: /sys/module/hid_xpadneo/drivers/hid:xpadneo/0005:045E:*/report_descriptor: No such file or directory
4294967295 0

Controller and Bluetooth information

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

Additional context

this is a series x controller, i just updated the firmware. (i just got it today)

kakra commented 3 years ago

I ordered this hardware myself and can look into it soonish. Apparently, the mp4 videos do not give a clue about smoothness although they are 60 fps. The controllers itself seem to use an internal clock of 100 Hz, it should be fast enough to be smooth.

This may be an issue of how bluez implements the device stack using a virtual uhid device in user-space before the kernel has a chance to handle it with xpadneo. This would be something we cannot fix in xpadneo.

Some ideas:

You are using kernel 5.12: Ensure, ERTM is enabled (if you upgraded from an older xpadneo version, the disable-hack may still be in place).
Check if any background Bluetooth services are running, kdeconnect in particular (or its Gnome counterpart).
Check if kernel 5.10 LTS is any different.
Ensure that no Bluetooth inquiries are running in the background, try turning nearby Bluetooth devices off for the duration of testing.

T3cube commented 3 years ago

I checked other issues before made this issue. I tried switching from the lts kernel as a troubleshooting step. I enabled ertm (reverted the workaround). The only bluetooth service i have making the requests is bluez. I didnot install kdeconnect(also can confirm it is not installed on the system). I also picked up a new Bluetooth dongle because my previous one had issues with continuous scanning and receiving information in a smooth manner that was very noticeable when using something like a wii remote. And it also literally fell apart so I can no longer test with it. I made sure that no other Bluetooth devices were running (or at least picked up) and I disabled discovery once the controller was connected to see if that would make a change.

Would you like me to post the changes that I made to my Bluetooth main.conf? I had to make some in order to avoid the connect disconnect pairing loop.

kakra commented 3 years ago

Could be useful, please attach your main.conf and identify the changes you made.

T3cube commented 3 years ago

main.conf.txt good old grep --invert-match to show everything uncommented.

kakra commented 3 years ago

Is it this problem? https://github.com/bluez/bluez/issues/156

T3cube commented 3 years ago

main.conf.txt that sounds about right.

here is the main.conf for bluez (oops, i see i already shared it. my mistake)

kakra commented 3 years ago

We found a possible solution for this by setting the LE connection latency manually, but it doesn't persist across reconnects yet. It's documented in the above linked bluez issue.

atar-axis / xpadneo