Summary: | Unwanted double tap (right click) with one finger | ||
---|---|---|---|
Product: | Wayland | Reporter: | Paviluf <jeremy9856> |
Component: | libinput | Assignee: | Wayland bug list <wayland-bugs> |
Status: | RESOLVED NOTOURBUG | QA Contact: | |
Severity: | normal | ||
Priority: | medium | CC: | peter.hutterer |
Version: | unspecified | ||
Hardware: | Other | ||
OS: | All | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Bug Depends on: | 100122 | ||
Bug Blocks: | |||
Attachments: |
unwanted two finger tap
evemu log unwanted two finger tap |
Description
Paviluf
2017-03-27 11:41:46 UTC
fwiw, "doubletap" are two single-finger taps in quick succession, resulting in a doubleclick. I think what you mean is a two-finger tap? I'll need an evemu-record please from such an unwanted tap so I can reproduce it here. Created attachment 130554 [details]
unwanted two finger tap
You are right, it's an unwanted two-finger tap with one finger, sorry.
Here is an evemu record. It had happened almost at the end.
Thanks !
fyi, evemu-record has a --autorestart=X option that creates a new file after X seconds of inactivity. Makes the recordings shorter, 65000 lines of event log is a bit long to sift through. anyway, a two-finger event first appears at timestamp 305.372914. A second finger is detected, then moves independently of the first finger. This looks like a normal event sequence. 307.037204 and 324.239153 are the same. In all three cases, the sequence looks correct, a second touch lands, both move a bit, then one or both are released. The only hint I have here that some thing *may* be wrong is that in all three cases, both fingers are released within the same or across two event frames. However, this is not something that's detectable, this is normal touchpad interaction. In all three cases, the x/y coordinates of the two touches are distant enough so they appear as two fingers. In other words - there's no way I can see how I could detect this without disabling two-finger interaction altogether. This *may* be fixable in the kernel if the touchpad has some tuning parameters, but I doubt it. You can try, as root, by running: echo 1 > /sys/class/input/event4/device/device/calibrate (and don't touch the touchpad until complete, takes a second or so I think) Note, that syspath might be wrong, swap event4 for your touchpad and dig around for the calibrate attribute. Created attachment 130559 [details]
evemu log
I calibrated the touchpad but that doesn't change anything
# echo 1 > /sys/bus/i2c/devices/i2c-CYAP0000\:00/calibrate
I managed to make a shorter log. I hope you can find something :)
Thanks !
ok, the right click you see is triggered by the software button, not by tapping. You're pressing the physical button and depending on the finger location this triggers a left or right click. See https://wayland.freedesktop.org/libinput/doc/latest/clickpad_softbuttons.html But there's something else that's going on here, look at the event at 0.087396, it sends heaps of different x/y/pressure values within the same frame. That's another sign of the touchpad/driver going a bit nuts, especially because some of the values go well beyond the axis maximum ranges (max is 1280, one value is 3840) Created attachment 130637 [details] unwanted two finger tap (In reply to Peter Hutterer from comment #5) > ok, the right click you see is triggered by the software button, not by > tapping. You're pressing the physical button and depending on the finger > location this triggers a left or right click. See > https://wayland.freedesktop.org/libinput/doc/latest/clickpad_softbuttons.html It was early in the morning but I'm almost certain that I did not physically press a button. > But there's something else that's going on here, look at the event at > 0.087396, it sends heaps of different x/y/pressure values within the same > frame. That's another sign of the touchpad/driver going a bit nuts, > especially because some of the values go well beyond the axis maximum ranges > (max is 1280, one value is 3840) I made a systemd service to calibrate the touchpad at boot and on resume. It seem a little bit better but that still happening. I made an other log (I hope it's the right one since I used the --autorestart option). same thing here, look for BTN_LEFT in the output, it happens at 8.962308. There are a few other taps that generate left buttons correctly, but that one is a click and is interpreted based on software button behaviour. Could be that your touchpad has a really sensitive physical trigger? I think your best escape from this problem is to enable clickfinger behaviour, that way a right-click is triggered by a two-finger click rather than a location-dependent click. That should work around this issue. (In reply to Peter Hutterer from comment #7) > same thing here, look for BTN_LEFT in the output, it happens at 8.962308. > There are a few other taps that generate left buttons correctly, but that > one is a click and is interpreted based on software button behaviour. > > Could be that your touchpad has a really sensitive physical trigger? It's not sensitive. To make a physical click you have to press a lot stronger than a tap. > I think your best escape from this problem is to enable clickfinger > behaviour, that way a right-click is triggered by a two-finger click rather > than a location-dependent click. That should work around this issue. I tried your advice for a full day and it seem to work very well ! Thank you very very much ! This touchpad is so crappy... (In reply to Paviluf from comment #8) > It's not sensitive. To make a physical click you have to press a lot > stronger than a tap. maybe, but check the BTN_LEFT events in the output. That button means a physical click and since the kernel usually doesn't just make those up, the firmware of the touchpad says a click has occured. So you may notice a *physical* difference between clicking and tapping like the above, but all we can go on is what the touchpad tells us. |
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.