Bug 91615

libinput 0.11 seems a bit out of date, you're sure you don't mean libinput 0.21?

Yes, of course you're right, that's 0.21.

this should've been fixed with 7013a20f8b6a441a5f80b84aa261c32dd8011f95, so something doesn't trigger here.

what's the output of udevadm test /sys/class/input/eventX (probably event6 in your case)

Created attachment 117782 [details]
udevadm test /sys/class/input/event6

Here it is.

Wait, I hadn't realized libinput 0.21 had entered Fedora so recently. I may not have restarted my machine since I upgraded from 0.20. I need to finish some work, but I'll test that soon.

right, try that then please. A simple restart of X should be enough (log out/back in). I see this udev prop set in the output:
LIBINPUT_MODEL_JUMPING_SEMI_MT=1
And when this is set, 0.21 changes the touchpad to the same input data synaptics uses (i.e. single-touch data) and barring any differences in pointer acceleration it should feel the same.

I've just tried 0.21, and I think there's been an improvement. But it still isn't as smooth as with the synaptics driver (to which I have returned). I'm not sure how to explain it, but for example I find it harder to click on the close button of a window, it looks like small moves happen that I don't master.

Also, I cannot go in one move from the bottom left to the top right corner of the screen, which is definitely possible with the synaptics driver. This is a silly test case which may have to do with the acceleration settings, but OTOH if I increase the acceleration, I suspect the first issue about precision will be aggravated.

Keep up the good work anyway!

Oh, and do you need a new evemu recording using libinput 0.21?

no, thanks. the evemu recording is straight from the kernel, the libinput version doesn't affect it.

I've just tested with libinput 1.1.5, and the experience still isn't as great as with the synaptics driver. Anything I can do to help?

