Bug 105850 - Clickpad drag lock sometimes activates
Summary: Clickpad drag lock sometimes activates
Status: RESOLVED NOTABUG
Alias: None
Product: Wayland
Classification: Unclassified
Component: libinput (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Wayland bug list
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-04-02 18:13 UTC by Jonathan Heathcote
Modified: 2018-04-04 13:10 UTC (History)
2 users (show)

See Also:
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. (16.99 KB, text/plain)
2018-04-02 18:13 UTC, Jonathan Heathcote
Details

Description Jonathan Heathcote 2018-04-02 18:13:03 UTC
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!
Comment 1 Peter Hutterer 2018-04-03 06:31:49 UTC
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.
Comment 2 Jonathan Heathcote 2018-04-03 06:49:02 UTC
> 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!)
Comment 3 Peter Hutterer 2018-04-03 07:59:14 UTC
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.
Comment 4 Jonathan Heathcote 2018-04-04 13:10:43 UTC
> 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.