This issue persists with all Linux distributions tested on the hardware.

Currently used libinput version is 1.10.2 in Fedora 27.

Try libinput 1.10.4 please, it has a bunch of jitter-related fixes. Also, *please* provide some description in the bug reports. There's one person working on libinput but a million ppl filing bugs. Making me click through three links to get an idea of what the bug is about is not an efficient use of my time.

Created attachment 138941 [details]
Mouse movement

The attachment shows the cursor movement as I am experiencing it. Very jumpy movement. Apparently this is due to firmware 8.1 for the touchpad, which I currently have.

The X220 quirk yields somewhat better results but with a wild acceleration contrast between slow movements and fast movements. Slow movements are very slow and fast movements are very fast.

I will try 1.10.4 and report back.

Created attachment 138942 [details]
evtest

1.10.4 yields same behavior. I attached evtest output.

sorry, I need an evemu-record output because that's what I can replay here, evtest cannot be replayed. The firmware 8.1 version doesn't matter here because the hw is different and that one doesn't suffer from the same issue (afaik). So the x230 quirk may do something but it's not designed for that hardware.

Created attachment 138944 [details]
evemu-test

Attached evemu-record output with libinput 1.10.4.

deltas on a per-event basis:

 0.544368: ↙←   -2/   1 |  *********** | 
 0.554709: ↙↓   -2/  18 |  *********** | 
 0.564084: ↙↓   -2/  18 |  *********** | 
 0.574229: ↙←  -21/  18 |  *********** | 
 0.584444: ↙↓   -2/  18 |  *********** | 
 0.595000: ↙↓   -4/  18 |  *********** | 
 0.604237: ↙←  -22/  18 |  *********** | 
 0.624738: ↙↓   -4/  18 |  *********** | 
 0.635189: ↙↓   -4/  18 |  *********** | 
 0.644283: ↙←  -22/  18 |  *********** | 
 0.654523: ↙↓   -1/  18 |  *********** | 
 0.664768: ↙↓   -2/  18 |  *********** | 
 0.675160: ↙←  -24/  18 |  *********** | 
 0.685256: ↙↓   -2/  18 |  *********** | 
 0.695281: ↙←  -24/  18 |  *********** | 
 0.709745: ↙↓   -2/  18 |  *********** | 
 0.725301: ↙←  -28/  18 |  *********** | 
 0.735631: ↙↓   -2/  18 |  *********** | 
 0.744848: ↙↓   -2/  18 |  *********** | 
 0.755461: ↙←  -25/  18 |  *********** | 
 0.765650: ↙↓   -4/  18 |  *********** | 
 0.776020: ↙←  -27/  18 |  *********** | 

 1.166998: ↖↑   -1/  -2 |  *********** | 
 1.177127: ↖↑   -1/  -2 |  *********** | 
 1.187562: ↖↑   -2/ -19 |  *********** | 
 1.197899: ↖↑   -2/ -19 |  *********** | 
 1.208095: ↖←  -20/ -19 |  *********** | 
 1.218402: ↖←  -20/  -2 |  *********** | 
 1.227577: ↖←   -2/  -2 |  *********** | 
 1.237896: ↖↑   -1/  -2 |  *********** | 
 1.248211: ↖←   -2/  -2 |  *********** | 


 1.951817: ↑↗    1/  -1 |  *********** | 
 1.962119: ↑↗    1/  -1 |  *********** | 
 1.972333: ↑↗    1/  -1 |  *********** | 
 1.982479: ↑↗    1/  -1 |  *********** | 
 1.991914: →↗   19/  -1 |  *********** | 
 2.012382: →↗   19/  -2 |  *********** | 
 2.022765: →↗   19/  -1 |  *********** | 
 2.033004: ↑↗    1/  -1 |  *********** | 
 2.042179: ↑↗    1/ -17 |  *********** | 


So yeah, this is very much garbage coming out of the device. No idea why this is supposed to work fine with synaptics though, I don't think it does any smoothing over what we do already in libinput.

On some boot-ups I get a smooth mouse in libinput also. Just like it is supposed to be. But after a reboot it goes away. Maybe 1/15 boot-ups.

Synaptics driver in X.org is perfectly fine 100% of the time, as it was in Windows, the OS the laptop came with.

What further info can I provide?

What happens when it's bumpy and you reduce the touchpad speed from the default of 0? I have a strong suspicion that the only reason the synaptics driver works better here is because it has a lower by-default acceleration (slower speed) and thus doesn't amplify the jumps as much as libinput does.

Created attachment 138991 [details]
Reduced touchpad speed evemu-record

I reduced the touchpad speed all the way in settings and tested. The mouse is too slow and just - feels weird still. Inaccurate and won't even detect two finger scroll now.

> won't even detect two finger scroll now.

that's... strange. the code that looks at the speed setting is not called from the two-finger scrolling code.

