| Summary: | libinput does not filter proximity events | ||
|---|---|---|---|
| Product: | Wayland | Reporter: | Alberto Ruiz <aruiz> |
| Component: | libinput | Assignee: | Peter Hutterer <peter.hutterer> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | CC: | benjamin.tissoires, jadahl, jstpierre, jwrdegoede, peter.hutterer |
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
evemu-record: Single finger down, second hovering
evemu-record: Two fingers down, third hovering evemu-record: Just two fingers down |
||
|
Description
Alberto Ruiz
2014-12-10 16:56:28 UTC
I need three more logs please: * single finger down on the surface, second finger hovering * two fingers down, third finger hovering * two fingers down Created attachment 110732 [details]
evemu-record: Single finger down, second hovering
Created attachment 110733 [details]
evemu-record: Two fingers down, third hovering
Created attachment 110734 [details]
evemu-record: Just two fingers down
thanks for the recordings. Preliminary analysis: BTN_TOUCH is set when a finger meets a given pressure threshold. see https://git.kernel.org/cgit/linux/kernel/git/jikos/hid.git/tree/drivers/input/mouse/synaptics.c#n1293 The hardcoded 30 matches the synaptics user interface guidelines section "3.2.5. Absolute mode Z values" So we can use that to check if a finger is down or hovering. Alas, BTN_TOOL_DOUBLETAP is set as soon as the second slot is active and we lose hover information for the second finger. BTN_TOUCH may be set if the pressure is high enough, but it may not be. If it is set, we don't know if the second finger is down too or just hovering. So we can only tell if both fingers are hovering (DOUBLETAP 1, TOUCH 0) or at least one finger is down (DOUBLETAP 1, TOUCH 1). ABS_PRESSURE is useless otherwise, it doesn't give us any information that we could use to work with the second finger. So right now it looks like we can avoid erroneous events while all fingers are hovering, but we cannot avoid them once a single finger is down. Alberto, you can verify the above oopsy, accidentally hit enter. Alberto, you can verify the above by running evemu-record | grep BTN_blah and grep for the various BTN_TOUCH, BTN_TOOL_DOUBLETAP, BTN_TOOL_TRIPLETAP bits. Hover with fingers, touch the touchpad and look at how they change. If my analysis is out, please let me know This is what I get when I touch with the first finger straight away, you're right, only a single BTN_TOUCH is sent, after that we get pairs of FINGER/DOUBLETAP or FINGER/TRIPLETAP whenever I get to hover the other fingers (it doesn't matter if I actually tap or hover the 2nd or 3rd finger). E: 0.000000 0001 0145 0001 # EV_KEY / BTN_TOOL_FINGER 1 E: 0.023554 0001 014a 0001 # EV_KEY / BTN_TOUCH 1 E: 3.210067 0001 0145 0000 # EV_KEY / BTN_TOOL_FINGER 0 E: 3.210067 0001 014d 0001 # EV_KEY / BTN_TOOL_DOUBLETAP 1 E: 3.222594 0001 0145 0001 # EV_KEY / BTN_TOOL_FINGER 1 E: 3.222594 0001 014d 0000 # EV_KEY / BTN_TOOL_DOUBLETAP 0 E: 3.246199 0001 0145 0000 # EV_KEY / BTN_TOOL_FINGER 0 E: 3.246199 0001 014d 0001 # EV_KEY / BTN_TOOL_DOUBLETAP 1 E: 3.258874 0001 0145 0001 # EV_KEY / BTN_TOOL_FINGER 1 E: 3.258874 0001 014d 0000 # EV_KEY / BTN_TOOL_DOUBLETAP 0 E: 3.283560 0001 0145 0000 # EV_KEY / BTN_TOOL_FINGER 0 E: 3.283560 0001 014d 0001 # EV_KEY / BTN_TOOL_DOUBLETAP 1 E: 3.295906 0001 0145 0001 # EV_KEY / BTN_TOOL_FINGER 1 E: 3.295906 0001 014d 0000 # EV_KEY / BTN_TOOL_DOUBLETAP 0 E: 3.356936 0001 0145 0000 # EV_KEY / BTN_TOOL_FINGER 0 E: 3.356936 0001 014d 0001 # EV_KEY / BTN_TOOL_DOUBLETAP 1 E: 3.516155 0001 0145 0001 # EV_KEY / BTN_TOOL_FINGER 1 E: 3.516155 0001 014d 0000 # EV_KEY / BTN_TOOL_DOUBLETAP 0 E: 5.132726 0001 0145 0000 # EV_KEY / BTN_TOOL_FINGER 0 E: 5.132726 0001 014d 0001 # EV_KEY / BTN_TOOL_DOUBLETAP 1 E: 8.489703 0001 014d 0000 # EV_KEY / BTN_TOOL_DOUBLETAP 0 E: 8.489703 0001 014e 0001 # EV_KEY / BTN_TOOL_TRIPLETAP 1 E: 8.562962 0001 014d 0001 # EV_KEY / BTN_TOOL_DOUBLETAP 1 E: 8.562962 0001 014e 0000 # EV_KEY / BTN_TOOL_TRIPLETAP 0 E: 8.612023 0001 014d 0000 # EV_KEY / BTN_TOOL_DOUBLETAP 0 E: 8.612023 0001 014e 0001 # EV_KEY / BTN_TOOL_TRIPLETAP 1 E: 8.783801 0001 014d 0001 # EV_KEY / BTN_TOOL_DOUBLETAP 1 E: 8.783801 0001 014e 0000 # EV_KEY / BTN_TOOL_TRIPLETAP 0 E: 9.323452 0001 014d 0000 # EV_KEY / BTN_TOOL_DOUBLETAP 0 E: 9.323452 0001 014e 0001 # EV_KEY / BTN_TOOL_TRIPLETAP 1 Addendum here: Jasper sent me an evemu-record from an alps touchpad today that didn't set BTN_TOUCH at all. The pressure never went past the kernel threshold to set it, even at what Jasper said was a heavy touch. The patch series on the list for hovering touches is inadequate for that case, we can't rely on BTN_TOUCH by the kernel for all devices. This was a touchpad from a prototype laptop we were looking at building. The touchpad or the kernel might have been misconfigured. ok, let's not worry about it for now then. I suspect we'll have to deal with it one day, but not today :) commit a467ac32cf5e731d4c18f4cf2983cec8c9c2a6af Author: Peter Hutterer <peter.hutterer@who-t.net> Date: Thu Dec 11 16:39:04 2014 +1000 touchpad: add a TOUCH_HOVERING state |
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.