open a terminal please and run sudo libinput-debug-events. Do you see the event flow pause here too? I think this may be caused by the server being too busy rendering and thus not able to handle input events. This doesn't happen in synaptics because the mouse cursor update code all runs inside a signal handler.

You can doubly verify this by switching to a VT and running libinput-debug-events. If you see the pauses there then this is a hardware or libinput issue.

I can confirm my fresh F24 install on the T460s has the trackpad-pausing problem. I see no output from `sudo journalctl -f -l` that correlates with the pauses.

When I run `sudo libinput-debug-events` I see the event flow pauses in the data stream that correspond with the mouse pauses. When the mouse flows smoothly the data stream is output smoothly. When the mouse freezes for a moment, the data stream freezes for a moment.

I haven't confirmed it myself yet, but I've heard that a fresh Fedora 23 install on a T460s does not show the issue. If that is true then this must be a software issue introduced with F24.

I'm very interested to test out any fixes or contribute with information.

In addition to what Brian said above, I can confirm that running libinput-debug-events in a VT also shows pauses.  The pauses are typically in the 10th of a second range but do spike up to 1/2 to a full second.  Here is a capture of libinput-debug-events that shows a pause of .3 seconds (time +.79):

[liveuser@localhost ~]$ sudo libinput-debug-events
event2 	DEVICE_ADDED     Power Button                      seat0 default group1 cap:k
event7 	DEVICE_ADDED     Video Bus                         seat0 default group2 cap:k
event1 	DEVICE_ADDED     Sleep Button                      seat0 default group3 cap:k
event15	DEVICE_ADDED     Integrated Camera                 seat0 default group4 cap:k
event3 	DEVICE_ADDED     AT Translated Set 2 keyboard      seat0 default group5 cap:k
event4 	DEVICE_ADDED     SynPS/2 Synaptics TouchPad        seat0 default group6 cap:pg	size 98.00/53.16mm tap(dl off) left scroll-nat scroll-2fg-edge click-buttonareas-clickfinger dwt-on
event5 	DEVICE_ADDED     TPPS/2 IBM TrackPoint             seat0 default group7 cap:p left scroll-nat scroll-button
event6 	DEVICE_ADDED     ThinkPad Extra Buttons            seat0 default group8 cap:k
event4 	POINTER_MOTION    +0.69s	 -2.42/ -0.40
event4 	POINTER_MOTION    +0.70s	 -2.27/ -1.77
event4 	POINTER_MOTION    +0.71s	 -1.14/ -2.97
event4 	POINTER_MOTION    +0.72s	  0.44/ -4.02
event4 	POINTER_MOTION    +0.73s	  2.36/ -5.16
event4 	POINTER_MOTION    +0.74s	  4.59/ -6.57
event4 	POINTER_MOTION    +0.75s	  6.94/ -8.99
event4 	POINTER_MOTION    +0.76s	 11.72/-14.04
event4 	POINTER_MOTION    +0.77s	 16.48/-16.32
event5 	POINTER_MOTION    +0.79s	  0.00/  0.30
event4 	POINTER_MOTION    +1.09s	  4.11/  4.93
event4 	POINTER_MOTION    +1.09s	  3.23/  4.27
event4 	POINTER_MOTION    +1.10s	  2.96/  5.95
event4 	POINTER_MOTION    +1.12s	  2.46/  7.49
event4 	POINTER_MOTION    +1.13s	  1.96/  8.88
event4 	POINTER_MOTION    +1.14s	  0.61/  7.38
event4 	POINTER_MOTION    +1.15s	 -0.41/  5.40
event4 	POINTER_MOTION    +1.16s	 -0.40/  4.86
event4 	POINTER_MOTION    +1.17s	 -0.49/  4.05
event4 	POINTER_MOTION    +1.19s	 -0.38/  1.96
event4 	POINTER_MOTION    +1.20s	  0.88/ -1.20
event4 	POINTER_MOTION    +1.21s	  2.72/ -4.79
event4 	POINTER_MOTION    +1.22s	  6.07/-10.35

