| Summary: | Clickpad drag lock sometimes activates | ||
|---|---|---|---|
| Product: | Wayland | Reporter: | Jonathan Heathcote <mail> |
| Component: | libinput | Assignee: | Wayland bug list <wayland-bugs> |
| Status: | RESOLVED NOTABUG | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | CC: | mail, peter.hutterer |
| Version: | unspecified | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | evemu recording of touchpad click lock activating when it shouldn't. All of the clicks made in this recording were brief but the last one in the recording "locks" eroneously. | ||
The problem is this sequence: E: 1.849800 0001 0110 0001 # EV_KEY / BTN_LEFT 1 E: 1.849800 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +695ms read: clickpad is physically down E: 1.866110 0003 0039 7325 # EV_ABS / ABS_MT_TRACKING_ID 7325 E: 1.866110 0003 0035 1672 # EV_ABS / ABS_MT_POSITION_X 1672 E: 1.866110 0003 0036 2028 # EV_ABS / ABS_MT_POSITION_Y 2028 E: 1.866110 0003 003a 0040 # EV_ABS / ABS_MT_PRESSURE 40 E: 1.866110 0003 0030 0000 # EV_ABS / ABS_MT_TOUCH_MAJOR 0 E: 1.866110 0003 0031 0000 # EV_ABS / ABS_MT_TOUCH_MINOR 0 E: 1.866110 0001 014a 0001 # EV_KEY / BTN_TOUCH 1 E: 1.866110 0001 0145 0001 # EV_KEY / BTN_TOOL_FINGER 1 E: 1.866110 0003 0000 1672 # EV_ABS / ABS_X 1672 E: 1.866110 0003 0001 2028 # EV_ABS / ABS_Y 2028 E: 1.866110 0003 0018 0040 # EV_ABS / ABS_PRESSURE 40 E: 1.866110 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +17ms E: 1.878489 0003 003a 0045 # EV_ABS / ABS_MT_PRESSURE 45 E: 1.878489 0003 0018 0045 # EV_ABS / ABS_PRESSURE 45 E: 1.878489 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +12ms read: a finger is down in position x/y with pressure E: 1.950450 0003 0039 -001 # EV_ABS / ABS_MT_TRACKING_ID -1 E: 1.950450 0001 014a 0000 # EV_KEY / BTN_TOUCH 0 E: 1.950450 0001 0145 0000 # EV_KEY / BTN_TOOL_FINGER 0 E: 1.950450 0003 0018 0000 # EV_ABS / ABS_PRESSURE 0 E: 1.950450 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +72ms read: finger is up again, no finger is on the touchpad. E: 3.679061 0003 0039 7326 # EV_ABS / ABS_MT_TRACKING_ID 7326 E: 3.679061 0003 0035 1925 # EV_ABS / ABS_MT_POSITION_X 1925 E: 3.679061 0003 0036 1593 # EV_ABS / ABS_MT_POSITION_Y 1593 E: 3.679061 0003 003a 0048 # EV_ABS / ABS_MT_PRESSURE 48 E: 3.679061 0001 014a 0001 # EV_KEY / BTN_TOUCH 1 E: 3.679061 0001 0145 0001 # EV_KEY / BTN_TOOL_FINGER 1 E: 3.679061 0003 0000 1925 # EV_ABS / ABS_X 1925 E: 3.679061 0003 0001 1593 # EV_ABS / ABS_Y 1593 E: 3.679061 0003 0018 0048 # EV_ABS / ABS_PRESSURE 48 E: 3.679061 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +1729ms read: a finger is down again, 1.7 seconds later So the touchpad device detects a physical click before a finger is down and keeps that click down even though no finger is down on the touchpad. This is a hw problem, i think your clickpad is simply wearing out. You could probably test this by clicking the touchpad with a pen (something that doesn't get detected by the touchpad) and see if that triggers the BTN_LEFT up event. This isn't easy to detect, on most clickpads it is possible to trigger a click without a finger being registered (especially on the bottom edge where it's common to click). so we have code to accommodate for that situation, see commit bfe05ed4a679ae2a5e3ff3b6882cbb3d046baec2. There's an argument that we *could* release the button when the last finger is released, but we haven't seen this case in 4 years and I'm quite loathe to add a hack for something that looks like failing hardware. > read: clickpad is physically down > read: a finger is down in position x/y with pressure > read: finger is up again, no finger is on the touchpad. > read: a finger is down again, 1.7 seconds later Am I correct in understanding that the clickpad is failing to report that the clickpad is released on occasion? Or is there a race between the clickpad event and touch event and in my hardware, the click is occasionally arriving before the touch? If the former, what an odd hardware issue... If the latter, should this not be handled since the relative timings of click/touch events may not be guaranteed? > This is a hw problem, i think your clickpad is simply wearing out. You could > probably test this by clicking the touchpad with a pen (something that doesn't > get detected by the touchpad) and see if that triggers the BTN_LEFT up event. Here's the result of pressing and releasing the button with a pen: E: 0.000001 0001 0110 0001 # EV_KEY / BTN_LEFT 1 E: 0.000001 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +0ms E: 0.095194 0001 0110 0000 # EV_KEY / BTN_LEFT 0 E: 0.095194 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +95ms After trying quite a number of times, I've not seen either event go missing yet. Is this correct behaviour? (Thanks again for your help!) BTN_LEFT on a clickpad is the physical switch underneath. If you don't get the BTN_LEFT event (like in the sequence I pointed out) then the hw is still considering itself down. Especially on the T440 it's hard to hold the touchpad down without a finger down, given how it's designed (though there are narrow dead areas on the edges).
> the click is occasionally arriving before the touch?
yeah, but that doesn't matter to us. In your case the problem is that the BTN_LEFT value 0 does not arrive at all when the finger is released, see the 1.950450 event.
regarding the pen, let me re-explain: when the button is logically stuck and you are not touching the touchpad, that's when I need you to click again with the pen and check whether this triggers a sole BTN_LEFT 0 event. Because if so, then it's the switch. If not, then we have some other issues with the firmware most likely.
> yeah, but that doesn't matter to us. In your case the problem is that the
> BTN_LEFT value 0 does not arrive at all when the finger is released, see the
> 1.950450 event.
>
> regarding the pen, let me re-explain: [...]
Ah, thanks for explaining, I'd misunderstood!
Frustratingly, ever since you suggested your experiment my clickpad has stopped exhibiting this problem and so despite regular attempts I've been unable to carry out the experiment. That said, this rather supports the claim of this being a hardware related issue.
I shall keep an eye and next time the problem manifests I'll see what happens. Since this is likely a hardware problem this issue should probably be closed. If I find any evidence to the contrary (now I know what I'm looking for!) I'll re-open this bug.
Thanks again, Peter, for the swift and extremely helpful responses, they were much appreciated! It might be the excuse I've been looking for to replace my t440s' trackpad with a t450s one with real buttons...
|
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.
Created attachment 138501 [details] evemu recording of touchpad click lock activating when it shouldn't. All of the clicks made in this recording were brief but the last one in the recording "locks" eroneously. When clicking the clickpad on my Thinkpad T440s, some of the time the mouse button is not released even though the clickpad has been released. The click is not terminated until the next clickpad press. This doesn't appear to happen if I keep my finger resting on the pad after clicking but will happen about 10-20% of the time when I simultaneously remove my finger from the pad as I release the clickpad. There doesn't seem to be any other pattern in when or where on the clickpad this problem occurs. It can happen when pressing the virtual left, middle or right buttons or when performing a left-click by pressing the clickpad somewhere else. In the attached evemu recording I am repeatedly clicking the clickpad (pressing then immediately simultaneously releasing and removing my finger). In the recording, the last click seems to get locked and held down and I have to press the clickpad again to release it. The device is a clickpad *without* dedicated mouse buttons for the associated TrackPoint device. I'm using the buttonareas click method. I have attempted to disable every drag-lock related feature possible in my xorg configuration: Section "InputClass" Identifier "libinput touchpad catchall" MatchIsTouchpad "on" MatchDevicePath "/dev/input/event*" Option "ClickMethod" "buttonareas" Option "ScrollMethod" "edge" Option "NaturalScrolling" "false" Option "Tapping" "false" Option "TappingDrag" "false" Option "TappingDragLock" "false" Option "DragLockButtons" "" Driver "libinput" EndSection Section "InputClass" Identifier "libinput trackpoint catchall" MatchIsPointer "on" MatchDevicePath "/dev/input/event*" Option "ScrollMethod" "none" Option "Tapping" "false" Option "TappingDrag" "false" Option "TappingDragLock" "false" Option "DragLockButtons" "" Driver "libinput" EndSection Output of udevadm info: P: /devices/rmi4-00/input/input20/event18 N: input/event18 E: DEVNAME=/dev/input/event18 E: DEVPATH=/devices/rmi4-00/input/input20/event18 E: ID_BUS=rmi E: ID_INPUT=1 E: ID_INPUT_HEIGHT_MM=68 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=82 E: SUBSYSTEM=input E: USEC_INITIALIZED=4502037 Contents of /sys/class/dmi/id/modalias: dmi:bvnLENOVO:bvrGJET72WW(2.22):bd02/21/2014:svnLENOVO:pn20AQCTO1WW:pvrThinkPadT440s:rvnLENOVO:rn20AQCTO1WW:rvr0B98405STD:cvnLENOVO:ct10:cvrNotAvailable: Hardware: Lenovo Thinkpad T440s, Synaptics TM2937-001 libinput version: 1.10.3-1 (as packaged by Arch linux) xf86-input-libinput version 0.27.0-2 (as packaged by Arch linux) Thanks for any help or suggestions for trying to narrow down when/why this bug occurs; as you can imagine having a random subset of your mouse clicks not release can be frustrating!