This is mostly a request for testing, because I've received zero feedback on the patches that I merged a month ago and libinput 1.12 is due to be out. No comments so far on the RC1 and RC2 either, so... well, maybe this gets a bit broader attention so we can address some things before the release. One can hope.
Required reading for this article: Observations on trackpoint input data and X server pointer acceleration analysis - part 5.
As the blog posts linked above explain, the trackpoint input data is difficult and largely arbitrary between different devices. The previous pointer acceleration libinput had relied on a fixed reporting rate which isn't true at low speeds, so the new acceleration method switches back to velocity-based acceleration. i.e. we convert the input deltas to a speed, then apply the acceleration curve on that. It's not speed, it's pressure, but it doesn't really matter unless you're a stickler for technicalities.
Because basically every trackpoint has different random data ranges not linked to anything easily measurable, libinput's device quirks now support a magic multiplier to scale the trackpoint range into something resembling a sane range. This is basically what we did before with the systemd POINTINGSTICK_CONST_ACCEL property except that we're handling this in libinput now (which is where acceleration is handled, so it kinda makes sense to move it here). There is no good conversion from the previous trackpoint range property to the new multiplier because the range didn't really have any relation to the physical input users expected.
So what does this mean for you? Test the libinput RCs or, better, libinput from master (because it's stable anyway), or from the Fedora COPR and check if the trackpoint works. If not, check the Trackpoint Configuration page and follow the instructions there.
6 comments:
I tested new libinput on T480s running F29 (installed the Rawhide package from COPR). It works fine, but I had to change the mouse speed to about -0.25 to make it comfortable (it was way too fast). (Gnome control center is terrible, doesn't show any numbers). It think it would be even better if the acceleration ramped up a bit more gradually (it speeds up too quickly), but it's definitely usable as it is now.
My major problem is now with GNOME UI. Because I can't configure trackpoint speed separately from mouse speed, I must choose just one device to configure properly, and the other one will be uncomfortable (and I'm really not going to adjust the slider every time I dock the laptop) :-/
Used the Copr to givt it a try with F28 on my XPS13 (9360), works fine so far
I have the following currently installed on a Lenovo W541
[508:]>rpm -qa '*libinput*'
libinput-1.11.901-201808130836git1668cd5.fc28.x86_64
libinput-debuginfo-1.11.901-201808130836git1668cd5.fc28.x86_64
libinput-debugsource-1.11.901-201808130836git1668cd5.fc28.x86_64
I've been using this with both the trackpoint and the touchpad without issues for a couple of weeks. The trackpoint seems intuitive and mostly does what I need. I'm on the fence on the acceleration - a more gradual acceleration ramp might be nicer. The current behaviour certainly helps get into the corners of the screen quickly.
Since I moved to FC28 from Debian, the trackpoint on my Thinkpad 13 has been a non-issue (I previously reported a bug which made it hard to use https://bugs.freedesktop.org/show_bug.cgi?id=98689 ).
$ rpm -qa libinput
libinput-1.11.902-201808160257gitc476524.fc28.x86_64
this works pretty well for me- I'll just echo the comment above that trackpoints should be tuneable independently of other input devices.
Thanks for your excellent work!
works good on my x1c5
Great work man. I can test it on latitude 7490 if you need it.
Post a Comment