Bug 93448 - Trackpoint speed lock
Summary: Trackpoint speed lock
Alias: None
Product: Wayland
Classification: Unclassified
Component: libinput (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Wayland bug list
QA Contact:
Depends on:
Reported: 2015-12-19 17:33 UTC by Juraj Fiala
Modified: 2017-08-17 22:09 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:

trackpoint speed lock recording (66.77 KB, text/plain)
2016-03-18 16:50 UTC, Juraj Fiala
Recording of the drag. (1.19 MB, text/plain)
2016-08-12 06:31 UTC, Juraj Fiala
Saved webpage containing graph (175.50 KB, application/zip)
2017-06-02 11:29 UTC, Juraj Fiala

Description Juraj Fiala 2015-12-19 17:33:25 UTC

I have a Lenovo Thinkpad X220 and I used the trackpoint all the time. However I often encounter this bug where the trackpoint speed gets locked in a certain direction, and it keeps pulling the cursor until I press a button on the keyboard. Sometimes it's rarely noticeable but considerably worsens accuracy, making it very frustrating. I don't know under what conditions it happens, even though I try to notice every time.

If you need any more info, just ask. Thanks.
Comment 1 Peter Hutterer 2015-12-22 00:23:46 UTC
run sudo evemu-record on the trackpoint device and check if there are still events coming out of the kernel when this happens. This way we can identify where the issue lies.
Comment 2 Peter Hutterer 2016-01-27 06:01:13 UTC
Comment 3 Juraj Fiala 2016-02-23 18:09:31 UTC
Hey, sorry for the delay, didn't have much time. It happened thrice today but I still don't have an idea when it happens.

Also, noticed that it's just trying to reach a certain position. When it reaches it it stops pulling. The target is just a few pixels aways, and it seems to be relative to the cursor. Or maybe it just needs a moment without any mouse movement to do it's thing. I dunno. It's weird.

Shall I just run the command in the background?
Comment 4 Peter Hutterer 2016-02-24 21:44:34 UTC
yeah, just cancel it and restart it regularly. this command produces a recording of the input event sequence, if you end up with an hour-long recording it may take me that long to replay it here - not very conductive to quick fixes ;)

if you restart it every 2 minutes you have only the last 2 min in the log, much easier to analyse.
Comment 5 Juraj Fiala 2016-03-18 16:48:49 UTC
OK so I finally managed to catch something. My automated script didn't work and I didn't have any more time so I just left it, but today I managed to catch the bug while scrolling, and since it won't stop if until I stopped scrolling, I managed to alt+tab to a terminal and run the command. Heres the output. I let the bug do its thing while holding the middle scroll button down and sometimes moving the mouse, and then I let go. I think I saw a tiny move after that, then it stopped. Hope you can dig something useful from it. It's only a few seconds.
Comment 6 Juraj Fiala 2016-03-18 16:50:18 UTC
Created attachment 122420 [details]
trackpoint speed lock recording
Comment 7 Peter Hutterer 2016-04-04 03:53:09 UTC
fwiw, if you grab evemu from git it now has the functionality to auto-resume new recordings when the device is quiet for a while, so you don't have to wrap it into a script.

so, unfortunately, this recording doesn't help much, it looks like completely normal x/y movement of the trackpoint. this can be a problem: either the hw keeps sending events even when you're not touching it or libinput gets stuck somewhere. The recording here only has one gap at 12.5 seconds into it where no events happen for ~1.5 seconds. from your description this doesn't sound like that's the occurance of the bug, right?

you get this bug without scrolling too, right? trackpoint motion events are a very simple code path that doesn't have any state, we just forward kernel events. so this indicates too that it's a hw issue.

try if you can reproduce it with large pressure values in one direction, historically this has been how you can poke the trackpoint into doing something weird.
Comment 8 Peter Hutterer 2016-08-05 04:45:10 UTC
Comment 9 Juraj Fiala 2016-08-05 20:27:46 UTC
Yes, I'm still here, the bug still occurs. Sorry for the delay, I had no free time at the end of the school year and my summer job just ended today so maybe I'll finally get to this. Question though, will it help if I post a timestamp where the bug occurred along with the log?
Comment 10 Peter Hutterer 2016-08-09 01:13:42 UTC
yeah, a timestamp would help because I can cut down the recording to the last couple of events that matter.

fwiw, evemu 2.4 has been released since, you can use --autorestart to have it restart logfiles after a timeout.
Comment 11 Juraj Fiala 2016-08-09 06:29:12 UTC
On it.
Comment 12 Juraj Fiala 2016-08-12 06:31:20 UTC
Created attachment 125725 [details]
Recording of the drag.

