Description of problem: I'm seeing spurious events from my touchpad, sending button 2 (middle click) events every 20-30 ms, as long as I hold two fingers at a certain place. I originally suspected faulty hardware, but no, it doesn't happen with kernel 4.11.11. It happens with kernel 4.12.5. I also tried downgrading libinput, that had no effect. The problem seems to occur when you do a triple finger click (button 3, right click) on the touchpad. From that point on, if you hold two fingers in that place where you did the triple finger click, it sends button 2 events continuously, like this: ButtonPress event, serial 33, synthetic NO, window 0x3200001, root 0xd6, subw 0x0, time 1251222, (74,60), root:(75,125), state 0x10, button 2, same_screen YES ButtonRelease event, serial 33, synthetic NO, window 0x3200001, root 0xd6, subw 0x0, time 1251222, (74,60), root:(75,125), state 0x210, button 2, same_screen YES ButtonPress event, serial 33, synthetic NO, window 0x3200001, root 0xd6, subw 0x0, time 1251241, (74,60), root:(75,125), state 0x10, button 2, same_screen YES ButtonRelease event, serial 33, synthetic NO, window 0x3200001, root 0xd6, subw 0x0, time 1251241, (74,60), root:(75,125), state 0x210, button 2, same_screen YES ButtonPress event, serial 33, synthetic NO, window 0x3200001, root 0xd6, subw 0x0, time 1251261, (74,60), root:(75,125), state 0x10, button 2, same_screen YES ButtonRelease event, serial 33, synthetic NO, window 0x3200001, root 0xd6, subw 0x0, time 1251261, (74,60), root:(75,125), state 0x210, button 2, same_screen YES ButtonPress event, serial 33, synthetic NO, window 0x3200001, root 0xd6, subw 0x0, time 1251279, (74,60), root:(75,125), state 0x10, button 2, same_screen YES ButtonRelease event, serial 33, synthetic NO, window 0x3200001, root 0xd6, subw 0x0, time 1251279, (74,60), root:(75,125), state 0x210, button 2, same_screen YES I noticed this when two finger scrolling was erratic for me in certain places of the touchpad (In firefox with autoscroll enabled, the autoscroll icon gets activated and deactivated tens of times per second). It took me a long time to figure out that the erratic place is related to the last triple finger click. Version-Release number of selected component (if applicable): kernel-4.12.5-300.fc26.x86_64 libinput-1.8.0-2.fc26.x86_64 ThinkPad T450s happens in both X11 and Wayland How reproducible: always for me (but you need to have some skill to find the right place) Steps to Reproduce: 1. make sure you have tap to click and two finger scrolling enabled for your touchpad 2. run xev to see events 3. do a triple finger click in some place - you should see button 2 event shown 4. rest down two fingers on that very place, make them still (do not perform two finger scrolling). You should see tens of button 2 events per second showing up. It might take some time to find the exact right place where to place your two fingers down, but I usually find it in a few attempts, in 5 seconds time. 5. confirm that this problem doesn't happen elsewhere on the touchpad - lay down two fingers elsewhere and see no spurious button 2 events 6. perform a triple finger click elsewhere on the touchpad 7. see that the original place no longer produces spurious events, but the new place does now
Created attachment 1314850 [details] evemu-describe output $ udevadm info /sys/class/input/event16 P: /devices/rmi4-00/input/input21/event16 N: input/event16 E: DEVNAME=/dev/input/event16 E: DEVPATH=/devices/rmi4-00/input/input21/event16 E: ID_BUS=rmi E: ID_INPUT=1 E: ID_INPUT_HEIGHT_MM=53 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=80 E: SUBSYSTEM=input E: USEC_INITIALIZED=8990656
CC Peter Hutterer from libinput, perhaps he can help here.
CCing benjamin, it's a kernel issue and he'll most likely know. If it changed between 4.11 and 4.12 it's likely the result of the RMI4 changes. Please attach your dmesg and the an evemu-record (not -describe) output of a sequence that triggers that issue. Thanks.
Created attachment 1315147 [details] dmesg after bug is triggered
Created attachment 1315149 [details] evemu-record output Here's evemu-record output. This was the first time I triggered the bug after a fresh reboot. First I performed a three finger tap (that took several attempts, I find it very hard to do - usually it's registered as a two finger tap), and then I laid down two fingers on that very spot (I think I found it on my second attempt) and kept them laying there for a short time - tens of button 2 events were emitted according to xev.
Thanks for the logs. It looks like either a kernel bug or a firmware issue. I'll check with Synaptics.
Not sure if it is related, but I started seeing some duplicate button 2 (middle button) events even with my mouse. Occasionally instead of clicking once, it clicks twice. It can be a failing hardware of course, but the timing seems suspicious.
Even though I only mentioned extra middle click events here, there are two more (most probably connected) issues: 1. While scrolling with two fingers, sometimes right click is triggered. 2. While scrolling with two fingers, the movement is sometimes stopped and then it jumps forward a bit. Like there was a dead spot on the tablet, during which the scrolling either doesn't work or works slower (like moving through a syrup). I believe both of those are connected to the problem described in comment 0 (which I considered a root cause) - when I try to move through the "affected spot", scrolling is broken and extra events are triggered. I write this because more people started complaining about this in the devel list: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/RLSMPQ7IFHDSWOCQV6DLBUB7S56OHLXM/ Please raise priority for this one. Scrolling is almost unusable on my touchpad at the current state.
I also see right click and/or middle click events when trying to do two-finger scrolling. Moving the fingers apart a few millimetres is enough to avoid the issue.
Created attachment 1323518 [details] output of kernel tracking slot assignments It looks like the continual button presses / releases are being caused by the kernel tracking. If I disable kernel tracking I am not able to reproduce it. I added some additional print statements and it looks like the input_mt_assign_slots() is incorrectly alternating the slot number of the first finger. The result is that every new report looks like a new finger has arrived. [ 214.312374] input input11: input_mt_report_slot_state: slot tool type: 0 tools_type: 0 id: -1 [ 214.312386] input input11: rmi_2d_sensor_abs_report: obj[0]: type: 0x01 tool: 0 X: 760 Y: 517 Z: 62 WX: 2 WY: 1 slot: 0 tracking slot: 1 [ 214.312388] input input11: rmi_2d_sensor_abs_report: obj[1]: type: 0x01 tool: 0 X: 1125 Y: 323 Z: 65 WX: 2 WY: 1 slot: 1 tracking slot: 0 I have not looked deeply into how exactly the slots are computed. But, would reducing the DMAX value help avoid this confusion? I don't remember the details of the original issue which caused us to use kernel tracking to begin with.
Sigh. I think I am at fault and I may have used it in a preventive way. There might have been a need for it at some point, but I can't recall why. Problem is, fixing the kernel tracking code is nearly impossible given that only a few people know how it works. I am not part of those people. I'll give a try at removing it (just setting kernel_tracking to false in drivers/input/mouse/synaptics.c is enough), and if the tests are good enough, we should just disable it altogether.
Any hope for having this resolved soon-ish? The touchpad is basically unusable for scrolling right now.
I came to stress the severity of the issue. I use Fedora 26 in a production desktop environment. After my last `dnf update` within Fedora 26 (which updated me to Kernel 4.12) I now accidentally open O(100) browser tabs at once multiple times per day, or accidentally paste text O(100) times into a form field. Or accidentally open the context menu. When all I want to do is scroll, with two fingers. Current system state: $ uname -a Linux jp-t450s 4.12.11-300.fc26.x86_64 #1 SMP Thu Sep 7 18:32:12 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux Can we do something to help? :)
Using a Thinkpad X250 and this issue is terrible. Presume the touchpad is registering the two finger scroll as individual middle clicks. Problem goes away if you use side scroll.
Created attachment 1330183 [details] Patch to disable kernel tracking I created a patch which disables kernel tracking for these devices. Would someone be will it try it out to make sure this fixes the issue before I post it upstream?
Can somebody please create a koji scratch build with the patch included? I'll be happy to test it.
If this one goes to the end, it should have Andrew's patch: https://koji.fedoraproject.org/koji/taskinfo?taskID=22082107
(In reply to Benjamin Tissoires from comment #17) > If this one goes to the end, it should have Andrew's patch: > https://koji.fedoraproject.org/koji/taskinfo?taskID=22082107 Andrew, Benjamin, this new kernel seems to work fine. I'm not seeing any spurious events from the touchpad.
On my T450s with a SynPS/2 Synaptics TouchPad, the following workaround was able to solve the problem: cat << EOF >/etc/udev/rules.d/90-psmouse.rules ACTION=="add|change",SUBSYSTEM=="module",DEVPATH=="/module/psmouse",ATTR{parameters/synaptics_intertouch}="0" EOF udevadm trigger
As an additional note, after updating my system to Fedora 27 beta, the problem is still present and tap-and-drag is not working even with the workaround I posted.
Andrew, Benjamin, can we get the patch included in Fedora kernel package, ideally before F27 Final freeze? Thanks.
FYI, the input maintainer just applied the patch into his tree, scheduled to be sent to Linus ASAP from what I understand: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git/commit/?h=for-linus&id=2b30297d481ad305134252557768c22391e0fed6 If a fedora kernel maintainer wants to pick it up and apply it to f25-rawhide, that would be great.
This patch is included in all kernels 4.13.6 and newer.