Bug 106506

Please run the libinput measure trackpoint-range tool and follow its instructions

> Please run the libinput measure trackpoint-range tool and follow its instructions

I had already done that prior to filing this bug report, and I have also tested various values of LIBINPUT_ATTR_TRACKPOINT_RANGE. I bumped TRACKPOINT_DEFAULT_MAX_DELTA because my pointer wasn't getting any faster no matter how low I set LIBINPUT_ATTR_TRACKPOINT_RANGE to and "libinput debug events" confirmed that (all deltas clamped at 60).

On a single screen, the speed was somewhat acceptable, but once I started trying to move the pointer between screens, it was really annoyingly slow.

I just tried another round of testing with lower values of LIBINPUT_ATTR_TRACKPOINT_RANGE, and my findings are that lowering that attribute's value causes the slow speed movements to become too fast to precisely hit anything, but the top speed is still too slow.

TL;DR: I just want fast movements to be faster. Slow movements are okay in the current implementation.

What was the actual value the trackpoint range tool gave you? And did you verify that the range was set on the udev device correctly? The hwdb is a bit fickle.

the max delta is currently at 60 as you noted, so the delta returned from the accel code is (60, 60) maximum. it's not directional, so a diagonal max delta is a longer vector than a horizontal/vertical, but meh.

Given the average trackpoint with ~80Hz this means at full pressure you'd get 60 * 80 pixels per second = 4800 pixels. That's the limit, but that should in your setup allow for a full movement from left to right within a second. The timestamps in your log suggest that the average report rate is around ~10ms, so this isn't an issue with the trackpoint not reporting fast enough.

I have a 3840x1200 setup here and with the right range configured (30 here), I can verify the above and cross from left to right within approx 1 second. That's a far cry off the 5 seconds you mentioned in the first post.

So what's going on here?

> What was the actual value the trackpoint range tool gave you?

With default settings, I think I got something like ~30, but after patching libinput to lift the speed limit, I got something like 15-20, and a lot less muscle strain. A slow pointer makes me press harder.

> And did you verify that the range was set on the udev device correctly? The hwdb is a bit fickle.

Yes, verified with "udevadm info --query=all --name=/dev/input/eventXX". Also, like I mentioned in my previous post, lowering LIBINPUT_ATTR_TRACKPOINT_RANGE makes the slow speed movements way too quick and imprecise, but still doesn't get me to the next screen fast enough.

> I have a 3840x1200 setup here and with the right range configured (30 here), I can verify the above and cross from left to right within approx 1 second. That's a far cry off the 5 seconds you mentioned in the first post.

It's not 3840x1200, it's 3840 + 1200. Two screens side by side. And perhaps you're used to hitting your trackpoint hard? I find that I start feeling pain on the back of my palm if I use the trackpoint without first adjusting the sensitivity.

If it helps, with libinput 1.8, I had a comfortable setup with POINTINGSTICK_CONST_ACCEL=10 and the sysfs sensitivity node set to 255.

Also the report rate doesn't seem to be at 10ms intervals -- it's 16/(1.44-1.18) = 61.5Hz, judging from the log in the description.

I just measured the trackpoint range again with different display setups:

Side-by-side (3840x2160 on the left, 1920x1200 on the right):
Average for abs deltas: x:  45 y:  16                                                                                                                                                                                                                                                                                                                                                    
Median for abs deltas: x:  44 y:  14
95% percentile for abs deltas: x: 103 y:  42

External only (3840x2170):
Average for abs deltas: x:  37 y:  21                                                                                                                                                                                                                                                                                                                                                    
Median for abs deltas: x:  34 y:  17
95% percentile for abs deltas: x:  95 y:  52    

Internal only (1920x1200):
Average for abs deltas: x:  25 y:  14                                                                                                                                                    
Median for abs deltas: x:  21 y:  12
95% percentile for abs deltas: x:  72 y:  38

As you can see, the trackpoint range varies quite significantly depending on display size.

urgh, really? that is terrible and would make it virtually impossible for libinput to ever do the right thing... 

Please re-confirm this though, just run the commands again. I find that I get quite different results every time I re-run-this and have to run it a few times in a row to get reliable readings. You also said above:

