Created attachment 131138 [details] "udevadm info" output * libinput 1.7.1 on Arch Linux * Laptop is an Asus UX301L * Physical dimensions are 100x66mm * Using x.org, not Wayland Problem: tapping to click doesn't work at all. Really clicking with the whole touchpad does work, but not tapping on it. Tap-clicking works if I use the Elantech touchpad driver instead of the libinput driver.
Created attachment 131139 [details] xinput properties
Created attachment 131140 [details] DMI ID modalias
Created attachment 131141 [details] evemu recording of me trying to tap-click
What I mean by "the Elantech driver" is actually the Synaptics input driver. Installing the "xs86-input-synaptics" package and using the following x.org configuration makes tap-clicking work: ------------------------------------------------------------ Section "InputClass" Identifier "touchpad" Driver "synaptics" MatchIsTouchpad "on" EndSection ------------------------------------------------------------ For comparison purposes I'll attach Xorg.0.log of for tap-click-working-with-Synaptics.
Created attachment 131142 [details] Xorg.0.log of tap-clicking working with Synaptics instead of libinput
Replaying this with evemu-play and sudo libinput-debug-events --enable-tap running shows me a lot of tap events. Can you please try this as well, not sure what's happening there.
Thanks for looking in this one, too. Running "sudo libinput-debug-events" does not show any tap event, only POINTER_MOVEMENT events when moving a single finger, and POINTER_BUTTON events when I press or release the whole touchpad. Running "sudo libinput-debug-events --enable-tap" does not change anything. No tap events are shown, only POINTER_MOVEMENT events when moving a single finger, and POINTER_BUTTON events when I press or release the whole touchpad. Having "sudo libinput-debug-events --enable-tap" running and executing "sudo evemu-play tapclicking.evemu" in another terminal only shows POINTER_MOVEMENT events and a couple of POINTER_BUTTON events in the later stages, but no tap events at all. I remember pressing the touchpad (really clicking, not tapping) during that recording. Another tidbit of information for which I meant to file a separate bug report (maybe it'll be of help; if not just ignore it, I'm not trying to conflate issues here): the touchpad only recognizes right-clicks in a tiny area to the right of the middle. The whole touchpad is ~10cm wide, and I'd say the area recognized as a right-click is between 6.0cm and 7.0cm. I often need three tries or more to hit the area. Anything else I can try or provide?
(In reply to Moritz Bunkus from comment #7) > Another tidbit of information for which I meant to file a separate bug > report (maybe it'll be of help; if not just ignore it, I'm not trying to > conflate issues here): the touchpad only recognizes right-clicks in a tiny > area to the right of the middle. The whole touchpad is ~10cm wide, and I'd > say the area recognized as a right-click is between 6.0cm and 7.0cm. I often > need three tries or more to hit the area. > > Anything else I can try or provide? yes, the output of the touchpad-edge-detector tool please. This sounds weird. The rest is likely a dupe of bug 100463 as well, let's see how we go after the 1.7.2 update.
With libinput 1.7.2: • "sudo libinput-debug-events --enable-tap" shows POINTER_BUTTON events with BTN_LEFT. Double-tapping does normal text selection in konsole, just like I would expect. • The bottom of the touchpad now reacts properly regarding the area where I'm clicking. Most of the bottom left emits BTN_LEFT, most of the right emits BTN_RIGHT, a smaller part in the middle emits BTN_MIDDLE. All this looks good to me. I consider this to be solved. Thanks a lot! Do you still want the output of touchpad-edge-detector?
yes please, just in case there's something we should fix anyway. Just post the (full) output here and I'll take it from there if anything is needed.
Created attachment 131309 [details] Output of "sudo touchpad-edge-detector 100x66 /dev/input/event10" Sure, here, you go. That's the output of me moving my pinky around the very edges. In a second run I've actually managed to get the reported limits to match the limits reported by the kernel by trying hard to make the coordinates as small/large as possible. However, that involved movements that one wouldn't make during normal usage. The attached file is what I'd consider normal usage.
don't get too wound up by the differences, 10 units is 1/3 of a mm and we can ignore that. Resolution is out but that was already fixed by the PR to systemd in Bug #100873. So we're good, thanks.
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.