Created attachment 138234 [details] Evemu recording of fine movement with jumps As discussed here: https://bugs.freedesktop.org/show_bug.cgi?id=105022 slow fine cursor movement on my trackpad causes frustrating cursor jumps. udev info: P: /devices/rmi4-00/input/input21/event19 N: input/event19 E: DEVNAME=/dev/input/event19 E: DEVPATH=/devices/rmi4-00/input/input21/event19 E: ID_BUS=rmi E: ID_INPUT=1 E: ID_INPUT_HEIGHT_MM=66 E: ID_INPUT_TOUCHPAD=1 E: ID_INPUT_TOUCHPAD_INTEGRATION=internal E: ID_INPUT_WIDTH_MM=97 E: ID_SERIAL=noserial E: LIBINPUT_DEVICE_GROUP=1d/6cb/0:rmi4-00 E: MAJOR=13 E: MINOR=83 E: SUBSYSTEM=input E: USEC_INITIALIZED=2578784 modalias: dmi:bvnLENOVO:bvrGLET80WW(2.34):bd07/23/2015:svnLENOVO:pn20AN006NUS:pvrThinkPadT440p:rvnLENOVO:rn20AN006NUS:rvr0B98401WIN:cvnLENOVO:ct10:cvrNotAvailable:
Created attachment 138235 [details] [review] 0001-udev-add-the-T440p-to-the-T450-jumping-motion-quirks.patch Please give this one a test, thanks
Ok, just want to check that what I did was correct here. Rather than rebuilding and reinstalling (I'm currently running libinput 1.10.3 from the Arch Repo) I just manually applied the patch to /usr/lib/udev/hwdb.d/90-libinput-model-quirks.hwdb, and then rebooted to be sure. Let me know if that's wrong. Anyway, I don't notice any significant improvement. It's possible that the jumps have been very slightly reduced but it's hard to be sure, and the cursor definitely still jumps on fine movement - attempting to do precisely selection in GIMP etc is still a challenge.
https://wayland.freedesktop.org/libinput/doc/latest/udev_config.html#hwdb has the list of things you need to be careful of, particularly running udevadm hwdb --update and checking the property is set for the device.
Ok, so I followed all the instructions there (sorry, that was totally findable, should have known there would be good docs on how to do that!). Here's the output of udevadm info for the device: P: /devices/rmi4-00/input/input16/event14 N: input/event14 E: DEVNAME=/dev/input/event14 E: DEVPATH=/devices/rmi4-00/input/input16/event14 E: ID_BUS=rmi E: ID_INPUT=1 E: ID_INPUT_HEIGHT_MM=66 E: ID_INPUT_TOUCHPAD=1 E: ID_INPUT_TOUCHPAD_INTEGRATION=internal E: ID_INPUT_WIDTH_MM=97 E: ID_SERIAL=noserial E: LIBINPUT_DEVICE_GROUP=1d/6cb/0:rmi4-00 E: LIBINPUT_MODEL_LENOVO_T450_TOUCHPAD=1 E: MAJOR=13 E: MINOR=78 E: SUBSYSTEM=input E: USEC_INITIALIZED=2582729 So it looks like that property has been picked up successfully, but sadly I'm still getting the jumps. Is there anything else I can send/record to give you more insight?
I'm assuming you restarted your session after the hwdb updates so libinput can pick it up? In that case - there's no ready answer to your cursor jumps, sorry. One or two more recordings won't hurt, just to get some more ideas on what affects it here but this needs to be analysed and likely some patch written for this device only.
Created attachment 138269 [details] New evemu recording Yes, I've restarted since updating hwdb, to no avail :-( I'm attaching another evemu recording now that I'm running with the T450 quirks patch in case it provides any further enlightenment...
Did you notice any changes in the behaviour with the patch applied? Looking at this latest recording, there are two categories of jumps: 6.735493: | *********** | *********** | *********** | *********** | 6.745580: | *********** | *********** | *********** | *********** | 6.796415: | *********** | *********** | *********** | *********** | 6.826930: | *********** | *********** | *********** | *********** | 6.897885: | *********** | *********** | *********** | *********** | 6.907994: | *********** | *********** | *********** | *********** | 6.928296: →↘ 20/ 3 | *********** | *********** | *********** | *********** | 6.938448: ↙↓ -1/ 3 | *********** | *********** | *********** | *********** | 6.948594: ↓↘ 1/ 3 | *********** | *********** | *********** | *********** | i.e. lots of nothings, then a jump, then normal motion. This type of jump should be fixed with the bug. 5.101908: | *********** | *********** | *********** | *********** | 5.152933: | *********** | *********** | *********** | *********** | 5.162819: | *********** | *********** | *********** | *********** | 5.213504: →↘ 20/ 3 | *********** | *********** | *********** | *********** | 5.233803: →↗ 20/ -1 | *********** | *********** | *********** | *********** | 5.243927: →↘ 20/ 1 | *********** | *********** | *********** | *********** | 5.264403: →↘ 1/ 1 | *********** | *********** | *********** | *********** | i.e. lots of nothings, then *multiple* jumps, in this case three. There's another one with three jumps of 17 as well but the recording in the other bug had 2 and 4 events as well. Problem is: these don't look anything special, we cannot easily detect those because they're indistinguishable from a real move. So yeah, I don't really know what to do here.
fwiw, I pushed the quirk out for now because I do think it helps, even if it doesn't remove the issue. commit 238ffd322728ed386bf59c79f5f7016fe4349944 Author: Peter Hutterer <> Date: Mon Mar 19 15:39:22 2018 +1000 udev: add the T440p to the T450 jumping motion quirks
It's certainly possible that the patch helped somewhat; it's just really hard to distinguish subjectively between the level of "jumpiness" between restarts. All I can say is that as things stand it is still challenging to do finer work with the trackpad. Maybe there's a problem with what I've done, however. You say that one of the categories of jump in the latest recording ought to be fixed by the patch; but the recording was made *after* I applied the hwdb changes, so this jump shouldn't be showing up at all now.... but as you can see from the udevadm info output, that variable does appear to be set, so I'm confused. Have I misunderstood here or is there some other way to check that the updated behaviour really is being used?
By the way, FWIW, I get lots of these in my logs: (EE) event19 - Synaptics tm2964-001: kernel bug: Touch jump detected and discarded. Not sure if this is connected - they don't necessarily occur at the same time as I try to do fine movement.
Hello. Same problem on my Lenovo t440. Slowly motions cause cursor jumpy. On Xorg with synaptics touchpad work perfectly. I tried patch from first comment , the problem was slightly resolved, but it remained. System: Fedora 27 DE: Gnome3 Kernel: 4.15.10-300.fc27.x86_64 Libinput: 1.10.2 Udev info: P: /devices/platform/i8042/serio1/input/input11/event17 N: input/event17 E: DEVNAME=/dev/input/event17 E: DEVPATH=/devices/platform/i8042/serio1/input/input11/event17 E: EVDEV_ABS_00=::41 E: EVDEV_ABS_01=::37 E: EVDEV_ABS_35=::41 E: EVDEV_ABS_36=::37 E: ID_BUS=i8042 E: ID_INPUT=1 E: ID_INPUT_HEIGHT_MM=75 E: ID_INPUT_TOUCHPAD=1 E: ID_INPUT_TOUCHPAD_INTEGRATION=internal E: ID_INPUT_WIDTH_MM=99 E: LIBINPUT_DEVICE_GROUP=11/2/7:isa0060/serio1 E: LIBINPUT_MODEL_LENOVO_T450_TOUCHPAD=1 E: LIBINPUT_MODEL_SYNAPTICS_SERIAL_TOUCHPAD=1 E: MAJOR=13 E: MINOR=81 E: SUBSYSTEM=input E: USEC_INITIALIZED=6418050
> (EE) event19 - Synaptics tm2964-001: kernel bug: Touch jump detected and discarded. Right, so this means even without the patch, libinput discards some jumping motion. > On Xorg with synaptics touchpad work perfectly. tbh, I don't quite know how this could be, iirc synaptics doesn't do any pointer jump mitigation and these events are just forwarded as-is. Only possibility here is that the acceleration ramp-up is higher and thus these get filtered out in the acceleration code somewhere.
Can you please verify that when you're using synaptics and reproducing these jumps (i.e. moving very slowly) you can see those jumps, only they're a few pixels only rather than the ones seen by libinput?
You should try 1.11rc1, it has the new touchpad pointer accel with reduces the basic speed. This should make the issue more-or-less disappear.
-- 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/16.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.