Summary: | Both two- and three- finger taps register as right-clicks, with no way to middle-click via taps | ||
---|---|---|---|
Product: | xorg | Reporter: | andykluger |
Component: | Input/libinput | Assignee: | Peter Hutterer <peter.hutterer> |
Status: | RESOLVED FIXED | QA Contact: | Xorg Project Team <xorg-team> |
Severity: | normal | ||
Priority: | medium | CC: | andykluger, benjamin.tissoires, peter.hutterer |
Version: | unspecified | ||
Hardware: | x86-64 (AMD64) | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: |
Description
andykluger
2016-10-05 17:18:55 UTC
Created attachment 127212 [details]
tap.evemu
in the future, please attach evemu recordings rather than pasting them.
looks like the device claims to support 4 touches (slots) but never sends slot data for the third touch (possibly the fourth). libinput ignores BTN_TOOL_TRIPLETAP if the device has more than 2 slots, so to libinput it simply looks like the third finger is never set down. that's a bug in the device or the kernel driver, with the remaining question of whether it's fixable or whether we need a udev tag to work around this. Benjamin? Andy: run evemu-record again and grep for ABS_MT_SLOT. do you see slots 2 and 3 ever activating when you put 3 or 4 fingers down? or does the slot value only cover 0 to 1 only Sorry about the large paste, I'd edit the comment/report if I could. Before suspend-wake dance, no events are recorded. After, those events are recorded, and the right-most column is always either 0 or 1 (perfectly alternating). Created attachment 127266 [details] [review] 0001-evdev-add-a-quirk-for-the-HP-Zbook-Studio-G3.patch See https://wayland.freedesktop.org/libinput/doc/latest/faq.html#faq_hwdb_changes for some extra info, you need to make sure the new hwdb entry is applied and triggers for the device Should any of that from the other page be necessary if I just modify my distro's build script for libinput to apply the patch before building and installing? That's what I did (and I see the new stuff in /usr/lib/udev/hwdb.d/90-libinput-model-quirks.hwdb), and restarted. The behavior is the same as before. By the way, a Zbook (HP) is not a ZenBook (Asus). (In reply to andykluger from comment #5) > Should any of that from the other page be necessary if I just modify my > distro's build script for libinput to apply the patch before building and > installing? that should be fine, provided it runs the udevadm hwdb --update etc. > That's what I did (and I see the new stuff in > /usr/lib/udev/hwdb.d/90-libinput-model-quirks.hwdb), and restarted. The > behavior is the same as before. is the property applied? if not, then I either have some typo in the match rule or the hwdb doesn't update as expected > By the way, a Zbook (HP) is not a ZenBook (Asus). yep, spotted that and already fixed locally, thanks Created attachment 127288 [details] [review] 0001-evdev-add-a-quirk-for-the-HP-Zbook-Studio-G3.patch Found a typo, please try this one Same results, except with four taps, # evemu-record|grep abs_mt_slot also spits out: /dev/input/event4: HP Wireless hotkeys How can I verify that the property is applied? (In reply to andykluger from comment #8) > Same results, except with four taps, > > # evemu-record|grep abs_mt_slot fwiw, this should be ABS_MT_SLOT or grep -i, the lowercase version won't show anything. > How can I verify that the property is applied? try sudo udevadm test /sys/class/input/eventX. That both shows the tag and applies it if it's still missing, you can re-run that command after each hwdb change. Yeah, sorry, my grep is always aliased with -i. The udevadm test does report "LIBINPUT_MODEL_HP_ZBOOK_STUDIO_G3=1". Created attachment 127370 [details] [review] 0001-evdev-add-a-quirk-for-the-HP-Zbook-Studio-G3.patch try this one, had the slot number at one too many ping? Sorry, I didn't have a lot of extra time with the work computer. With the new patch, the slots are still alternating between 0 and 1, whether it's a three- or four-finger tap, but the four-finger tab *does middle click!* So that's great, thanks! I still wish I could get a two-finger middle click, but this workable. Thank you again! the four-finger one does middle-click? Should be the three-finger one, unless I've screwed something else up. (In reply to andykluger from comment #13) > Sorry, I didn't have a lot of extra time with the work computer. With the > new patch, the slots are still alternating between 0 and 1, whether it's a > three- or four-finger tap, that's intended, this patch just changes how many slots the touchpad really announces so libinput can look at the BTN_TOOL_* events for anything above the second slot. Yes, four fingers for middle click, three or two for right click, one for left click. In the evemu-record output, do you see BTN_TOOL_QUADTAP for a four-finger tap? do you see BTN_TOOL_TRIPLETAP for a three-finger tap? and also, do you see QUADTAP at all? At least the recording above didn't include it but you may not have quad-tapped then. If the BTN_TOOL bits are out there isn't much we can do in libinput, we rely on the touchpad to be accurate for those Yes, with a single four-finger tap, BTN_TOOL_QUADTAP appears 10 times in the evemu-record output. With a single three-finger tap, BTN_TOOL_TRIPLETAP appears 6 times, and QUADTAP does not appear at all. When I opened this ticket I did not even consider quad taps being a thing, as I have enough trouble doing a triple tap due to the awkward positioning and the finger alignment and angle requirements. I'll attach three- and four-finger single tap logs. Created attachment 127760 [details]
A single three-finger tap evemu log
Created attachment 127761 [details]
A single four-finger tap evemu log
are these unmodified logs? there are sequences in there that the kernel should filter (in theory), e.g. attachment 127760 [details] has three switches from doubletap to tripletap without any switch back. those events are supposed to be filtered by the kernel.
Please always attach the full logs, including the device description at the top. Otherwise I have to figure out which attachments go together to replay an event sequence locally.
They are just the tail ends, as I didn't want to pollute with all the events from just moving the cursor around. I'll recreate and attach full logs next time I get access to that computer. Alright, back at this computer, I'm attaching full logs, each one showing five attempts at the respective tap type. Created attachment 128016 [details]
Five attempts at a three-finger tap
Created attachment 128017 [details]
Five attempts at a four-finger tap
Tested both and they behave as expected, so right now I'm putting down the odd behaviour to some missing bit in the udev hwdb or something, which can happen when testing. I sent the patch to the list now: https://lists.freedesktop.org/archives/wayland-devel/2016-November/031730.html and expect it to be pushed over the next few days. One more comment I should've mentioned earlier: (In reply to andykluger from comment #13) > Sorry, I didn't have a lot of extra time with the work computer. With the > new patch, the slots are still alternating between 0 and 1, whether it's a > three- or four-finger tap, but the four-finger tab *does middle click!* the libinput patch doesn't affect the evemu reporting at all, it merely limits how libinput interprets the events. When you run evemu-debug --verbose --enable-tap, you can check if the tag applies ("event18: tagged as LIBINPUT_MODEL_HP_ZBOOK_STUDIO_G3") and the behaviour is the right one. As I said, this works correctly here with your recordings, so there shouldn't be any reason it works differently on yours closing as fixed, please re-open if it's still an issue after updating libinput commit 6752544e566250ef856b836c4b0e8c994155ffa9 Author: Peter Hutterer <peter.hutterer@who-t.net> Date: Thu Oct 13 19:05:00 2016 +1000 evdev: add a quirk for the HP Zbook Studio G3 I upgraded from libinput 1.5.0 to 1.5.1.r6.g6752544, using kernel 4.8.8, and when X started I had no keyboard or touchpad control at all -- I couldn't even switch to another TTY. I had to boot into single user mode and downgrade to get things working again. I realize now I should have tried the suspend-wake dance while it was in that state -- please let me know if you think that's worth trying. easy way to test: update libinput to the new version, then run sudo libinput-debug-events and see if you see events. Do this without restarting X or rebooting, so X keeps using the old libinput. If you see events, it's not libinput's fault but the kernel. Given the changeset in 1.5.0-current that's what I suspect (and the suspend dance should 'fix' it). Alright, I've now updated to kernel 4.8.10, btw. Within a running X session, I did the dance, then upgraded to libinput-git and debugged events, and they did show up. Later when I have some more time I'll reboot and observe the tapping behavior after suspending, assuming that closing the lid at the SDDM login screen triggers a suspension. Aside from suspending an waking my computer every time I turn it on or switch TTYs, what is to be done next? 'sudo systemd-sleep suspend' should force a suspend if you don't think you can trust the lid close. the suspend issue is Bug 98099, let's keep it there. The lid close does not suspend at the SDDM screen, and I obviously cannot use that command because I have no use of the keyboard or touchpad. I see now that libinput-1.5.2 has been released. Do I need to add a rule for my package manager to stop upgrading that package to keep my computer usable? And can we keep this open until someone who actually has the hardware in question can verify the fix? I consider this issue fixed, the suspend thing is really something different, and at least not caused by this specific bugfix. You said above: (In reply to andykluger from comment #27) > I upgraded from libinput 1.5.0 to 1.5.1.r6.g6752544, using kernel 4.8.8 ... Please run a git bisect between those commits to figure out which one of them breaks the touchpad. But given that it works after the suspend, I doubt it's a libinput issue anyway given that libinput isn't aware of the suspend and Bug 98099 shows that the i2c device dies. I went through the whole bisect process, wound up back at 1.5.1.r6.g6752544, and (with kernel 4.8.11) could not reproduce that locked-out-at-boot problem. Then, after the suspend-and-wake dance, two finger taps were left clicks and three finger taps were middle clicks. Fantastic! Thank you! |
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.