I noticed the drag around 08:22:44, but it's likely it started a bit sooner.
Comment 13 Francis Herne 2016-12-08 09:20:58 UTC
Similar behaviour can be caused by the auto-calibration feature of the BIOS.

If you hold the trackpoint in a fixed position for a moment (most commonly while scrolling), it will decide that point is the centre. Releasing the trackpoint will then cause an uncontrolled movement in the opposite direction until it recalibrates.

By default, the timeout is 0.5s, which is (IME) rather too low and causes miscalibrations during normal use.

Try writing to /sys/devices/platform/i8042/serio1/serio2/drift_time (in units of 0.1s), and see if it's any better or at least noticeably different. `20` (2s) seems like a good number for me.
Comment 14 Peter Hutterer 2017-05-09 03:22:28 UTC
Juraj, can you confirm that this is the issue you're seeing and that changing drift_time fixes it?
Comment 15 Juraj Fiala 2017-05-09 13:40:13 UTC
I’ve switched to Fedora and I’m not sure whether I’ve seen it here, I’ll post back if I see it and then I’ll try the fix.
Comment 16 Peter Hutterer 2017-05-17 03:15:55 UTC
I gather it hasn't reappeared in the last 2 weeks? Closing this bug for now, please re-open if it happens again.
Comment 17 Juraj Fiala 2017-06-02 11:21:37 UTC
It happened again, this time I finally have a way to reproduce it.
Comment 18 Juraj Fiala 2017-06-02 11:29:50 UTC
Created attachment 131668 [details]
Saved webpage containing graph

When you open this webpage, you’ll see a temperature graph. When you hover your mouse above the nodes on it it shows the temperature. Start at the beginning and continue through the graph while going slow enough to read the temperatures. You will probably notice that during this time the trackpoint is hard to control. At the end the trackpoint should have a slight to strong pull back in the direction of the line.

I can reproduce this on Fedora 25.

❯ cat /sys/devices/platform/i8042/serio1/serio2/drift_time
Comment 19 Peter Hutterer 2017-06-13 00:02:05 UTC
Judging by your description, what you're seeing is the effect of the trackpoint's re-calibration.

drift_time means if the firmware detects continuous pressure in one direction for more than drift_time seconds, it recalibrates this as default neutral pressure. When you then release, the real hardware-neutral now appears as movement in the opposite direction -  the trackpoint takes a second or so to recalibrate itself but that's the pull back you see.

I don't think that's something we can reasonably fix in libinput, it's a way how trackpoints work and your best option is likely to increase the drift_time to something quite high so you don't see that effect. Or avoid these types of movements.

The best we could do in libinput is to have something monitor the trackpoint coordinates and post a warning in the log when it may trigger but this could a) cause false positives and b) just be hidden in some log somewhere. So a lot of code for very little gain.

I think just increasing the drift time is the only real option here, sorry.
Comment 20 Peter Hutterer 2017-06-13 01:46:39 UTC
(In reply to Peter Hutterer from comment #19)
> drift_time means if the firmware detects continuous pressure in one
> direction for more than drift_time seconds

after reading up on these details: this isn't in seconds but in units of ~107 ms, so a drift time of 5 is ca 535ms. and in order to trigger the re-calibration, the x/y deltas have to be small and steady which is why this particular use-case of slow motion triggers the bug but not others.
Comment 21 Peter Hutterer 2017-06-19 03:56:12 UTC
Juraj, can you please try the drift_time and let me know if that fixed it, thanks
Comment 22 Juraj Fiala 2017-06-25 19:02:58 UTC
(In reply to Peter Hutterer from comment #21)
> Juraj, can you please try the drift_time and let me know if that fixed it,
> thanks

It didn’t completely fix it (I managed to reproduce it once since then—it was a bit weird since I had to wait a much longer time for it to fix itself), but it did make it less often (I can’t say for sure because I thought I set it to 20 permanently but found out I did not). Do you think it would be a good idea for libinput to set it?
Comment 23 Peter Hutterer 2017-06-26 01:09:10 UTC
Mind you, the issue cannot be "fixed" as such, because you're just hitting a corner case of how trackpoints work vs your specific use-case. You'll always be balancing the two, there isn't anything we can do here I think. You can increase the timeout further to reduce the chance of it triggering but it's a trade-off.

libinput cannot set it because it doesn't have write access to the sysfs files (and it may not have write access even when run in the compositor). We can watch it and maybe put a warning in, but that's about it. But we won't know when it kicks in, so it'd be a fair bit of effort for a high chance of false positives.
Comment 24 Peter Hutterer 2017-08-17 22:09:53 UTC
I'm going to close this bug now, see comments #19 and #23. There isn't really much we can do in libinput, sorry.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.