Bug 105446

Can you reproduce this with libinput debug-events --enable-tap? Certainly works here for both master and 1.10.2

Hmm, sounds like right-click emulation is higher level because libinput doesn't see the difference...

Tested both libinput 1.10.1-1 (debian/ubuntu) and libinput master (d786b55):

Tap on bottom right area (shell incorrectly does a left click)
event15  POINTER_BUTTON   +74.96s	BTN_LEFT (272) pressed, seat count: 1
event15  POINTER_BUTTON   +75.06s	BTN_LEFT (272) released, seat count: 0

Click on bottom-right area (shell correctly does a right click)
event15  POINTER_BUTTON    +3.94s	BTN_LEFT (272) pressed, seat count: 1
event15  POINTER_BUTTON    +4.12s	BTN_LEFT (272) released, seat count: 0

Is the right click emulation done in mutter then?

Tapping and click method is handled in libinput. What device is this? maybe it's one of the ones where clickfinger is the default? libinput list-devices will tell you, --set-click-method=buttons will force it in debug-events.

The --verbose argument will also tell you what state the various pieces are in.

It seems there's an inconsistency here:

Gnome Settings > Devices > Mouse & Touchpad > Tap to Click = ON
gnome-tweak-tool > Keyboard & Mouse > Touchpad > Mouse Click Emulation = Area

but...

Device:           Apple Wireless Trackpad
Kernel:           /dev/input/event15
Group:            7
Seat:             seat0, default
Size:             132x112mm
Capabilities:     pointer gesture
Tap-to-click:     disabled   <---- off?
Tap-and-drag:     enabled
Tap drag lock:    disabled
Left-handed:      disabled
Nat.scrolling:    disabled
Middle emulation: disabled
Calibration:      n/a
Scroll methods:   *two-finger edge 
Click methods:    button-areas *clickfinger <--- wrong one?
Disable-w-typing: n/a
Accel profiles:   none
Rotation:         n/a

Is that correct for libinput to natively show its defaults rather than the gnome settings? or a bug?

Can you show me which command you'd like run next?

all the libinput tools create their own context, nothing but the compositor has access to the compositor's context. So libinput list-devices shows the default settings, libinput debug-events uses the default settings unless specified otherwise.

Apple touchpads have clickfinger enabled by default, so that's why the bottom-right doesn't work as right click.

uhm, and I just realised: do you expect a tap on the bottom right button to be a right click? If so, that feature doesn't exist in libinput.

This bug doesn't bother me personally. I was only trying to reproduce the downstream issue but now realise I misread "enable" as "disable". So maybe I have the wrong bug link.

That said, I'm still a little curious about this one because it sounds like a contradiction between:

Click methods:    button-areas *clickfinger

and

"do you expect a tap on the bottom right button to be a right click? If so, that feature doesn't exist in libinput."

It does work, for clicks but not for taps. So are you saying it was mutter doing that emulation all along?

https://wayland.freedesktop.org/libinput/doc/latest/clickpad_softbuttons.html

Physical click in bottom right corner when software buttons are enabled => right click, otherwise always left click. Clickfinger requires 2 fingers to trigger a right click.

Tap anywhere with a single finger (when enabled) -> left click, tap with two fingers -> right click.

From comment #0:
> 3. Tap on bottom-right area.
> Expected: Right click emulated

This feature doesn't exist. You can click in the bottom right corner and get a right click, but tapping always produces a left click.

OK. Happy to forget this bug.