> A slow pointer makes me press harder.

Please make sure you're not affected by the speed of the pointer motion on the screen. You may be inclined to push harder on the large screen to hit the edges, resulting in higher deltas. This could affect the input data.

The instructions to hit the screen edges are just so users know what to roughly do, the tool isn't affected by the visible pointer movement at all - the trackpoint will keep sending events even when the pointer is at the screen edge.

> And perhaps you're used to hitting your trackpoint hard?

I admit I only use the trackpoint to test things, I hardly ever use it directly. So I'm not sure what I'm used to and I definitely can't comment in regards to RSI etc. Which effectively means I'll question everything you tell me for basic sanity, but otherwise you'll have the last word on everything :)

(In reply to Peter Hutterer from comment #8)
> urgh, really? that is terrible and would make it virtually impossible for
> libinput to ever do the right thing... 
> 
> Please re-confirm this though, just run the commands again. I find that I
> get quite different results every time I re-run-this and have to run it a
> few times in a row to get reliable readings.

Yeah the behaviour runs around a bit, but my results seem to be pretty consistent. I just tried moving my pointer around each of my screens without mode-switching, and got the following results:

Just the internal:
Average for abs deltas: x:  22 y:  14
Median for abs deltas: x:  18 y:  12
95% percentile for abs deltas: x:  62 y:  39

Just the external:
Average for abs deltas: x:  32 y:  19
Median for abs deltas: x:  30 y:  17
95% percentile for abs deltas: x:  80 y:  50


> You also said above: 
> > A slow pointer makes me press harder.
> 
> Please make sure you're not affected by the speed of the pointer motion on
> the screen. You may be inclined to push harder on the large screen to hit
> the edges, resulting in higher deltas. This could affect the input data.

I think that this is exactly what's happening, but it's also possible the the firmware is sending larger inputs in response to longer straight movements.

> The instructions to hit the screen edges are just so users know what to
> roughly do, the tool isn't affected by the visible pointer movement at all -
> the trackpoint will keep sending events even when the pointer is at the
> screen edge.

With the test I just did in this post, I was roughly drawing large circles touching the screen edges without bothering to hit the corners.
 
> > And perhaps you're used to hitting your trackpoint hard?
> 
> I admit I only use the trackpoint to test things, I hardly ever use it
> directly. So I'm not sure what I'm used to and I definitely can't comment in
> regards to RSI etc. Which effectively means I'll question everything you
> tell me for basic sanity, but otherwise you'll have the last word on
> everything :)

:)

Created attachment 139617 [details] [review]
Patch to bump TRACKPOINT_DEFAULT_MAX_DELTA to 120

Created attachment 139618 [details] [review]
Patch to use accelerated deltas for scrolling

This patch goes off on a slight tangent to also use accelerated coordinates for scrolling, as it feels more natural for the a scrolled document to move about with the same rate as the pointer would move when not scrolling (e.g. similar to grabbing the document and moving it around, but with axes inverted).

First commit is on master now, thank you.

commit 8e30b3069cd11f1a3e4fea6b12d094dc0b203b62
Author: Chow Loong Jin <>
Date:   Fri May 18 03:11:57 2018 +0800

     Bump TRACKPOINT_DEFAULT_MAX_DELTA to 120

So I think we can close this bug as fixed?


As for using accelerated deltas while scrolling - bit of a contested point but we don't use those anywhere for scrolling and instead leave it up to the caller to adjust the scroll speed as necessary. IIRC GTK already does that where long documents have different scroll speed/scroll acceleration than short documents.
Changing this now would result in some applications double-accelerating, which is going to make things worse.

(In reply to Peter Hutterer from comment #12)
> First commit is on master now, thank you.
> 
> commit 8e30b3069cd11f1a3e4fea6b12d094dc0b203b62
> Author: Chow Loong Jin <>
> Date:   Fri May 18 03:11:57 2018 +0800
> 
>      Bump TRACKPOINT_DEFAULT_MAX_DELTA to 120
> 
> So I think we can close this bug as fixed?

Sure, thanks. I've opened another bug to track the accelerated scrolling issue: https://bugs.freedesktop.org/show_bug.cgi?id=106648