Smooth scrolling counts up in hundredths of a second.  Noticable pauses are tenths of a second.

I'm going to try to reproduce this issue on F23. If it does not reproduce then we'll know it's a software issue with F24.

Please attach the evemu-record for such a pausing sequence (ideally *only* the pausing sequence, not the events before/after, and definitely not a 20-min long recording :)

You can run evemu-record and libinput-debug-events at the same time without side-effects

Created attachment 1190258 [details]
evemu-record output

This file is the output from evemu-record on fedora 24 live running on a Lenovo T460s.  In the file, the cursor was fine until the section where you can see 1110ms (search for that to find the transition from good to bad).  To make this happen I opened up FireFox to bestbuy.com and searched for computer monitors and did a two finger scroll up and down on that page.

evemu shouldn't really be affected by any rendering since it sits below everything and unless the machine is close to exhaustion the recording should not show any delay.

I can see some jerky motion in the output with mtdiag but my own mtview debugging tool hangs for some reason. If it isn't jerky with synaptics then this would indicate either the single-touch emulation is more precise or that libinput's averaging of touch events is problematic here. Benjamin, if you have a few spare cycles please look at that, I ran out of time today.

If PS/2 is not working properly, it would be interesting to see if RMI4 over SMBus is behaving without those pauses.

I am currently trying to finish the series and hope to be able to send it today (if I can get around the last issue I see during suspend/resume). Once I got this reliable, I'll push a koji scratch-build for you to test and report if this fixes the issues you are seeing.

I would love to test a koji scratch build. I'll see the update if the link is posted here. Thank you all for helping with this!

Hmm, looks like I won't get my reworked series done today. I pushed my previous series in http://koji.fedoraproject.org/koji/taskinfo?taskID=15232074

Once installed, there should be some new drivers loaded rmi_core, rmi_smbus and rmi_ps2. If they do not appear, append to the kernel parameters psmouse.synaptics_intertouch=1.

