Bug 103809 - Inconsistent behaviour in relation to thumb rejection
Summary: Inconsistent behaviour in relation to thumb rejection
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: 103210
Blocks:
  Show dependency treegraph
 
Reported: 2017-11-18 16:39 UTC by Peter Y. Chuang
Modified: 2018-06-05 09:59 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
evemu-record of one-finger tap when thumb rejection is triggered (176.28 KB, text/plain)
2017-11-18 16:39 UTC, Peter Y. Chuang
Details
evemu-record when thumb rejection is triggered (2) (173.57 KB, text/plain)
2017-11-18 16:45 UTC, Peter Y. Chuang
Details
evemu-record of one-finger tap when thumb rejection is triggered (v.2) (154.47 KB, text/plain)
2017-11-20 06:15 UTC, Peter Y. Chuang
Details
evemu-record of one-finger tap when thumb rejection is triggered (2, v.2) (122.32 KB, text/plain)
2017-11-20 06:24 UTC, Peter Y. Chuang
Details
evemu-record of one-finger tap when thumb rejection is triggered (2, v.3) (125.99 KB, text/plain)
2017-11-20 07:17 UTC, Peter Y. Chuang
Details
evemu-record of two-finger clickfinger when thumb rejection is triggered (207.27 KB, text/plain)
2017-11-20 07:43 UTC, Peter Y. Chuang
Details
udevadm info /sys/class/input/event1 (903 bytes, text/plain)
2017-11-22 16:58 UTC, Peter Y. Chuang
Details

Description Peter Y. Chuang 2017-11-18 16:39:35 UTC
Created attachment 135577 [details]
evemu-record of one-finger tap when thumb rejection is triggered

This is a follow-up to the discussion in bug103210 in relation to thumb detection.

When thumb detection is triggered with a light touch on the lower edge of the touchpad, one-finger tapping elsewhere on the touchpad is sometimes, but not always, registered as two-finger tapping, and two-finger tapping as three-finger tapping. This behaviour is similar to touch-size-based palm rejection in bug103210.

I've attached the evemu-record for the problem. Here are the steps to trigger the problem:

1. Put a finger on the lower edge of the touchpad
2. With the second finger, move the cursor a bit
3. Lift the second finger with the first finger remaining on the lower edge of the touchpad
4. Tap with the second finger

Note that this problem doesn't happen 100% of the time.
Comment 1 Peter Y. Chuang 2017-11-18 16:45:30 UTC
Created attachment 135578 [details]
evemu-record when thumb rejection is triggered (2)

It is also possible to trigger this problem just by tapping the touchpad repeatedly after placing one finger at the lower edge.
Comment 2 Peter Hutterer 2017-11-20 05:56:16 UTC
fwiw, in both attachments the problem isn't the tapping code. at the beginning a thumb is detected and the state returns to idle. all other touches aren't detected as thumbs. but neither recording triggers a right click here. I'll need some other recording to trigger the bug(s), sorry.
Comment 3 Peter Y. Chuang 2017-11-20 06:15:44 UTC
Created attachment 135595 [details]
evemu-record of one-finger tap when thumb rejection is triggered (v.2)

That sounds strange, because it did behave like right-click when I recorded it. I am giving it another go.
Comment 4 Peter Y. Chuang 2017-11-20 06:24:07 UTC
Created attachment 135596 [details]
evemu-record of one-finger tap when thumb rejection is triggered (2, v.2)

In here, I first put my thumb on the lower edge, then tap twice, the second of which behaves like a right-click. I'm not sure what the recording says here though.
Comment 5 Peter Hutterer 2017-11-20 06:47:43 UTC
run sudo evemu-play <filename> then hit enter to play the file. If you run libinput debug-events on the side you can verify whether it triggers. I can't trigger the right click with either of those either, so now I'm thinking that I'm missing a configuration option or something. Not sure which one though (running with --enable-tap --set-click-method=clickfinger)
Comment 6 Peter Y. Chuang 2017-11-20 07:08:16 UTC
Can you see the right clicks with libinput debug-events --enable-tap --set-click-method=clickfinger?

