Bug 1482640
Summary: | [regression] kernel 4.12.5 sends spurious button 2 (middle click) events from touchpad, 50 times per second | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Kamil Páral <kparal> | ||||||||||||
Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> | ||||||||||||
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||||
Severity: | unspecified | Docs Contact: | |||||||||||||
Priority: | unspecified | ||||||||||||||
Version: | 26 | CC: | accdias, aduggan, alsadi, btissoir, conflatulence, fzatlouk, gansalmon, haliyo, ichavero, itamar, jforbes, jgehrcke, jonathan, kernel-maint, kparal, madhu.chinakonda, mchehab, peter.hutterer, roger.k.wells, sergio, tommyamos, zbyszek | ||||||||||||
Target Milestone: | --- | Keywords: | CommonBugs | ||||||||||||
Target Release: | --- | ||||||||||||||
Hardware: | Unspecified | ||||||||||||||
OS: | Unspecified | ||||||||||||||
Whiteboard: | https://fedoraproject.org/wiki/Common_F27_bugs#touchpad-spurious-events | ||||||||||||||
Fixed In Version: | Doc Type: | If docs needed, set a value | |||||||||||||
Doc Text: | Story Points: | --- | |||||||||||||
Clone Of: | Environment: | ||||||||||||||
Last Closed: | 2017-10-19 14:25:56 UTC | Type: | Bug | ||||||||||||
Regression: | --- | Mount Type: | --- | ||||||||||||
Documentation: | --- | CRM: | |||||||||||||
Verified Versions: | Category: | --- | |||||||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||||||
Embargoed: | |||||||||||||||
Attachments: |
|
Description
Kamil Páral
2017-08-17 19:13:36 UTC
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. |