Created attachment 135584 [details]
screen recording of the pointer moving

try git master, it removed the hysteresis which should make small movements more reliable

I'm using libinput 1.9.1 now.  It has improved a bit which I could confirm using libinput-debug-events.

 event5   POINTER_MOTION   +95.31s	  0.13/  0.00
 event5   POINTER_MOTION   +95.96s	  0.12/  0.00
 event5   POINTER_MOTION   +96.39s	  0.11/  0.00
 event5   POINTER_MOTION   +96.52s	  0.11/  0.00
 event5   POINTER_MOTION   +96.80s	  0.11/  0.00
 event5   POINTER_MOTION   +96.97s	  0.11/  0.00
 event5   POINTER_MOTION   +96.98s	  0.11/  0.00
 event5   POINTER_MOTION   +97.51s	  0.11/  0.00
 event5   POINTER_MOTION   +97.89s	  0.11/  0.00
 event5   POINTER_MOTION   +97.90s	  0.11/  0.00
 event5   POINTER_MOTION   +97.97s	  1.94/  0.00
 event5   POINTER_MOTION   +98.13s	  0.00/  0.10
 event5   POINTER_MOTION   +98.27s	  0.00/  0.10
 event5   POINTER_MOTION   +98.69s	 -1.96/  0.00
 event5   POINTER_MOTION   +98.71s	  6.24/  5.69

this is how it looks now when doing very precise movements. Beforehand the 0.11 would be 0.00 meaning the pointer wouldn't move at all until 6.24 / 5.69.
So the small movements by 0.11 is a big improvement already.

Sadly every 20 events or so a big jump like 6.24 / 5.69 still occurs. Which is still kind of annoying to deal with. 

Maybe this has something to do with mouse acceleration?

1.9.1 still has the hysteresis enabled, you'll need to try git master for that bit.

I git cloned https://github.com/wayland-project/libinput cded into libinput (powerline showed me that i'm in master branch) and used meson and ninja to build and updated.

libinput --version still says 1.9.1 though so I'm not sure if I'm doing this correctly.

good point, I forgot to bump the version on the master branch. Fixed now with  6a8d5a6e0, thanks.

Okay I'm using 1.9.900 now

Touchpad still behaving erratic

 event5   POINTER_MOTION   +30.11s	  0.13/  0.00
 event5   POINTER_MOTION   +30.12s	  0.12/  0.00
 event5   POINTER_MOTION   +30.22s	  0.12/  0.00
 event5   POINTER_MOTION   +30.23s	  0.12/  0.00
 event5   POINTER_MOTION   +30.24s	  0.12/  0.00
 event5   POINTER_MOTION   +30.25s	  0.13/  0.00
 event5   POINTER_MOTION   +30.26s	  0.13/  0.00
 event5   POINTER_MOTION   +30.27s	  0.13/  0.00
 event5   POINTER_MOTION   +30.40s	  2.82/  0.00
 event5   POINTER_MOTION   +30.41s	 -5.07/  0.00
 event5   POINTER_MOTION   +30.42s	  5.55/  0.00
 event5   POINTER_MOTION   +30.50s	 -5.35/  0.00
 event5   POINTER_MOTION   +30.54s	  1.73/  0.00

I moved the pointer very slowly from left to right. It works normally for a few pixels then suddenly jumps forward / backward.

I found someone with a similar problem using a thinkpad x220 if that helps.
https://bugzilla.redhat.com/show_bug.cgi?id=1264453

the stair pattern should be gone with the hysteresis gone?

If one prints the per-slot deltas the problem is visible:

 0.148118:              |  *********** | 
 0.176980:              |  *********** | 
 0.207288:              |  *********** | 
 0.226218:              |  *********** | 
 0.236147:              |  *********** | 
 0.246356: ↑↗   31/ -43 |  *********** | 
 0.314911: →↘   31/   7 |  *********** | 
 0.325129: →↘   31/   4 |  *********** | 
 0.335191: →↘   31/   1 |  *********** | 
 0.364298: →↗   31/  -6 |  *********** | 
 0.374541: →↘   31/   4 |  *********** | 
 0.383795: →↘   31/   1 |  *********** | 
 0.393685: →↘    7/   1 |  *********** | 
 0.403613: →↘    5/   1 |  *********** | 
 0.413709: →↘    1/   1 |  *********** | 
 0.423796: ↓↘    1/   4 |  *********** | 
 0.432893: →↘    1/   1 |  *********** | 
 0.443063: →↘    1/   1 |  *********** | 