(In reply to Milan Bouchet-Valat from comment #7)
> it looks like small moves happen that I don't master

can you expand on this please? what exactly do you mean with you don't master the moves? they're not small enough? the touchpad doesn't react?

(In reply to Peter Hutterer from comment #11)
> (In reply to Milan Bouchet-Valat from comment #7)
> > it looks like small moves happen that I don't master
> 
> can you expand on this please? what exactly do you mean with you don't
> master the moves? they're not small enough? the touchpad doesn't react?

Sure, at least I can try, as it's not easy to describe. Basically, I find it very hard to put the cursor over small targets like buttons or HTML links. If I move the finger very slowly, the movement is smooth and it works, but when I go a little faster (as I'm used to do on all touchpads), I often overshoot. For example, if I play at going back and forth between two points in a single move, I almost always fail.

So, yes, the moves are not small enough when ending a long movement. But certainly the touchpad does react.

Maybe this has to do with the way the movement stops, i.e. maybe it doesn't stop or slow down "as quickly" as with the Synaptics driver when I'd like it to. But that's just a vague idea. I'm not sure how I could be more helpful. Maybe a video with each driver to try showing the difference?

Actually, I also think the problem is more pronounced (or only happens) with vertical moves. Another hint: maybe the acceleration is too hard to predict, i.e. the length of the pointer move can change a lot depending on very small differences in the finger move.

Ah, got another issue. When using vertical kinetic scrolling, doing a finger move in the reverse direction to stop the scrolling has a small delay. Or at least a larger part of the finger move has no effect on the pointer. Moreover, leaving the finger on the touchpad without moving does not stop the scrolling at all, which it does with the Synaptics driver.

This may well be the same underlying issue as the other ones I described, but it's easier to pin down.

the touchpad says its size is 79x46mm, is that correct? If not, that could be the cause for uneven motion. The libinput touchpad accel is different to the old one, specifically it stops quicker than the old one. I'm surprised you have an issue with overshooting, so far I hear more of undershooting.

a video could help, yes. Sometimes it's hard interpreting textual event logs :)

(In reply to Milan Bouchet-Valat from comment #14)
> Ah, got another issue. When using vertical kinetic scrolling, doing a finger
> move in the reverse direction to stop the scrolling has a small delay. Or at
> least a larger part of the finger move has no effect on the pointer.
> Moreover, leaving the finger on the touchpad without moving does not stop
> the scrolling at all, which it does with the Synaptics driver.

huh, haven't seen that one before, please file a separate bug for this and assign it to me (with an evemu recording of a sequence that doesn't stop scrolling).

Created attachment 121386 [details]
Screencast

(In reply to Peter Hutterer from comment #15)
> the touchpad says its size is 79x46mm, is that correct? If not, that could
> be the cause for uneven motion. The libinput touchpad accel is different to
> the old one, specifically it stops quicker than the old one. I'm surprised
> you have an issue with overshooting, so far I hear more of undershooting.
That may be part of the explanation: it's actual size is 89x55mm, or 89x40mm if you exclude the bottom area corresponding to the buttons (but which can be used for moves).

> a video could help, yes. Sometimes it's hard interpreting textual event logs
> :)
See the attached video of me trying to put the pointer on the small "-" link. I'm not sure it's absolutely clear, but you should be able to see that in the first half of it I'm making relatively short moves, and in the second half larger ones which make the the overshooting well visible. Then at the end of the video you can see that slow moves are relatively precise.

> (In reply to Milan Bouchet-Valat from comment #14)
> > Ah, got another issue. When using vertical kinetic scrolling, doing a finger
> > move in the reverse direction to stop the scrolling has a small delay. Or at
> > least a larger part of the finger move has no effect on the pointer.
> > Moreover, leaving the finger on the touchpad without moving does not stop
> > the scrolling at all, which it does with the Synaptics driver.
> 
> huh, haven't seen that one before, please file a separate bug for this and
> assign it to me (with an evemu recording of a sequence that doesn't stop
> scrolling).
Sure, I filed bug 93923.

run the touchpad-edge-detector tool (part of libevdev) please and attach the output here, the touchpad size needs to be fixed in the udev hwdb. Let's see how the touchpad behaviour changes once we fix that up.

Here's what I get:
$ sudo touchpad-edge-detector /dev/input/event5
Touchpad SynPS/2 Synaptics TouchPad on /dev/input/event5
Move one finger around the touchpad to detect the actual edges
Kernel says:	x [1472..5456], y [1408..4456]
Touchpad sends:	x [1360..5563], y [1269..4618] |^C

Touchpad size as listed by the kernel: 79x46mm
Calculate resolution as:
	x axis: 3984/<width in mm>
	y axis: 3048/<height in mm>

Suggested udev rule:
# <Laptop model description goes here>
evdev:name:SynPS/2 Synaptics TouchPad:dmi:bvnHewlett-Packard:bvrF.11:bd07/08/2010:svnHewlett-Packard:pnHPPaviliondm4NotebookPC:pvr058B110000242B10000020100:rvnHewlett-Packard:rn146A:rvr58.1F:cvnHewlett-Packard:ct10:cvrChassisVersion:*
 EVDEV_ABS_00=1360:5563:<x resolution>
 EVDEV_ABS_01=1269:4618:<y resolution>
 EVDEV_ABS_35=1360:5563:<x resolution>
 EVDEV_ABS_36=1269:4618:<y resolution>

Adding this rule to /etc/udev/hwdb.d/ makes a major difference: the touchpad is now as smooth as with the Synaptics driver! I wouldn't have hoped for such a simple and radical fix! At last, I can consider the switch to Wayland as a nice experience...

So I guess you can consider this as fixed as soon as the rules are added. Thanks for the support.

Created attachment 121446 [details] [review]
0001-hwdb-add-HP-Pavilion-dm4-axis-corrections.patch

That's the systemd patch I'm going to submit, please verify it'll work. Thanks.

You can just copy the new lines into your local hwdb, no need to actually apply the patch and build systemd from git :)

I've been using this for some time, and it looks good. Out of curiosity, what's the difference with the code from my comment?

The feel is still a bit different with libinput compared with the Synaptics driver: it looks like the acceleration is stronger, i.e. the moves are slower when you make small changes, but faster when you move the finger over a longer distance. For example, to go from one corner of the screen to another, I need to move my finger less with Synaptics, even if the general speed is similar (or even lower). Not sure whether this can be tweaked. Anyway, that's perfectly usable now, I'm just looking for the perfect feel. :-)

not much, other than that it's in patch format that I can submit upstream :)

the acceleration is different in libinput and synaptics, but the problem is that it's really hard to figure out what the synaptics acceleration actually is on any specific device (it depends e.g. on the screen resolution...)
something you can get used to after a while though. we'll get to refining touchpad accel one day (bug 90735) but it's a tricky problem, to say the least.

closing, was merged in systemd upstream.

https://github.com/systemd/systemd/commit/7f39a2bdda04356a2ec0b76051382a0842012925