[Wayland-bugs] [Bug 91369] Libinput 0.19 and 0.20 ignore POINTINGSTICK_CONST_ACCEL
bugzilla-daemon at freedesktop.org
bugzilla-daemon at freedesktop.org
Wed May 10 09:03:40 UTC 2017
https://bugs.freedesktop.org/show_bug.cgi?id=91369
--- Comment #42 from Peter Hutterer <peter.hutterer at who-t.net> ---
First analysis here. The range differs greatly. Pressing hard on the trackpoint
I have here (which most of libinput's accel is tested against) I can easily get
into the 30+ range for REL_X/Y. Both recordings in Commment 41 go up to a max
of 15. In addition, the sample frequency is lower, ~70Hz vs my 100Hz.
This results in significantly different speeds being calculated. The
CONST_ACCEL in libinput isn't just used as a straightforward multiplier but it
adjusts the acceleration curve so that it accelerates sooner and has a higher
maximum. [1]
This works provided we get into that range.
Looks like Iiro never gets close to the maximum. The data I get from this,
overlaid onto the acceleration curve matches exactly. The problem is that it
just never really gets into the differing range. For reference, look at the
low-dpi graph here:
https://wayland.freedesktop.org/libinput/doc/latest/pointer-acceleration.html
The events are almost all left of the x:0.001 marker, where the difference
isn't as pronounced yet and CONST_ACCEL has relatively little effect.
In other words: we need to a) rethink the trackpoint acceleration for these
devices and b) possibly need some property to auto-scale the range of the
trackpoint. I'm not sure CONST_ACCELERATION fits the bill as well as we hoped.
[1] A straightforward multiplication can make pixel-precision impossible, a
delta of 1/1 would move 3/3 with a a simple const accel of 3
--
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-bugs/attachments/20170510/96b4114a/attachment.html>
More information about the wayland-bugs
mailing list