Bug 97813

Created attachment 126534 [details]
evemu-record output for a 100mm movement on the x axis (bluetooth)

Created attachment 126535 [details]
evemu-record output for a 100mm movement on the x axis (usb)

while connected through the usb dongle, the movement is correct. Here is the evemu-record output for the same movement

For the archive and as a reminder to myself: the bluetooth events are 70ms apart, there's a high chance this messes with the acceleration and causes the slow movement

somewhat related (and because zubzub just mentioned this on IRC): could there be some interference or otherwise bad reception with the receiver? I'd expect it to be less regular in that case but it may be worth a try

Created attachment 127709 [details]
gnuplot of the velocity of the pointer from the two recordings

Augmented the libinput accel code with a printf and then ran gnuplot over it. 
What I printed was timestamps for each event and the calculated velocity in units/ms.

This image shows the two velocities compared, the recordings are roughly the same length over time so it overlays nicely. What you can see clearly is that the velocity when over bluetooth is a fraction of that over USB. This is the cause for the slowness - the mouse simply sends us less mickeys.

btw, it's not caused by any internal timeouts happening because of the 70ms between events, I checked for that.

What happens when you run the mouse-dpi-tool over bluetooth vs usb? What resolution does it show?

Created attachment 127710 [details]
acceleration factor for the two recordings

The acceleration factor applied to the motion for the events in the recordings. On the bluetooth (slow) mouse the factor is practically always 1, so no acceleration is applied, the device is too slow to trigger acceleration.
The usb one is maxed out at 2 for a lot of the time or has some factor applied, it's almost never 1. This is a direct consequence of the calculated speed but it amplifies the different feel, the fast movement is accelerated and thus feels even faster, the slow movement isn't and thus feels slower.

Created attachment 127711 [details] [review]
diff for the debug printf

This was the printf used, then run against the two evemu recordings. Just storing it here so it's easy to reproduce the data.

Created attachment 127714 [details]
mouse-dpi-tool for usb

The covered distance is ~240mm.
This gives
- a covered distance of 8558 units
- a resolution of 905,72
- a frequency of 287.8Hz

Created attachment 127715 [details]
mouse-dpi-tool for bluetooth


The covered distance is ~240mm.
This gives
- a covered distance of 1062 units
- a resolution of 112.395
- a frequency of 14.4Hz

yep, that would do it. pop this hwdb entry into /etc/udev/hwdb.d/99-x1-mouse.hwdb

mouse:bluetooth:v17efp6088:name:ThinkPad X1 Mouse:
 MOUSE_DPI=120@14

then run sudo udevadm hwdb --update, sudo udevadm test /sys/class/input/event20. Check if the MOUSE_DPI property shows up, if so, restart X and see what changes.

the entry is seen by systemd-hwdb query "mouse:bluetooth:v17efp6088:name:ThinkPad X1 Mouse:" but not applied by udevadm test

