Bug 93448

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.

ping?

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?

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.

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.

Created attachment 122420 [details]
trackpoint speed lock recording

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.

ping?

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?

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.

On it.

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.

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.

Juraj, can you confirm that this is the issue you're seeing and that changing drift_time fixes it?

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.

I gather it hasn't reappeared in the last 2 weeks? Closing this bug for now, please re-open if it happens again.

It happened again, this time I finally have a way to reproduce it.

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
5

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.

(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.

Juraj, can you please try the drift_time and let me know if that fixed it, thanks

(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?

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.

I'm going to close this bug now, see comments #19 and #23. There isn't really much we can do in libinput, sorry.