I guess it's because I've set org.gnome.desktop.peripherals.touchpad click-method to 'fingers'?
Comment 7 Peter Y. Chuang 2017-11-20 07:17:24 UTC
Created attachment 135597 [details]
evemu-record of one-finger tap when thumb rejection is triggered (2, v.3)

I can see the right clicks here with both --enable-tap and --set-click-method=clickfinger.
Comment 8 Peter Y. Chuang 2017-11-20 07:24:34 UTC
I think I can see those right clicks with --enable-tap only, without the clickfinger thing... sorry about that.
Comment 9 Peter Y. Chuang 2017-11-20 07:43:39 UTC
Created attachment 135598 [details]
evemu-record of two-finger clickfinger when thumb rejection is triggered

Speaking of clickfinger, I've just noticed that when thumb rejection is triggered, clicking with two fingers triggers middle click instead of right click. One-finger and three-finger clicks seem to behave correctly though (i.e. one-finger -> left click, three-finger -> middle click).

This one should be replayed with --set-click-method=clickfinger.
Comment 10 Peter Hutterer 2017-11-21 22:54:48 UTC
regarding comment #9, see commit 316f30d2f2 but let's handle this in a separate bug.

can you attach your udevadm info /sys/class/input/eventX output for the touchpad device please. attachment 135597 [details] doesn't trigger right clicks here so a difference in hwdb entries is the most likely cause.
Comment 11 Peter Y. Chuang 2017-11-22 16:58:33 UTC
Created attachment 135667 [details]
udevadm info /sys/class/input/event1
Comment 12 Peter Hutterer 2017-11-29 06:49:24 UTC
sorry for the delay. I adjusted my hwdb so my udevadm info look the same and I still can't reproduce it. sorry, I don't know what else is going on here. I'm getting middle events from the recordings but no right button clicks.

Without being able to reproduce it, chances of me fixing this are rather low. Best if you try to track this down yourself, sorry.
Comment 13 Peter Y. Chuang 2017-11-30 08:00:46 UTC
Thanks, I'll see what I can do.

And should I file (two) separate bugs for the clickfinger issues? On my machine, two-finger clicks are always recognised as three-finger clicks/middle clicks whenever touch-size-based palm rejection or thumb rejection is active. One-finger and three-finger clickfingers appear to behave correctly.
Comment 14 Peter Y. Chuang 2017-12-19 11:58:29 UTC
I am still not sure why the recordings don't show right click in non-MacBook, but I have just discovered a few other things.

As I understand it, each tap should produce a sequence in libinput debug-events as below:

event1   POINTER_BUTTON   +456.44s	BTN_LEFT (272) pressed, seat count: 1
event1   POINTER_BUTTON   +456.52s	BTN_LEFT (272) released, seat count: 0

On some occasions, however, with my thumb on, the first tap appears as "pressed", and the second tap appears as "released". When that happens, very quick successive taps are recognised as right clicks.

There are also occasions when tapping just flat out doesn't work at all. Instead, it just moves the cursor a bit.

Replaying those recordings remains problematic though. In fact, I can't even replay some of the problems correctly on the same MacBook.
Comment 15 Peter Hutterer 2018-01-08 05:49:00 UTC
correct, a tap (when detected) should provide a left button press + release a bit later. there are a few timeouts involved, but it should still be obvious.

The first issue sounds like there's a finger miscount happening? libinput debug-events --verbose can be a bit more useful here since it prints the tap state machine.

The second issue could be a movement being detected during/after the tap? Again, --verbose should show that, the tap states are reasonably well named so it's human-debuggable :) Also, there's a giant SVG in doc/ to follow the state machine.
Comment 16 GitLab Migration User 2018-06-05 09:59:23 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/10.


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.