Can you confirm please:
At the speed where you notice the bumps, is the default speed in synaptics faster or slower than libinput?

Can you observe the bumps in synaptics? They are most likely smaller but still there, so watch closely, do you get 1-3 pixel jumps with synaptics when libinput jumps a lot more?

ok, I just replayed this here to check a patch that I thought would fix this - this data is complete garbage. It has a distinct saw tooth behaviour that causes the jumpy behaviour, e.g.:

19.038526: ↙↓   -1/   1 |  *********** | 
19.047722: ↙←   -2/   1 |  *********** | 
19.057847: ↙←   -2/   1 |  *********** | 
19.068035: ↙←   -4/   1 |  *********** | 
19.078270: ↙←  -22/   1 |  *********** | 
19.088396: ↙←  -22/  21 |  *********** | 
19.097523: ↙↓   -1/  21 |  *********** | 
19.107754: ↙↓   -2/  21 |  *********** | 
19.117948: ↙↓   -1/  21 |  *********** | 
19.128083: ↙↓   -2/  21 |  *********** | 

or:

17.026707: →↘   22/   1 |  *********** | 
17.036102: →↘   22/   1 |  *********** | 
17.046134: →↘   22/   1 |  *********** | 
17.056361: →↘   22/   1 |  *********** | 
17.066739: →↘    1/   1 |  *********** | 
17.096367: →↘    1/   1 |  *********** | 
17.106718: ↓↘    1/  19 |  *********** | 
17.116698: ↓↘    1/  19 |  *********** | 
17.127087: ↓↘    1/  19 |  *********** | 
17.137231: ↓↘    1/  19 |  *********** |

The questions in comment #15 are still valid but I suspect the only way to get rid of those jumps is by turning the pointer acceleration down by quite a bit.

Created attachment 139033 [details]
synaptics parameters

(In reply to Peter Hutterer from comment #15)
> > won't even detect two finger scroll now.
> 
> that's... strange. the code that looks at the speed setting is not called
> from the two-finger scrolling code.
> 
> Can you confirm please:
> At the speed where you notice the bumps, is the default speed in synaptics
> faster or slower than libinput?
> 
> Can you observe the bumps in synaptics? They are most likely smaller but
> still there, so watch closely, do you get 1-3 pixel jumps with synaptics
> when libinput jumps a lot more?

Synaptics driver's speed is in no way slow. There are tiny bumps in synaptics also, maybe 1-3 pixels like you said. The acceleration in synaptics is much lower. I wasn't sure which setting was cursor speed so attached all synaptics parameters.

I just realized something. Remember when I said on some boots the trackpad is silky smooth with libinput, maybe 1/10 times? Well it turns out when that type of boot does occur, synaptics and libinput are absolutely smooth, libinput doesn't have the huge saw tooth pattern and synaptics doesn't have the small 1-3 pixel one.

I am not sure what causes this problem. However, on the boots that do have the jumpy cursor bug, synaptics seems to compensate for it with drastically less acceleration, reducing it down to just a few pixel jumps. Your prediction about acceleration was correct.

I also have a suspicion that, like previous users have reported, when the touchpad firmware is updated to 8.1 from Windows, this bug occurs with Linux. X220 and X240 users have reported the same behavior. I have both of those Red Hat Bugzilla tickets linked in See Also.

Created attachment 139118 [details] [review]
0001-filter-always-average-the-velocity-of-the-first-two-.patch

Does this patch against libinput help a bit?

There isn't any visible difference.

I applied the patch and built libinput from source. xorg-driver-input-libinput is distro-provided. Am I missing something?

Restarted the X server too? or the wayland compositor?

Yes. Restarted the system in fact.

Right, guess it doesn't provide any visible benefits then. fwiw, in the test data the first event is smaller so the jumps should be less. But whether you're getting a 10px jump or a 5px jump doesn't matter and is not really visible.

Bug 101139 may help a bit because it changes the acceleration curve. But that too only gets rid of the jumps, not of the sawtooth pattern, I'm not sure what to do about those.

Andrew, can you please have a look at the data from comment 8? we're seeing a distinct sawtooth pattern in the data, see comment 16 for the deltas per event. Rather than diagonal it goes e.g. 5 events up, then 5 events right. I have no idea how to filter that out, it goes across multiple events with difficult patterns. Does it look/sound familiar?

Setting the synaptics driver acceleration to 0 yields the exact same results as libinput, the sawtooth pattern. The default acceleration of 2 yields usable results.

Created attachment 139439 [details]
email garbage

Andrew - this was a empty comment with an empty html attachment, I doubt that was intended? :)

Hmm, I was out of the office when comment 26 was sent. My out of office reply to the notification for comment 25 might have triggered that I guess.

I don't have anything useful to add regarding this bug at this time.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/libinput/libinput/issues/18.