Bug 103017

The problematic sequence seems to be here. It follows a long 2-finger scroll
sequence with two fingers on the touchpad and ends like this:

E: 5.191392 0003 002f 0000      # EV_ABS / ABS_MT_SLOT          0
E: 5.191392 0003 0039 -001      # EV_ABS / ABS_MT_TRACKING_ID   -1
E: 5.191392 0003 002f 0001      # EV_ABS / ABS_MT_SLOT          1
E: 5.191392 0003 0035 0839      # EV_ABS / ABS_MT_POSITION_X    839
E: 5.191392 0003 0036 0297      # EV_ABS / ABS_MT_POSITION_Y    297
E: 5.191392 0003 003a 0049      # EV_ABS / ABS_MT_PRESSURE      49
E: 5.191392 0001 0145 0001      # EV_KEY / BTN_TOOL_FINGER      1
E: 5.191392 0001 014d 0000      # EV_KEY / BTN_TOOL_DOUBLETAP   0
E: 5.191392 0003 0000 0839      # EV_ABS / ABS_X                839
E: 5.191392 0003 0001 0297      # EV_ABS / ABS_Y                297
E: 5.191392 0003 0018 0049      # EV_ABS / ABS_PRESSURE         49
E: 5.191392 0000 0000 0000      # ------------ SYN_REPORT (0) ---------- +10ms
E: 5.200812 0003 0039 -001      # EV_ABS / ABS_MT_TRACKING_ID   -1
E: 5.200812 0003 002f 0000      # EV_ABS / ABS_MT_SLOT          0
E: 5.200812 0003 0039 1002      # EV_ABS / ABS_MT_TRACKING_ID   1002
E: 5.200812 0003 0035 0834      # EV_ABS / ABS_MT_POSITION_X    834
E: 5.200812 0003 0036 0292      # EV_ABS / ABS_MT_POSITION_Y    292
E: 5.200812 0003 003a 0049      # EV_ABS / ABS_MT_PRESSURE      49
E: 5.200812 0003 0031 0000      # EV_ABS / ABS_MT_TOUCH_MINOR   0
E: 5.200812 0003 0000 0834      # EV_ABS / ABS_X                834
E: 5.200812 0003 0001 0292      # EV_ABS / ABS_Y                292
E: 5.200812 0000 0000 0000      # ------------ SYN_REPORT (0) ---------- +9ms
E: 5.210479 0003 0039 -001      # EV_ABS / ABS_MT_TRACKING_ID   -1
E: 5.210479 0001 014a 0000      # EV_KEY / BTN_TOUCH            0
E: 5.210479 0001 0145 0000      # EV_KEY / BTN_TOOL_FINGER      0
E: 5.210479 0003 0018 0000      # EV_ABS / ABS_PRESSURE         0

the 5.191392 event is 'first finger up, second finger move'
the 5.200812 event is 'second finger up, first finger down again'
the 5.210479 event is 'first finger up'

So what libinput sees is a two-finger scroll followed by a single-finger
tap. Whether that's justified as a right click instead of a left click is a
bit ambiguous to decide but a tap is definitely there. Not sure how to fix
this without messing around with timeouts after scrolling, etc.

To clarify: are you tapping at all here? or just lifting the fingers?

I am not tapping in this case, at least not intentionally. At very minimum I would be happy if this accidental tap isn't treated as a 2 finger tap. 

Another fix that would help me is - disable 2 finger tap altogether since I use physical buttons present in T450s. 

BTW - this appeared to have started to happen recently. In Fedora 25, I didn't had palm detection working but at least 2 finger tap problem wasn't there. After upgrading Fedora 26, palm detection wasn't working as well but 2 finger accidental tap problem came up. I tried using `lmr` mapping but that is no help at all.

So I upgraded to master version of libinput and voila palm detection was perfect (wondering if this was a packaging issue with stock libinput fedora package) but 2 finger tap problem was still there.

Since I am running from master, I can provide you whatever debug output you need. I was thinking of implementing a timeout based solution myself, like discard all 2 finger taps for 1-2 seconds after 2 finger scroll event is finished.

If you're using the buttons anyway, why not disable tapping altogether?

I strongly suspect that the trigger for this is the switch to SMBus/RMI4 from the old serial protoocol. That came into effect with kernel 4.12. The tap is there in the kernel events and I reproduced the bug at least with libinput 1.8.0 as well. Implementing the timeout after tap is... tricky. Not quite sure yet when I'll find the time to do that.

any chance you can verify that this doesn't occur with a kernel 4.11 btw?

Yes I think I can. let me try and report back.

So it turns out, Fedora does not make it easy to try a older version of kernel and I don't have enough time to  compile my own and try. I will keep looking though.

https://koji.fedoraproject.org/koji/packageinfo?packageID=8 has a list of packages for download, you can then install them and reboot

FWIW, I believe that I'm also seeing this issue - or one very close to it - on Arch Linux. I'm on a Lenovo Thinkpad T440p, running GNOME 3.26 under Wayland 1.14.0-1, libinput 1.8.3-1. Kernel is 4.13.5-1-ARCH.

Whenever I enable tap-to-click (which I hugely prefer since I have a clickpad and am an ex-Mac user) I get an unusable number of spurious right and middle clicks when I two-finger scroll. If I'm super-careful about exactly how I place my fingers on the touchpad, how I scroll etc, then I can generally just about avoid these - but as soon as I go back to using the thing naturally I end up right/middle clicking all over the place. Quite often I get dozens of click events in a row during scrolling which can e.g. result in a huge number of tabs being opened in my browser. It makes tap-to-click essentially unusable.

I never had this problem with this touchpad under Mint Cinnamon when using the Synaptics driver - but the palm detection was considerably inferior and I'd like to be part of the future direction of Gnome/Wayland if possible.

udev info:
P: /devices/rmi4-00/input/input16/event14
N: input/event14
E: DEVNAME=/dev/input/event14
E: DEVPATH=/devices/rmi4-00/input/input16/event14
E: ID_BUS=rmi
E: ID_INPUT=1
E: ID_INPUT_HEIGHT_MM=66
E: ID_INPUT_TOUCHPAD=1
E: ID_INPUT_TOUCHPAD_INTEGRATION=internal
E: ID_INPUT_WIDTH_MM=97
E: LIBINPUT_DEVICE_GROUP=1d/6cb/0/0:rmi4-00
E: MAJOR=13
E: MINOR=78
E: SUBSYSTEM=input
E: USEC_INITIALIZED=3411945

modalias:
dmi:bvnLENOVO:bvrGLET80WW(2.34):bd07/23/2015:svnLENOVO:pn20AN006NUS:pvrThinkPadT440p:rvnLENOVO:rn20AN006NUS:rvr0B98401WIN:cvnLENOVO:ct10:cvrNotAvailable:

Let me know if you want me to do an evemu_record for my machine as well. From a user perspective, it just feels like click events immediately after two-finger scrolling should be ignored, but I've no doubt that it's more complicated than that!

if you're on 4.13, you may see the same kernel bugs, see comment #1. iirc synaptics has no timer after scrolling to prevent tapping, so it would see the same clicks - I suspect you had it running on an older kernel that didn't exhibit that behaviour?

a month in needinfo, closing