If there is a new input device named like "Synaptics TM3053-004" (that's on the t450s), that means you are using RMI4 over SMBus.

FWIW, when I boot my T460s into Fedora 23 I immediately reproduce the same pausing mouse issue. I do not thing this was a regression created in Fedora 23.

@btissoir So I should install that kernel onto my F24 test system? Also where does one list the input devices?

That should have read, "I do not think this is a regression introduced in Fedora 24."

(In reply to Brian Bouterse from comment #12)
> @btissoir So I should install that kernel onto my F24 test system? Also
> where does one list the input devices?

Yes, please install on F24. If you install only the kernel related packages, it should be fine (kernel, kernel-core, kernel-modules, kernel-modules-extra and if you need kernel-devel and kernel-header).

For listing (and testing) the input devices, please use evemu-record (just run it as sudoer, without arguments).

I successfully installed the kernel and associated packages from koji.

[bmbouter@localhost ~]$ uname -r
4.8.0-0.rc1.git4.1.rmi4.1.fc26.x86_64

I did need to add the kernel option to load the new drivers: rmi_core, rmi_smbus and rmi_ps2. Without the kernel option I only got rmi_ps2. Here is my driver verification step.

[bmbouter@localhost ~]$ lsmod | grep rmi
rmi_smbus              16384  0
rmi_core               45056  1 rmi_smbus
rmi_ps2                16384  0

Also when loading the drivers I do see an entry similar to the one you displayed for the T450s. Apparently the T460s is a TM3145-003.

[bmbouter@localhost ~]$ xinput --list | grep Synaptics
⎜   ↳ Synaptics TM3145-003                    	id=13	[slave  pointer  (2)]

When booting the 4.8.0.0-rc1 kernel without the kernel parameter I did observe that I did not have this device. Also only the rmi_ps2 driver was loaded.

I can confirm that with these drivers loaded I still observe the jumpy mouse symptoms.

I then captured the evemu-record output in the running system for the correct device and I will upload that now.

Created attachment 1192327 [details]
evemu-record output from 4.8.0.0.rc1 kernel with device drivers loaded

try this one please:
http://koji.fedoraproject.org/koji/taskinfo?taskID=15345948

After installing you'll need to restart X, but no reboot required. This build uses only a single touch for two-finger scrolling and does away with the averaging. If the synaptics driver doesn't see jumps while scrolling, this one should not either. It won't have any effects on normal pointer motion.

Also, I'm not sure whether we're looking at several different issues here:

* attachment 1190258 [details] shows the 1110ms delay that's coming from the kernel. that delay would be seen by synaptics as well and would lead to the same jump
* synaptics in F24 uses sigio in the server, libinput doesn't. So when the server is busy rendering, pointer movement can be jumpy and that'll be fixed in the next server release. but that would only affect single-finger pointer movement anyway. two-finger scrolling would be similar between synaptics and libinput since it relies on rendering and if that's slow, things are slow and jumpy
* synaptics uses single-finger motion for two-finger scrolling, libinput averages the motion between the fingers. The scratch build above tests this, afaict from looking at the recording this should make libinput use the same coordinates as synaptics would otherwise use. but this does not explain the pointer jumps when moving.
* synaptics and libinput have different pointer acceleration. if the touchpad has insensitive zones (it does) then the acceleration differences may cause the jumpiness. but we already have special handling for the T450 and T460 series to avoid this, so...

so one more thing I'll need: run evemu-record and move your finger around the *whole* touchpad surface, multiple times. The idea here is to trigger every sensor position to figure out where the areas are that the touchpad does not detect. this file may end up being multiple megabytes, if bugzilla complains just zip it before attaching, thanks.

I installed the libinput build you linked to in koji.

[bmbouter@localhost ~]$ rpm -qa | grep libinput
libinput-1.4.1-1.bz1364850.fc24.x86_64

After installing I did reboot for good measure. After the reboot the problem still exists.

I would describe the issue as "stalling", not jumpiness. Also I'm only testing this with single-finger pointer movements. A 1110ms delay coming from the kernel sounds consistent with my experience.

Also note that I met another F24 user with a T460s who reports no issues. When they run `xinput --list | grep Synaptics` they get:

SynPS/2 Synaptics TouchPad

I think this means that the T460s have different types of trackpads depending on something I don't understand.

Created attachment 1193411 [details]
evemu-output whole trackpad with custom libinput package

I did 3 passes. I believe each pass touched all points on the trackpad. First was left to right (swiping up and down), second right to left (swiping up and down), third was top to bottom (swiping left and right).

Also when the most recent attachment was made since I rebooted and didn't enable the special drivers it only loaded rmi_ps2. Specifically I get this output:

[bmbouter@localhost ~]$ lsmod | grep rmi
rmi_ps2                16384  0

(In reply to Brian Bouterse from comment #19)
> I would describe the issue as "stalling", not jumpiness. Also I'm only
> testing this with single-finger pointer movements. A 1110ms delay coming
> from the kernel sounds consistent with my experience.

that's the thing, if the delay comes from the kernel (and thus shows up in the evemu record like in the attachment in comment 7) there's no way the synaptics driver would not see the delay too. synaptics and libinput both use the same input data, the one also recorded by evemu.

As I said above, single-finger motion does not change at all in the test build I submitted.

I guess an interesting experiment though would be to start X with the synaptics driver and then run sudo libinput-debug-events --device /dev/input/eventX (with your touchpad's event node). If you see the debug-events output stall but the visible synaptics pointer keeps moving, then we have a real heisenbug...

> Also note that I met another F24 user with a T460s who reports no issues.
> When they run `xinput --list | grep Synaptics` they get:
> 
> SynPS/2 Synaptics TouchPad
> 
> I think this means that the T460s have different types of trackpads
> depending on something I don't understand.'

switching to the RMI4 test kernel gives you a different touchpad name. It's the same touchpad but addressed by a different bus (legacy PS/2 vs the new RMI4 protocol)

I just noticed something on my T450 here: the udev property we use for this type of device isn't set. Is this the case with you guys too?

the output of "udevadm info /sys/class/input/event4" (with the touchpad event node of course) should show LIBINPUT_MODEL_LENOVO_T450_TOUCHPAD=1
it doesn't on my T450 for some reason but running
"sudo udevadm test /sys/class/input/event4" makes it show up. If this is the case for you, log out and log in again (don't reboot!) and check to see the differences. It won't remove the cursor stalls because they're in hw but it will remove the jumps.

Note: this will not work on the RMI4 test kernel Benjamin provided, only with the stock Fedora kernel.

I managed to get a hold of another T460s which had 256 GB hard drive and 12 G of ram. I loaded Fedora 24 on it and the trackpad performed beautifully. We also attempted to update the bios of the affected machine and it looked like it would not complete the update.

For both of these reasons I think this bug was actually a hardware issue and not a software issue.

I'm not sure if the original reporter is also experiencing a hardware issue or if there is a software issue.

Peter and Will thank you both so much for your time. For my purposes, feel free to close this bug.

Brian, can you attach the dmesg from the good and the bad machine please, thanks

Looks like this might be caused by having both the trackpoint and trackpad on at the same time on the Lenovo.  If you turn off the trackpoint with 

xinput set-prop "TPPS/2 IBM TrackPoint" "Device Enabled" 0

the problem seems to go away.  You lose both the trackpoint and the buttons but the cursor moves smoothly with both single finger motion and two finger scrolling.

I no longer have access to the machines I was testing with. I will get another one in the coming weeks which I could post dmesg output from.

libinput-1.4.901-2.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-199a8437c6

libinput-1.4.901-2.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-5944541819

fwiw, the 1.4.901-2 package fixes an issue where the trackpoint would send spurious events every once in a while. This triggered the palm detection on the touchpad and halted touchpad movements for 300ms. It won't fix the halting motion when moving really slowly that is described here:
http://who-t.blogspot.com.au/2016/09/libinput-and-lenovo-t450-and-t460.html

Looking at the output in comment #3 I'm now pretty sure this is the issue Mike faced originally. There is one event from event5 in there - the trackpoint. That event would stop the touchpad shortly, causing the observed pause.

For a Lenovo T460s, I can confirm that disabling the trackpoint and leaving the touchpad enabled in the bios does fix the random pauses for libinput 1.4.2-2.fc24.

Tested on the 1.15 Bios, kernel 4.7.2-201.fc24.x86_64

When I installed libinput 1.4.901-2 off koji I can confirm that the stuttered/pausing is fixed with both trackpoint and trackpad enabled in the T460s bios and trackpoint disabed and trackpad enabled.  The pointer still feels slightly inaccurate at very slow speeds (like rolling your finger slowly).  But overall I have no problems using this as a daily driver and dumping the synaptics and syndaemon config I cobbled together.

(In reply to Mike Echevarria from comment #31)
> When I installed libinput 1.4.901-2 off koji I can confirm that the
> stuttered/pausing is fixed with both trackpoint and trackpad enabled in the
> T460s bios and trackpoint disabed and trackpad enabled.  

You shouldn't need to disable the trackpoint anymore, that's the point of the fix :)


> The pointer still
> feels slightly inaccurate at very slow speeds (like rolling your finger
> slowly). 

yeah, this is the other bug (see the blog post above) that we haven't addressed yet

libinput-1.4.901-2.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-199a8437c6

libinput-1.4.901-2.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-5944541819

libinput-1.4.901-2.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.

libinput-1.4.901-2.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.

I have the same device and I experienced the same problem. I was able to stop this by disabling the Trackpoint.

FTR the bugfix from comments 35 and 36 was incomplete, bug 1572394 now has the new fixes.

*** Bug 1570405 has been marked as a duplicate of this bug. ***