seems we are facing another bug, currently investigating on it with grawity on irc (#systemd), but I'm afraid it will go beyond my capacities…

Created attachment 127716 [details]
udevadm info -a for the bluetooth device

for the archive, investigations showed that ID_BUS is not defined

This is probably related to something in 60-persistent-input.rules, and to the lack of SUBSYSTEMS=="bluetooth" in the output of udevadm info -a

Note: adding an explicit rule
ATTRS{name}=="ThinkPad X1 Mouse", ENV{ID_BUS}="bluetooth", GOTO="persistent_input_end"
to 60-persistent-input.rules
made MOUSE_DPI to appear in the output of udevadm test

Then a restart increased mouse speed (but it is not as fluent as while connected through usb dongle)

(In reply to CircleCode from comment #12)
> Created attachment 127716 [details]
> udevadm info -a for the bluetooth device
> 
> for the archive, investigations showed that ID_BUS is not defined
> 
> This is probably related to something in 60-persistent-input.rules, and to
> the lack of SUBSYSTEMS=="bluetooth" in the output of udevadm info -a

please file a bug for that against systemd. this should be fixed there so we don't run into this with other devices. relying on ID_BUS is somewhat important :)


> Note: adding an explicit rule
> ATTRS{name}=="ThinkPad X1 Mouse", ENV{ID_BUS}="bluetooth",
> GOTO="persistent_input_end"
> to 60-persistent-input.rules
> made MOUSE_DPI to appear in the output of udevadm test
> 
> Then a restart increased mouse speed (but it is not as fluent as while
> connected through usb dongle)

Given the huge delay between events, I'm not sure we can do much about that. 70ms is quite big, I can't remember what the delay is where humans notice it, but I'm sure it's below 70ms. out of interest, did you try the evdev driver - does this work better? and have you tried it under windows by any chance?

> please file a bug for that against systemd. this should be fixed there so we don't
> run into this with other devices. relying on ID_BUS is somewhat important :)

Done in https://github.com/systemd/systemd/issues/4566

> Given the huge delay between events, I'm not sure we can do much about that. 70ms is quite big,
> I can't remember what the delay is where humans notice it, but I'm sure it's below 70ms.
> out of interest, did you try the evdev driver - does this work better?

Not tried it yet, will give it a try

> and have you tried it under windows by any chance?

yes, it works very fluently under windows 10, so I suppose there is something different there…
Do you know if one can measure something under windows to catch the differences?

did the evdev driver work at all? I don't know what you could do under windows to catch the difference, sorry. Short of a USB and bluetooth sniffer anyway.

if the evdev driver works, we know this is a libinput issue, otherwise there isn't much we can do beyond that DPI entry, and that is now in systemd hands.

I tried the evdev driver with the following xorg.conf.d file:
--8<-------------------------
Section "InputClass"
        Identifier "X1 mouse"
	MatchProduct "X1"
	Driver "evdev"
EndSection 
------------------------->8--

the results are the following:

- with libinput driver, the command `xinput --list --short` shows `ThinkPad X1 Mouse` under `Virtual core pointer` AND `Virtual core keyboard` (with 2 different ids), while it appears only under `Virtual core pointer` with evdev driver

- with evdev driver, the mouse is quite as slow as with libinput

- with evdev driver, `xinput --list-props` lists a lot of "unknown" buttons

Should I do some more tests?

nope, that's all that's needed, thanks. libinput splits devices that have pointer and keyboard capabilities into two X devices (which works around a few bugs in the server). evdev doesn't do that, so having only one device is expected. See bug 92896.

the unknown buttons doesn't matter either, they're just for decorative purposes, I don't think anything uses button labels.


I'm gonna have to close this one as fixed. There is the hwdb entry that at least improves things but with the 70ms delay we can't make it as smooth as on USB. The systemd issue is unrelated to libinput. Beyond that, i don't know what else to do, we simply don't have enough data to make this perfect.

The only option we have is a custom acceleration method with motion prediction for this device, b I don't have the time to implement this. So unless you want to do this yourself, this is as good as we're going to get, sorry.

Don't be sorry, it's sad Lenovo did not provide enough information (or better drivers) to make this work correctly under linux.
You spent a lot of time on this issue, including helping and teaching me… thanks

The 70ms delay is caused by the bluetooth low energy mode of this mouse. And it can be lowered by reducing the min and max LE connection parameters with "hcitool lecup".

As I am not at al a bluetooth expert, I wonder if these parameters can have other side effects (if I understand it correctly, they are applied system-wide)

And as a side question, it seems hcitool is deprecated, so is there another way to achieve the same result?

Last question, for my understanding: what exactly do these parameters?

I'm not a bluetooth expert too, I simply noticed that these parameters solved a similar issue on a completely unrelated bluetooth device, that only shared the characteristic to be a "low energy" device too:

https://github.com/IanHarvey/bluepy/issues/117

My understanding of these min/max values is that they define a fixed rate, used by low energy bluetooth to exchange data, allowing the hardware to enter power saving mode between communications, instead of being always on.

I think these params are specific to a connection, via the handle value.

there are several options here for libinput to handle this when detected:
- issue a warning in the log to point to documentation on how to resolve this using the hcitool (or writing to the sysfs files). This is the easiest one to add
- change the connection details itself by writing to the sysfs files. This could be an issue because we may not have write access
- change the connection details by monitoring/writing to the bluez DBus interface. This is the most complex issue because it'd require dbus handling inside libinput which we don't have yet

I think even the first one (log + docs) would be very useful and I'd really appreciate a patch to that extent. Unfortunately I don't have a device to reproduce this here, so I'll rely on you to test the exact sequences of steps.

If you're interested, please open a new issue here: https://gitlab.freedesktop.org/libinput/libinput/issues