so no movement, then several movemnts with 31 units (42 units == 1mm), then smaller movements. This repeats often:

 2.167606: →↘    1/   1 |  *********** | 
 2.177573: →↘    1/   1 |  *********** | 
 2.187647: →↘    4/   1 |  *********** | 
 2.196651: ↓↘    1/  18 |  *********** | 
 2.206751: →↘   20/  18 |  *********** | 
 2.226926: ↓↘    1/  18 |  *********** | 
 2.236070: ↓↘    1/  18 |  *********** | 
 2.246686: ↓↘    1/  18 |  *********** | 
 2.255925: ↓↘    1/  18 |  *********** | 
 2.265937: ↓↘    1/  18 |  *********** | 
 2.275980: ↓↘    1/  18 |  *********** | 
 2.285035: ↑↗    1/  -7 |  *********** | 


That 20 in there would give you a jump. In other words, the data coming out of the device is bad and we need some code to detect and paper over these jumps. Not sure how to do this yet, suggestions appreciated

Tool used: https://github.com/whot/input-data-analysis/tree/master/per-slot-deltas

i have the same problem with ELAN touchpad, feels like it skips after every "n" movements and then jumps to catch-up to finger. The faster you move the finger, the more often it jumps

have it on both libinput 1.9.3 and 1.9.900

per-slot-delta output:

11.804130: ↑↗    1/  -1 |  *********** |
11.816446: ↑↗    1/  -1 |  *********** |
12.034435: →↗   13/  -1 |  *********** |
12.060522: ↑↗    1/  -1 |  *********** |
12.085206: ↑↗    1/  -1 |  *********** |
12.111328: →↗    2/  -1 |  *********** |
12.124130: ↑↗    1/  -1 |  *********** |
12.151906: ↑↗    1/  -1 |  *********** |
12.182069: ↑↗    1/  -1 |  *********** |
12.214404: →↗    2/  -1 |  *********** |
12.242133: ↑↗    1/  -1 |  *********** |
12.253445: ↑↗    1/  -1 |  *********** |
12.264750: ↑↗    1/  -1 |  *********** |
12.277063: ↑↗    1/  -1 |  *********** |
12.316001: ↑↗    1/  -1 |  *********** |
12.329307: ↑↗    1/  -1 |  *********** |
12.342120: ↑↗    1/  -1 |  *********** |
12.354944: ↑↗    1/  -1 |  *********** |
12.366272: →↗    2/  -1 |  *********** |
12.392937: ↑↗    1/  -1 |  *********** |
12.405262: ↑↗    1/  -1 |  *********** |
12.431897: ↑↗    1/  -1 |  *********** |
12.444723: ↑↗    1/  -1 |  *********** |
12.456041: ↑↗    1/  -1 |  *********** |
12.482623: ↑↗    1/  -1 |  *********** |
12.508823: ↑↗    1/  -1 |  *********** |
12.521657: ↑↗    1/  -1 |  *********** |
12.545798: ↑↗    1/  -1 |  *********** |
12.559627:              |  *********** |
12.584754: ↑↗    1/  -1 |  *********** |
12.598580: →↗    2/  -1 |  *********** |
12.624224: ↑↗    1/  -1 |  *********** |
12.635513: ↑↗    1/  -1 |  *********** |
12.649337: ↑↗    1/  -1 |  *********** |
12.674440: ↑↗    1/  -1 |  *********** |
12.688258: ↑↗    1/  -1 |  *********** |
12.854909:              |  *********** |
12.905671:              |  *********** |
12.918479: →↗   13/  -2 |  *********** |
12.931288: ↑↗    1/  -2 |  *********** |
12.944892: ↑↗    1/  -2 |  *********** |

Created attachment 136714 [details]
screen recording of the issue

fedora 27, no difference between wayland and xorg sessions

attaching a video of the issue ( libinput 1.9.900 )

judging by comment 9, the two 13/y would give a cursor jump. As with the other device, I don't know how to fix this. *maybe* some averaging but that would introduce delay into the finger movement - not ideal given how many people already complain about that.

it just feels almost like there are tiny "deadzones" spread out equally across the touchpad. Could it be some problem with resolution calculation?

fwiw, at least on the T450 generation laptops that's exactly what happens: https://who-t.blogspot.com.au/2016/09/libinput-and-lenovo-t450-and-t460.html

I'm wondering if bug 105303 has something to do with that, although that wouldn't trigger a delta of 13. Still, might be worth trying this script:

#!/bin/bash
  
fuzz=0
device=/dev/input/event4
sudo libevdev-tweak-device --abs ABS_X --fuzz $fuzz $device
sudo libevdev-tweak-device --abs ABS_Y --fuzz $fuzz $device
sudo libevdev-tweak-device --abs ABS_MT_POSITION_X --fuzz $fuzz $device
sudo libevdev-tweak-device --abs ABS_MT_POSITION_Y --fuzz $fuzz $device


Run that against the touchpad device (i.e. replace the device node accordingly) and restart X. This may cause some pointer wobble, the question is whether it reduces the jumps.

Needinfo for too long, closing