Bug 106044 - Unreliable tap-to-click on a DELL XPS 9370 - exceeds motion threshold
Summary: Unreliable tap-to-click on a DELL XPS 9370 - exceeds motion threshold
Status: RESOLVED MOVED
Alias: None
Product: Wayland
Classification: Unclassified
Component: libinput (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Wayland bug list
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-04-14 14:23 UTC by Pierpaolo Valerio
Modified: 2018-06-05 10:00 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
evemu recording of a missed tap (57.81 KB, text/plain)
2018-04-14 14:23 UTC, Pierpaolo Valerio
Details
New evemu recording (single finger) (42.43 KB, text/plain)
2018-04-16 15:28 UTC, Pierpaolo Valerio
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Pierpaolo Valerio 2018-04-14 14:23:08 UTC
Created attachment 138836 [details]
evemu recording of a missed tap

I have a pretty new DELL XPS13 9370 laptop and using tap-to-click my touchpad is missing clicks every now and then (like, 1 every 5 or 6). It happens a lot more often with 2-finger or 3-finger tapping. I suspect this is due to the touchpad recognizing my finger moving during the tap, but it happens way too often to be normal (it NEVER happens on Windows with the same hardware and I think I use my touchpad in the same way regardless of the operating system). Attached is a evemu recording of a missed tap.
Other than this I'm happy to report that the touchpad works pretty well (scrolling, palm rejection, accuracy...).

Other info:
libinput version 1.10.4 on Manjaro linux

udev info:
P: /devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-1/i2c-DELL07E6:00/0018:06CB:76AF.0002/input/input19/event10
N: input/event10
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/event10
E: DEVPATH=/devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-1/i2c-DELL07E6:00/0018:06CB:76AF.0002/input/input19/event10
E: EVDEV_ABS_00=0:1216:12
E: EVDEV_ABS_01=0:680:11
E: EVDEV_ABS_35=0:1216:12
E: EVDEV_ABS_36=0:680:11
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=74
E: SUBSYSTEM=input
E: USEC_INITIALIZED=2620793

modalias:
dmi:bvnDellInc.:bvr1.2.0:bd01/25/2018:svnDellInc.:pnXPS139370:pvr:rvnDellInc.:rn0F6P3V:rvrA00:cvnDellInc.:ct9:cvr:

touchpad-edge-detector:
Touchpad size as listed by the kernel: 101x61mm
User-specified touchpad size: 105x60mm
Calculated ranges: 1216/680
Comment 1 Peter Hutterer 2018-04-16 08:08:53 UTC
The log parts that matter here, for the evemu record from comment 0:

event19 - tap: touch 0 state TAP_STATE_IDLE → TAP_EVENT_TOUCH → TAP_STATE_TOUCH
event19 - tap: touch 1 state TAP_STATE_TOUCH → TAP_EVENT_TOUCH → TAP_STATE_TOUCH_2
event19 - palm: touch 1: palm-tap detected
event19 - tap: touch 1 state TAP_STATE_TOUCH_2 → TAP_EVENT_MOTION → TAP_STATE_TOUCH_2_HOLD
event19 - tap: touch 1 state TAP_STATE_TOUCH_2_HOLD → TAP_EVENT_RELEASE → TAP_STATE_HOLD
event19 - tap: touch 0 state TAP_STATE_HOLD → TAP_EVENT_RELEASE → TAP_STATE_IDLE

So basically what this means:
- touch down
- second touch down
- second touch is detected as palm touch because it's at the far edge of the touchpad
- this puts the first touch into the "touch-and-hold" state

IOW, if a palm is detected during tapping, we don't continue with the tap because there's too much chance of interference. That's the reason that you don't get a one-finger tap with two fingers (one of which is a palm). And the reason you don't get a two-finger tap is because one touchpoint is in the palm detection area on the far side of the touchpad. This is an intentional behaviour, see:
http://wayland.freedesktop.org/libinput/doc/latest/palm_detection.html
Comment 2 Pierpaolo Valerio 2018-04-16 15:27:32 UTC
Thanks for the quick answer.
I don't think it's (only) a matter of palm rejection, unless my touchpad is detecting ghost touches. It might be that in the previous recording I had my hand close to the edge so it was triggered by it. I'm attaching a new evemu recording that I just did making sure that the rest of my hand was nowhere near the touchpad, which I touched only with one extended finger.
Comment 3 Pierpaolo Valerio 2018-04-16 15:28:26 UTC
Created attachment 138868 [details]
New evemu recording (single finger)
Comment 4 Peter Hutterer 2018-04-17 00:35:44 UTC
Problem in this one is the motion, yes. events that matter here:

E: 0.992120 0003 0036 0307      # EV_ABS / ABS_MT_POSITION_Y    307
E: 0.999293 0003 0036 0324      # EV_ABS / ABS_MT_POSITION_Y    324

This is a 17 unit movement, translating to a 1.4mm movement. Which is just above the 1.3mm threshold. So yeah, you're just triggering the motion threshold on the first event after touch down, converting the whole thing into pointer motion. That's the source of the issue, I guess there are some heuristics we can improve to make this less of an issue.

Note ahead: increasing the motion threshold makes the touchpad less responsive, so that's not ideal either.
Comment 5 GitLab Migration User 2018-06-05 10:00:13 UTC
-- 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/17.


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.