Bug 103809

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.

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.

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.

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.

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)

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'?

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.

I think I can see those right clicks with --enable-tap only, without the clickfinger thing... sorry about that.

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.

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.

Created attachment 135667 [details]
udevadm info /sys/class/input/event1

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.

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.

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.

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.

-- 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.