Tap to click doesn't work with bottom-right area mode.
1. Settings > Devices > Mouse & Touchpad > Tap to Click = ON
2. gnome-tweak-tool > Keyboard & Mouse > Touchpad > Mouse Click Emulation = Area
3. Tap on bottom-right area.
Expected: Right click emulated
Observed: Left click emulated
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
Device: Apple Wireless Trackpad
Seat: seat0, default
Capabilities: pointer gesture
Tap-to-click: disabled <---- off?
Tap drag lock: disabled
Middle emulation: disabled
Scroll methods: *two-finger edge
Click methods: button-areas *clickfinger <--- wrong one?
Accel profiles: none
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
"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?
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.