Recently I found libinput supports multi-finger gestures as an alternative to touchpad buttons. Most of the times it's amazing, except when it doesn't work. Sometimes touching the touchpad with 3 fingers ends up with no visible effect, othertimes its effect is as if I touched with two fingers (e.g. a context menu pops up). The evemu-record is done with a few attempts to make the triple-button gesture over a terminal. Some attempts resulted in no visible effect, whereas when this detected as a two-fingers click, I had to make a single click to dismiss the menu. Note: the very last triple click in the record did succeed. laptop: SAMSUNG NP305V5A touchpad: x=103mm, y=53mm. (I'm traveling, measures are done with a checkered notebook) libinput version tested: 1.9.901.r0.g0ac4a148 (git) $ udevadm info /dev/input/event10 P: /devices/platform/i8042/serio1/input/input8/event10 N: input/event10 S: input/by-path/platform-i8042-serio-1-event-mouse E: DEVLINKS=/dev/input/by-path/platform-i8042-serio-1-event-mouse E: DEVNAME=/dev/input/event10 E: DEVPATH=/devices/platform/i8042/serio1/input/input8/event10 E: ID_BUS=i8042 E: ID_INPUT=1 E: ID_INPUT_HEIGHT_MM=48 E: ID_INPUT_TOUCHPAD=1 E: ID_INPUT_TOUCHPAD_INTEGRATION=internal E: ID_INPUT_WIDTH_MM=94 E: ID_PATH=platform-i8042-serio-1 E: ID_PATH_TAG=platform-i8042-serio-1 E: ID_SERIAL=noserial E: LIBINPUT_DEVICE_GROUP=11/2/7:isa0060/serio1 E: LIBINPUT_MODEL_JUMPING_SEMI_MT=1 E: LIBINPUT_MODEL_SYNAPTICS_SERIAL_TOUCHPAD=1 E: MAJOR=13 E: MINOR=74 E: SUBSYSTEM=input E: USEC_INITIALIZED=19212 $ cat /sys/class/dmi/id/modalias dmi:bvnAmericanMegatrendsInc.:bvr07PW.ME06.20120112.SKK:bd01/12/2012:svnSAMSUNGELECTRONICSCO.,LTD.:pn305V4A/305V5A/3415VA:pvr07PW:rvnSAMSUNGELECTRONICSCO.,LTD.:rn305V4A/305V4A:rvr07PW:cvnSAMSUNGELECTRONICSCO.,LTD.:ct9:cvrN/A:
Created attachment 137269 [details] 3 fingers touch record
are all these 3-finger taps in that recording? There are only two BTN_TOOL_TRIPLETAP events in here, the first of which is detected as palm (edge), the second one (last tap in the recording) is, correctly, a middle click. If there are more than two 3-finger taps in this recording, then one issue is with the hardware not even detecting the three fingers.
(In reply to Peter Hutterer from comment #2) > are all these 3-finger taps in that recording? There are only two > BTN_TOOL_TRIPLETAP events in here, the first of which is detected as palm > (edge), the second one (last tap in the recording) is, correctly, a middle > click. > > If there are more than two 3-finger taps in this recording, then one issue > is with the hardware not even detecting the three fingers. Yeah, I remember there were at least 3 3-finger taps besides the last one (i.e. 4 3-finger taps overall); and at least one of them was detected as a 2-finger tap. So, isn't detection done by libinput itself? Can it be done by libinput instead of firmware?
libinput converts the touches into relative motion, or taps, or scrolling, etc. But libinput cannot *detect* the touches [1], that has to be done by the firmware. The kernel sets BTN_TOOL_FINGER, BTN_TOOL_DOUBLETAP and BTN_TOOL_TRIPLETAP together with the slot data (which is what we use where available), so that's the easiest and quickest way to check if a finger is detected at all. Easiest way to verify if that is (part of) the issue is running evemu-record |grep BTN_TOOL and checking that output while tapping. If you don't see TRIPLETAP every time you three-finger tap, then that's the source of that. Slower tapping can help, might be you're really too fast for the device to detect contact. Without that data, we can't do that much. So in this particular recording, the only one we could fix in libinput is the one that's also detected as a palm, but not the other two.
(In reply to Peter Hutterer from comment #4) > libinput converts the touches into relative motion, or taps, or scrolling, > etc. But libinput cannot *detect* the touches [1], that has to be done by > the firmware. The kernel sets BTN_TOOL_FINGER, BTN_TOOL_DOUBLETAP and > BTN_TOOL_TRIPLETAP together with the slot data (which is what we use where > available), so that's the easiest and quickest way to check if a finger is > detected at all. You probably wanted to add a link, but forgot :) > Easiest way to verify if that is (part of) the issue is running evemu-record > |grep BTN_TOOL and checking that output while tapping. If you don't see > TRIPLETAP every time you three-finger tap, then that's the source of that. > Slower tapping can help, might be you're really too fast for the device to > detect contact. > > Without that data, we can't do that much. So in this particular recording, > the only one we could fix in libinput is the one that's also detected as a > palm, but not the other two. Okay, thanks for the idea — when that gonna happen again, I'll try to check what BTN_TOOL* events produced upon triple-tapping, perhaps is there some pattern showing that something weird is going on. I shall note that triple-tap for some reason stops working occasionally, and then usually it don't work for a number of consequent triple-taps. Slowing down, holding fingers on the touchpad, etc, doesn't help it.
whoops. that was supposed to be: [1] we *decide* whether a detected touch is a logical touch based on pressure/size to filter out palms but also light/hovering touches. but that still requires the touchpad to detect them first.
Ok, before I forgot: the moment when 3-fingers touch gets detected as a 2-fingers unfortunately produces what looks exactly like 2-fingers tap: E: 62.717573 0001 014d 0001 # EV_KEY / BTN_TOOL_DOUBLETAP 1 E: 62.835737 0001 014d 0000 # EV_KEY / BTN_TOOL_DOUBLETAP 0 I'll try to catch the other moment, when 3-fingers tap don't work like any tap at all.
Okay, I caught the flow when 3-fingers touch is not detected, and nothing happens. It looks like 2-finger touch and 1-finger touches at close time, e.g.: Sample 1: E: 34.311155 0001 0145 0001 # EV_KEY / BTN_TOOL_FINGER 1 E: 34.334286 0001 0145 0000 # EV_KEY / BTN_TOOL_FINGER 0 E: 34.334286 0001 014d 0001 # EV_KEY / BTN_TOOL_DOUBLETAP 1 E: 34.457612 0001 014d 0000 # EV_KEY / BTN_TOOL_DOUBLETAP 0 Sample 2: E: 47.998600 0001 014d 0001 # EV_KEY / BTN_TOOL_DOUBLETAP 1 E: 48.072614 0001 0145 0001 # EV_KEY / BTN_TOOL_FINGER 1 E: 48.072614 0001 014d 0000 # EV_KEY / BTN_TOOL_DOUBLETAP 0 E: 48.116407 0001 0145 0000 # EV_KEY / BTN_TOOL_FINGER 0 Sample 3: E: 73.864204 0001 014d 0001 # EV_KEY / BTN_TOOL_DOUBLETAP 1 E: 73.968262 0001 0145 0001 # EV_KEY / BTN_TOOL_FINGER 1 E: 73.968262 0001 014d 0000 # EV_KEY / BTN_TOOL_DOUBLETAP 0 E: 73.995397 0001 0145 0000 # EV_KEY / BTN_TOOL_FINGER 0 Sample 4: E: 82.847529 0001 0145 0001 # EV_KEY / BTN_TOOL_FINGER 1 E: 82.881636 0001 0145 0000 # EV_KEY / BTN_TOOL_FINGER 0 E: 82.881636 0001 014d 0001 # EV_KEY / BTN_TOOL_DOUBLETAP 1 E: 82.983867 0001 014d 0000 # EV_KEY / BTN_TOOL_DOUBLETAP 0 Worth emphasizing that for some reason these does not cause any action at all. E.g. I have selected a text, and rationally after such a misdetected touch shall happen either α) a menu pops up, or β) the selected text gets unselected. The samples I shown above cause neither α nor β, like if they get completely ignored by libinput.
run libinput debug-events --verbose at the same time, that give you more debugging output and you can tell what tap state a touch is in and what palm state it is in. if a finger is detected as palm it'll be reflected as such, and if there's too much movement to cancel the tap, it'll show up as well.
(In reply to Peter Hutterer from comment #9) > run libinput debug-events --verbose at the same time, that give you more > debugging output and you can tell what tap state a touch is in and what palm > state it is in. if a finger is detected as palm it'll be reflected as such, > and if there's too much movement to cancel the tap, it'll show up as well. Thanks, I managed to get it, though don't really know what to make of that info: Sample from evemu-record | grep BTN_TOOL: E: 29.585448 0001 0145 0001 # EV_KEY / BTN_TOOL_FINGER 1 E: 29.625140 0001 0145 0000 # EV_KEY / BTN_TOOL_FINGER 0 E: 29.625140 0001 014d 0001 # EV_KEY / BTN_TOOL_DOUBLETAP 1 E: 29.769373 0001 014d 0000 # EV_KEY / BTN_TOOL_DOUBLETAP 0 Acc. output from libinput debug-events --verbose: event10 - palm: keyboard timeout event10 - pressure: begin touch event10 - button state: from BUTTON_STATE_NONE, event BUTTON_EVENT_IN_AREA to BUTTON_STATE_AREA event10 - button state: from BUTTON_STATE_NONE, event BUTTON_EVENT_IN_AREA to BUTTON_STATE_AREA event10 - gesture state: GESTURE_STATE_NONE → GESTURE_STATE_SCROLL event10 - gesture state: GESTURE_STATE_SCROLL → GESTURE_STATE_SCROLL event10 - gesture state: GESTURE_STATE_SCROLL → GESTURE_STATE_SCROLL event10 - gesture state: GESTURE_STATE_SCROLL → GESTURE_STATE_SCROLL -event10 POINTER_AXIS +33.50s vert 2.73* horiz 0.00 (finger) event10 - gesture state: GESTURE_STATE_SCROLL → GESTURE_STATE_SCROLL event10 POINTER_AXIS +33.52s vert 1.46* horiz 0.00 (finger) event10 - pressure: end touch event10 - button state: from BUTTON_STATE_AREA, event BUTTON_EVENT_UP to BUTTON_STATE_NONE event10 - button state: from BUTTON_STATE_AREA, event BUTTON_EVENT_UP to BUTTON_STATE_NONE event10 POINTER_AXIS +33.57s vert 0.00* horiz 0.00* (finger)
I shall say I noticed that 2-finger tap often sends the same tuple from 1-finger tap and 2-finger tap. It doesn't make any sense except that those who wrote the firmware are asses. Oh, well, at least the problem that events often get skipped by libinput whatsoever can be fixed.
oops, sorry, I forgot: you need to --enable-tap, it's disabled by default on your device. Could be the fw, could be the HW, could be the protocol. You're on PS2 as well, try passing psmouse.synaptics_intertouch=1 on the kernel boot line in grub and see if that makes a difference (you should see a new device appear, named Synaptics ABCD or so)
(In reply to Peter Hutterer from comment #12) > oops, sorry, I forgot: you need to --enable-tap, it's disabled by default on > your device. Could be the fw, could be the HW, could be the protocol. You're > on PS2 as well, try passing psmouse.synaptics_intertouch=1 on the kernel > boot line in grub and see if that makes a difference (you should see a new > device appear, named Synaptics ABCD or so) Np, I did the record with the option; will try the kernel boot option, but a bit later — I'm travelling, don't have ATM a live-usb/cd to boot from if I screw up something. FWIW these records are done with 2-finger touch, it seems to easier reproduce than the 3-finger touch that ends up looking the same in the evemu-record anyway. Sample from evemu-record | grep BTN_TOOL: E: 22.688289 0001 0145 0001 # EV_KEY / BTN_TOOL_FINGER 1 E: 22.717802 0001 0145 0000 # EV_KEY / BTN_TOOL_FINGER 0 E: 22.717802 0001 014d 0001 # EV_KEY / BTN_TOOL_DOUBLETAP 1 E: 22.810558 0001 014d 0000 # EV_KEY / BTN_TOOL_DOUBLETAP 0 Acc. output from libinput debug-events --verbose --enable-tap: event7 - palm: keyboard timeout event7 - pressure: begin touch event7 - button state: from BUTTON_STATE_NONE, event BUTTON_EVENT_IN_AREA to BUTTON_STATE_AREA event7 - button state: from BUTTON_STATE_NONE, event BUTTON_EVENT_IN_AREA to BUTTON_STATE_AREA event7 - tap state: TAP_STATE_IDLE → TAP_EVENT_TOUCH → TAP_STATE_TOUCH event7 - tap state: TAP_STATE_TOUCH → TAP_EVENT_TOUCH → TAP_STATE_TOUCH_2 event7 - tap state: TAP_STATE_TOUCH_2 → TAP_EVENT_MOTION → TAP_STATE_TOUCH_2_HOLD event7 - tap state: TAP_STATE_TOUCH_2_HOLD → TAP_EVENT_MOTION → TAP_STATE_TOUCH_2_HOLD event7 - gesture state: GESTURE_STATE_NONE → GESTURE_STATE_SCROLL -event7 POINTER_AXIS +26.00s vert 24.59* horiz 0.00 (finger) event7 - pressure: end touch event7 - button state: from BUTTON_STATE_AREA, event BUTTON_EVENT_UP to BUTTON_STATE_NONE event7 - button state: from BUTTON_STATE_AREA, event BUTTON_EVENT_UP to BUTTON_STATE_NONE event7 - tap state: TAP_STATE_TOUCH_2_HOLD → TAP_EVENT_RELEASE → TAP_STATE_HOLD event7 - tap state: TAP_STATE_HOLD → TAP_EVENT_RELEASE → TAP_STATE_IDLE event7 POINTER_AXIS +26.03s vert 0.00* horiz 0.00* (finger) This one is interesting — I did a 2-finger tap, and it got correctly shown as such — however I didn't get a popup menu. Sample from evemu-record | grep BTN_TOOL: E: 525.924421 0001 014d 0001 # EV_KEY / BTN_TOOL_DOUBLETAP 1 E: 526.042849 0001 014d 0000 # EV_KEY / BTN_TOOL_DOUBLETAP 0 Acc. output from libinput debug-events --verbose --enable-tap: event7 - palm: keyboard timeout event7 - pressure: begin touch event7 - button state: from BUTTON_STATE_NONE, event BUTTON_EVENT_IN_AREA to BUTTON_STATE_AREA event7 - button state: from BUTTON_STATE_NONE, event BUTTON_EVENT_IN_AREA to BUTTON_STATE_AREA event7 - tap state: TAP_STATE_IDLE → TAP_EVENT_TOUCH → TAP_STATE_TOUCH event7 - tap state: TAP_STATE_TOUCH → TAP_EVENT_TOUCH → TAP_STATE_TOUCH_2 event7 - tap state: TAP_STATE_TOUCH_2 → TAP_EVENT_MOTION → TAP_STATE_TOUCH_2_HOLD event7 - tap state: TAP_STATE_TOUCH_2_HOLD → TAP_EVENT_MOTION → TAP_STATE_TOUCH_2_HOLD event7 - gesture state: GESTURE_STATE_NONE → GESTURE_STATE_SCROLL -event7 POINTER_AXIS +543.67s vert 0.00 horiz 6.98* (finger) event7 - pressure: end touch event7 - button state: from BUTTON_STATE_AREA, event BUTTON_EVENT_UP to BUTTON_STATE_NONE event7 - button state: from BUTTON_STATE_AREA, event BUTTON_EVENT_UP to BUTTON_STATE_NONE event7 - tap state: TAP_STATE_TOUCH_2_HOLD → TAP_EVENT_RELEASE → TAP_STATE_HOLD event7 - tap state: TAP_STATE_HOLD → TAP_EVENT_RELEASE → TAP_STATE_IDLE event7 POINTER_AXIS +543.71s vert 0.00* horiz 0.00* (finger)
(In reply to Hi-Angel from comment #13) > Np, I did the record with the option; will try the kernel boot option, but a > bit later — I'm travelling, don't have ATM a live-usb/cd to boot from if I > screw up something. add it manually on boot instead of writing into the grub.cfg and the worst thing that can happen is that you don't have a touchpad :) > event7 - tap state: TAP_STATE_IDLE → TAP_EVENT_TOUCH → TAP_STATE_TOUCH > event7 - tap state: TAP_STATE_TOUCH → TAP_EVENT_TOUCH → TAP_STATE_TOUCH_2 > event7 - tap state: TAP_STATE_TOUCH_2 → TAP_EVENT_MOTION → > TAP_STATE_TOUCH_2_HOLD > event7 - tap state: TAP_STATE_TOUCH_2_HOLD → TAP_EVENT_MOTION → > TAP_STATE_TOUCH_2_HOLD translation: idle to 'one finger down' to 'two fingers down' to 'motion threshold exceeded'. if you have the git repo, there is a touchpad-tap-state-machine.svg that illustrates all this. try not to scream when you see it first ;) > event7 - tap state: TAP_STATE_TOUCH_2 → TAP_EVENT_MOTION → > TAP_STATE_TOUCH_2_HOLD same here - you're getting motion events when the second finger is down, exceeding the internal thresholds and we go from tap to just 'two fingers down'. note that the state machine is independent of everything else, so tapping is in the 'two fingers down' state when e.g. you're two-finger scrolling. The 'button state' debug events are for the software button state, unrelated again.
(In reply to Peter Hutterer from comment #14) > (In reply to Hi-Angel from comment #13) > > Np, I did the record with the option; will try the kernel boot option, but a > > bit later — I'm travelling, don't have ATM a live-usb/cd to boot from if I > > screw up something. > > add it manually on boot instead of writing into the grub.cfg and the worst > thing that can happen is that you don't have a touchpad :) > > > event7 - tap state: TAP_STATE_IDLE → TAP_EVENT_TOUCH → TAP_STATE_TOUCH > > event7 - tap state: TAP_STATE_TOUCH → TAP_EVENT_TOUCH → TAP_STATE_TOUCH_2 > > event7 - tap state: TAP_STATE_TOUCH_2 → TAP_EVENT_MOTION → > > TAP_STATE_TOUCH_2_HOLD > > event7 - tap state: TAP_STATE_TOUCH_2_HOLD → TAP_EVENT_MOTION → > > TAP_STATE_TOUCH_2_HOLD > > translation: idle to 'one finger down' to 'two fingers down' to 'motion > threshold exceeded'. if you have the git repo, there is a > touchpad-tap-state-machine.svg that illustrates all this. try not to scream > when you see it first ;) Thanks, I like the graph, though I think being svg is not good. I think such graph would be nicer in html, or something alike that would allow a text search/highlight. > > event7 - tap state: TAP_STATE_TOUCH_2 → TAP_EVENT_MOTION → > > TAP_STATE_TOUCH_2_HOLD > > same here - you're getting motion events when the second finger is down, > exceeding the internal thresholds and we go from tap to just 'two fingers > down'. note that the state machine is independent of everything else, so > tapping is in the 'two fingers down' state when e.g. you're two-finger > scrolling. > > The 'button state' debug events are for the software button state, unrelated > again. Thanks, I think I see. For the record, I might be getting motion events of fingers down because I'm also affected by #104828 aka "wobbly touchpad". 2 days ago I did also override hysteresis locally to have it always enabled — and I think this codepath ought to remove the motion before deciding if the user is scrolling or not.
(In reply to Hi-Angel from comment #15) > (In reply to Peter Hutterer from comment #14) > > (In reply to Hi-Angel from comment #13) > > > Np, I did the record with the option; will try the kernel boot option, but a > > > bit later — I'm travelling, don't have ATM a live-usb/cd to boot from if I > > > screw up something. > > > > add it manually on boot instead of writing into the grub.cfg and the worst > > thing that can happen is that you don't have a touchpad :) Thanks, forgot to say, yeah, will try. > > > event7 - tap state: TAP_STATE_IDLE → TAP_EVENT_TOUCH → TAP_STATE_TOUCH > > > event7 - tap state: TAP_STATE_TOUCH → TAP_EVENT_TOUCH → TAP_STATE_TOUCH_2 > > > event7 - tap state: TAP_STATE_TOUCH_2 → TAP_EVENT_MOTION → > > > TAP_STATE_TOUCH_2_HOLD > > > event7 - tap state: TAP_STATE_TOUCH_2_HOLD → TAP_EVENT_MOTION → > > > TAP_STATE_TOUCH_2_HOLD > > > > translation: idle to 'one finger down' to 'two fingers down' to 'motion > > threshold exceeded'. if you have the git repo, there is a > > touchpad-tap-state-machine.svg that illustrates all this. try not to scream > > when you see it first ;) > > Thanks, I like the graph, though I think being svg is not good. I think such > graph would be nicer in html, or something alike that would allow a text > search/highlight. Wow, never mind — I've tried gwenview, and there doesn't seem to be a text search; however I just found the svg can be opened with browser, and text search does work :)
(In reply to Peter Hutterer from comment #12) > oops, sorry, I forgot: you need to --enable-tap, it's disabled by default on > your device. Could be the fw, could be the HW, could be the protocol. You're > on PS2 as well, try passing psmouse.synaptics_intertouch=1 on the kernel > boot line in grub and see if that makes a difference (you should see a new > device appear, named Synaptics ABCD or so) Just did; it seems like I don't see the wobbliness in "libinput debug-events --verbose" anymore. I think I'll try compiling libinput from git again, then gonna work for some time like this to see how it's going.
(In reply to Hi-Angel from comment #17) > (In reply to Peter Hutterer from comment #12) > > oops, sorry, I forgot: you need to --enable-tap, it's disabled by default on > > your device. Could be the fw, could be the HW, could be the protocol. You're > > on PS2 as well, try passing psmouse.synaptics_intertouch=1 on the kernel > > boot line in grub and see if that makes a difference (you should see a new > > device appear, named Synaptics ABCD or so) > > Just did; it seems like I don't see the wobbliness in "libinput debug-events > --verbose" anymore. I think I'll try compiling libinput from git again, then > gonna work for some time like this to see how it's going. Nvm about wobbliness — perhaps movement events that removed by hysteresis not being shown in libinput debug-events. Regarding your question to experiment — no, I don't see any difference, e.g. 2-fingers touch still results in 1-finger + 2-fingers tuple. I have yet to see the problem of skipping the touches — but, I think, we determined that it's result of motion by wobbly touchpad, and wobbliness persist, so not sure if there's anything more to see.
yes, if the movement is dropped with the hysteresis, you won't see any debug output for it (otherwise we'd spam the log like crazy).
Any updates now that all the hysteresis patches have been merged on master?
(In reply to Peter Hutterer from comment #20) > Any updates now that all the hysteresis patches have been merged on master? Yeah, double-touch still seems to not work occasionally. I'm using git at commit d8db6b5927f61460b2991479a85056256c819485 "touchpad: end hovering touches in maybe_end_touch". Output of "libinput debug-events --verbose --enable-tap" for a single "non-working" double-touch: event10 - pressure: begin touch 0 event10 - button state: touch 0 from BUTTON_STATE_NONE, event BUTTON_EVENT_IN_AREA to BUTTON_STATE_AREA event10 - button state: touch 1 from BUTTON_STATE_NONE, event BUTTON_EVENT_IN_AREA to BUTTON_STATE_AREA event10 - tap: touch 0 state TAP_STATE_IDLE → TAP_EVENT_TOUCH → TAP_STATE_TOUCH event10 - tap: touch 1 state TAP_STATE_TOUCH → TAP_EVENT_TOUCH → TAP_STATE_TOUCH_2 event10 - button state: touch 1 from BUTTON_STATE_AREA, event BUTTON_EVENT_UP to BUTTON_STATE_NONE event10 - tap: touch 0 state TAP_STATE_TOUCH_2 → TAP_EVENT_MOTION → TAP_STATE_TOUCH_2_HOLD event10 - tap: touch 1 state TAP_STATE_TOUCH_2_HOLD → TAP_EVENT_RELEASE → TAP_STATE_HOLD event10 - tap: touch 0 state TAP_STATE_HOLD → TAP_EVENT_MOTION → TAP_STATE_HOLD event10 - pressure: end touch 0 event10 - button state: touch 0 from BUTTON_STATE_AREA, event BUTTON_EVENT_UP to BUTTON_STATE_NONE event10 - tap: touch 0 state TAP_STATE_HOLD → TAP_EVENT_RELEASE → TAP_STATE_IDLE Output of evemu-record for the same double-touch: E: 20.461822 0003 002f 0000 # EV_ABS / ABS_MT_SLOT 0 E: 20.461822 0003 0039 0527 # EV_ABS / ABS_MT_TRACKING_ID 527 E: 20.461822 0003 0035 4097 # EV_ABS / ABS_MT_POSITION_X 4097 E: 20.461822 0003 0036 3175 # EV_ABS / ABS_MT_POSITION_Y 3175 E: 20.461822 0003 0000 4097 # EV_ABS / ABS_X 4097 E: 20.461822 0003 0001 3175 # EV_ABS / ABS_Y 3175 E: 20.461822 0003 0018 0026 # EV_ABS / ABS_PRESSURE 26 E: 20.461822 0003 001c 0006 # EV_ABS / ABS_TOOL_WIDTH 6 E: 20.461822 0001 0145 0001 # EV_KEY / BTN_TOOL_FINGER 1 E: 20.461822 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +6837ms E: 20.492061 0003 0035 3366 # EV_ABS / ABS_MT_POSITION_X 3366 E: 20.492061 0003 0036 2975 # EV_ABS / ABS_MT_POSITION_Y 2975 E: 20.492061 0003 002f 0001 # EV_ABS / ABS_MT_SLOT 1 E: 20.492061 0003 0039 0528 # EV_ABS / ABS_MT_TRACKING_ID 528 E: 20.492061 0003 0035 4097 # EV_ABS / ABS_MT_POSITION_X 4097 E: 20.492061 0003 0036 2508 # EV_ABS / ABS_MT_POSITION_Y 2508 E: 20.492061 0001 014a 0001 # EV_KEY / BTN_TOUCH 1 E: 20.492061 0003 0001 2975 # EV_ABS / ABS_Y 2975 E: 20.492061 0003 0018 0041 # EV_ABS / ABS_PRESSURE 41 E: 20.492061 0003 001c 0005 # EV_ABS / ABS_TOOL_WIDTH 5 E: 20.492061 0001 0145 0000 # EV_KEY / BTN_TOOL_FINGER 0 E: 20.492061 0001 014d 0001 # EV_KEY / BTN_TOOL_DOUBLETAP 1 E: 20.492061 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +31ms E: 20.515281 0003 002f 0000 # EV_ABS / ABS_MT_SLOT 0 E: 20.515281 0003 0036 2971 # EV_ABS / ABS_MT_POSITION_Y 2971 E: 20.515281 0003 002f 0001 # EV_ABS / ABS_MT_SLOT 1 E: 20.515281 0003 0035 4096 # EV_ABS / ABS_MT_POSITION_X 4096 E: 20.515281 0003 0036 2509 # EV_ABS / ABS_MT_POSITION_Y 2509 E: 20.515281 0003 0000 4093 # EV_ABS / ABS_X 4093 E: 20.515281 0003 0001 2967 # EV_ABS / ABS_Y 2967 E: 20.515281 0003 0018 0043 # EV_ABS / ABS_PRESSURE 43 E: 20.515281 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +23ms E: 20.538615 0003 002f 0000 # EV_ABS / ABS_MT_SLOT 0 E: 20.538615 0003 0036 2972 # EV_ABS / ABS_MT_POSITION_Y 2972 E: 20.538615 0003 002f 0001 # EV_ABS / ABS_MT_SLOT 1 E: 20.538615 0003 0036 2566 # EV_ABS / ABS_MT_POSITION_Y 2566 E: 20.538615 0003 0000 4094 # EV_ABS / ABS_X 4094 E: 20.538615 0003 0001 2978 # EV_ABS / ABS_Y 2978 E: 20.538615 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +23ms E: 20.550366 0003 002f 0000 # EV_ABS / ABS_MT_SLOT 0 E: 20.550366 0003 0035 3328 # EV_ABS / ABS_MT_POSITION_X 3328 E: 20.550366 0003 0036 3129 # EV_ABS / ABS_MT_POSITION_Y 3129 E: 20.550366 0003 002f 0001 # EV_ABS / ABS_MT_SLOT 1 E: 20.550366 0003 0039 -001 # EV_ABS / ABS_MT_TRACKING_ID -1 E: 20.550366 0003 0000 3328 # EV_ABS / ABS_X 3328 E: 20.550366 0003 0001 3129 # EV_ABS / ABS_Y 3129 E: 20.550366 0003 001c 0004 # EV_ABS / ABS_TOOL_WIDTH 4 E: 20.550366 0001 0145 0001 # EV_KEY / BTN_TOOL_FINGER 1 E: 20.550366 0001 014d 0000 # EV_KEY / BTN_TOOL_DOUBLETAP 0 E: 20.550366 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +12ms E: 20.561980 0003 002f 0000 # EV_ABS / ABS_MT_SLOT 0 E: 20.561980 0003 0035 3304 # EV_ABS / ABS_MT_POSITION_X 3304 E: 20.561980 0003 0036 3153 # EV_ABS / ABS_MT_POSITION_Y 3153 E: 20.561980 0003 0000 3304 # EV_ABS / ABS_X 3304 E: 20.561980 0003 0001 3153 # EV_ABS / ABS_Y 3153 E: 20.561980 0003 0018 0030 # EV_ABS / ABS_PRESSURE 30 E: 20.561980 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +11ms E: 20.596309 0003 0039 -001 # EV_ABS / ABS_MT_TRACKING_ID -1 E: 20.596309 0001 014a 0000 # EV_KEY / BTN_TOUCH 0 E: 20.596309 0003 0018 0000 # EV_ABS / ABS_PRESSURE 0 E: 20.596309 0003 001c 0000 # EV_ABS / ABS_TOOL_WIDTH 0 E: 20.596309 0001 0145 0000 # EV_KEY / BTN_TOOL_FINGER 0 E: 20.596309 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +35ms
s/double-touch/double-finger touch.
> event10 - tap: touch 0 state TAP_STATE_TOUCH_2 → TAP_EVENT_MOTION → TAP_STATE_TOUCH_2_HOLD That's still the problem here, a motion event after the second finger down causes it to not detect the tap. I think this may be related to how we handle semi-mt touchpads too, because we treat them effectively as single-finger touchpads. In the 20.550366 event you get a large finger movement as slot 1 ends but because we process slots in order, I wonder if that triggers a bug where we think there's movement before we realise it's part of the finger up.
Sorry about the delay, I actually had a patch in my tree and forgot about it. Pushed now, please re-open if this doesn't fix the issue. Note that the failure of detection can have multiple sources, most notably the lack of BTN_TOOL_TRIPLETAP. Those we can't fix. commit 80c3a100de23de90cb76d023f9972b6ce3094ee2 Author: Peter Hutterer <> Date: Thu Mar 15 09:09:28 2018 +1000 touchpad: ignore any semi-mt movement in the same frame as a finger release
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.