Created attachment 138412 [details] evemu recording, that should contain 2-3 jumps my cursor is jumping every once in a while. i've tried following the guidelines to gather as much info as i can about the issue. i'm using latest Debian Buster/Sid, libinput 1.10.3, on a Dell XPS 9370 xinput list-props "DELL07E6:00 06CB:76AF Touchpad": Device 'DELL07E6:00 06CB:76AF Touchpad': Device Enabled (139): 1 Coordinate Transformation Matrix (141): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000 libinput Tapping Enabled (280): 0 libinput Tapping Enabled Default (281): 0 libinput Tapping Drag Enabled (282): 1 libinput Tapping Drag Enabled Default (283): 1 libinput Tapping Drag Lock Enabled (284): 0 libinput Tapping Drag Lock Enabled Default (285): 0 libinput Tapping Button Mapping Enabled (286): 1, 0 libinput Tapping Button Mapping Default (287): 1, 0 libinput Natural Scrolling Enabled (288): 0 libinput Natural Scrolling Enabled Default (289): 0 libinput Disable While Typing Enabled (290): 1 libinput Disable While Typing Enabled Default (291): 1 libinput Scroll Methods Available (292): 1, 1, 0 libinput Scroll Method Enabled (293): 1, 0, 0 libinput Scroll Method Enabled Default (294): 1, 0, 0 libinput Click Methods Available (295): 1, 1 libinput Click Method Enabled (296): 1, 0 libinput Click Method Enabled Default (297): 1, 0 libinput Middle Emulation Enabled (298): 0 libinput Middle Emulation Enabled Default (299): 0 libinput Accel Speed (300): 0.000000 libinput Accel Speed Default (301): 0.000000 libinput Left Handed Enabled (302): 0 libinput Left Handed Enabled Default (303): 0 libinput Send Events Modes Available (261): 1, 1 libinput Send Events Mode Enabled (262): 0, 0 libinput Send Events Mode Enabled Default (263): 0, 0 Device Node (264): "/dev/input/event20" Device Product ID (265): 1739, 30383 libinput Drag Lock Buttons (304): <no items> libinput Horizontal Scroll Enabled (305): 1 udevadm info /sys/class/input/event20 : P: /devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-8/i2c-DELL07E6:00/0018:06CB:76AF.0002/input/input26/event20 N: input/event20 S: input/by-path/pci-0000:00:15.1-platform-i2c_designware.1-event-mouse E: DEVLINKS=/dev/input/by-path/pci-0000:00:15.1-platform-i2c_designware.1-event-mouse E: DEVNAME=/dev/input/event20 E: DEVPATH=/devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-8/i2c-DELL07E6:00/0018:06CB:76AF.0002/input/input26/event20 E: ID_INPUT=1 E: ID_INPUT_HEIGHT_MM=56 E: ID_INPUT_TOUCHPAD=1 E: ID_INPUT_WIDTH_MM=101 E: ID_PATH=pci-0000:00:15.1-platform-i2c_designware.1 E: ID_PATH_TAG=pci-0000_00_15_1-platform-i2c_designware_1 E: ID_SERIAL=noserial E: LIBINPUT_DEVICE_GROUP=18/6cb/76af:i2c-DELL07E6:00 E: LIBINPUT_MODEL_TOUCHPAD_VISIBLE_MARKER=1 E: MAJOR=13 E: MINOR=84 E: SUBSYSTEM=input E: USEC_INITIALIZED=4691620 cat /sys/class/dmi/id/modalias : dmi:bvnDellInc.:bvr1.2.1:bd02/21/2018:svnDellInc.:pnXPS139370:pvr:rvnDellInc.:rn0F6P3V:rvrA00:cvnDellInc.:ct9:cvr:
the physical dimensions are: 105 mm width x 60 mm height the whole surface is clickable, but it's easier to press the lower part of the path where it also intepres left,middle,right click depending on whether your finger is.
Created attachment 138413 [details] xorg log, with the jump notifications
Looks like we need to fix the edges up, the touchpad size is out by a few mm. Please run the touchpad-edge-detector tool and attach the output here. Otherwise, probably not much we can do here in libinput, it's the kernel that gives us those jumps and while we can paper over some, it's questionable whether we can reliably detect all of them. CC-ing benjamin in any case, please also attach a dmesg and one or more *short* evemu recording that contains a jump. Sifting through 24k events is a bit time-consuming otherwise. evemu has a --autorestart option that can be used here to keep the logs at small sizes.
~ $ touchpad-edge-detector 105x60 /dev/input/event20 Touchpad DELL07E6:00 06CB:76AF Touchpad on /dev/input/event20 Move one finger around the touchpad to detect the actual edges Kernel says: x [0..1216], y [0..680] Touchpad sends: x [0..1216], y [0..680] |\-- Touchpad sends: x [0..1216], y [0..680] -^C Touchpad size as listed by the kernel: 101x56mm User-specified touchpad size: 105x60mm Calculated ranges: 1216/680 Suggested udev rule: # <Laptop model description goes here> evdev:name:DELL07E6:00 06CB:76AF Touchpad:dmi:bvnDellInc.:bvr1.2.1:bd02/21/2018:svnDellInc.:pnXPS139370:pvr:rvnDellInc.:rn0F6P3V:rvrA00:cvnDellInc.:ct9:cvr:* EVDEV_ABS_00=0:1216:12 EVDEV_ABS_01=0:680:11 EVDEV_ABS_35=0:1216:12 EVDEV_ABS_36=0:680:11
Created attachment 138563 [details] dmesg output after complete boot
Created attachment 138564 [details] this record should show a jump, as the cursor jump right after it was started
Created attachment 138565 [details] record should show 2-3 jumps
Thank you. I ran this through https://github.com/whot/input-data-analysis/tree/master/per-slot-deltas in attachment 138563 [details] 0.000001: ++++++ | *********** | 0.001787: →↗ 10/ -9 | *********** | 0.008625: ↖↑ -56/-140 | *********** | 0.015743: ↖← -20/ -8 | *********** | 140 (i.e. ~12mm) would be the jump here but because it's less than the 20mm we currently have as threshold it doesn't get discarded. in attachment 138565 [details] 14.897535: ↖← -15/ -2 | *********** | 14.905275: ↙← -473/ 53 | *********** | 14.912425: ↙← -65/ 37 | *********** | 14.919523: ↙← -27/ 21 | *********** | This one should've been discarded 26.199970: ++++++ | *********** | 26.201786: ↖↑ -5/ -18 | *********** | 26.207100: ↑↗ 25/-505 | *********** | 26.214147: ↑↗ 4/ -7 | *********** | 26.221237: ↑↗ 2/ -4 | *********** | 26.227837: ------ | *********** | should've been discarded 41.927455: ↖↑ -59/-252 | *********** | just over the 20mm, should be discarded 52.812556: ↙↓ -16/ 70 | *********** | ~6mm jump, got through 56.271947: ↑↗ 210/-272 | *********** | over 20mm, discarded These are the ones I spotted by glancing over the output. so yeah, there are definitely jumps in there that get through. We should look into reducing the threshold for jumps and be generally smarter about it but right now it's a matter of finding the time for it. One option we have is to look closer at the timestamps. Right now we only look at events but not the timestamps. This is *mostly* the same but we might edge out a bit better behaviour. a 10mm movement within 8-12ms is unrealistic in normal interaction. But yeah, ETIME...
-- 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/xorg/driver/xf86-input-libinput/issues/11.
Please see the last comment I left in the gitlab issue, please file one for libinput and give that branch a try, should make things better. Thanks.
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.