Created attachment 124157 [details] evemu-record of the trackpoint during a) putting two fingers on the touchpad, b) pressing and holding the middle button over the touchpad, c) moving the trackpoint As I don't use the touchpad, I disable it with «xinput disable "SynPS/2 Synaptics TouchPad"». However, if I touch it it still sometimes interferes with the trackpoint. This is on an X1 Carbon from 2015 (3rd generation), with physical buttons for the trackpoint. One way to reproduce the issue is to disable the touchpad, hold down two fingers closely side-by-side on the touchpad and then attempting to scroll with holding down the middle button and moving trackpoint. Other issues is that some clicks on the physical trackpoint buttons continues to be considered held down after release.
do a xinput list-props for the synaptics device please after you disable it. The device shouldn't even send events when that is the case, not sure where those events come from...
Device 'SynPS/2 Synaptics TouchPad': Device Enabled (138): 0 Coordinate Transformation Matrix (140): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000 libinput Tapping Enabled (442): 0 libinput Tapping Enabled Default (443): 0 libinput Tapping Drag Enabled (444): 1 libinput Tapping Drag Enabled Default (445): 1 libinput Tapping Drag Lock Enabled (446): 0 libinput Tapping Drag Lock Enabled Default (447): 0 libinput Accel Speed (448): 0.000000 libinput Accel Speed Default (449): 0.000000 libinput Natural Scrolling Enabled (450): 0 libinput Natural Scrolling Enabled Default (451): 0 libinput Send Events Modes Available (258): 1, 1 libinput Send Events Mode Enabled (259): 0, 0 libinput Send Events Mode Enabled Default (260): 0, 0 libinput Left Handed Enabled (452): 0 libinput Left Handed Enabled Default (453): 0 libinput Scroll Methods Available (454): 1, 1, 0 libinput Scroll Method Enabled (455): 1, 0, 0 libinput Scroll Method Enabled Default (456): 1, 0, 0 libinput Click Methods Available (457): 1, 1 libinput Click Method Enabled (458): 1, 0 libinput Click Method Enabled Default (459): 1, 0 libinput Disable While Typing Enabled (460): 1 libinput Disable While Typing Enabled Default (461): 1 Device Node (261): "/dev/input/event13" Device Product ID (262): 2, 7 libinput Drag Lock Buttons (462): <no items> libinput Horizonal Scroll Enabled (263): 1
According to evemu-record, the the touchpad still sends events even after disabling with «xinput disable "SynPS/2 Synaptics TouchPad"». As you can see, the device has «Device Enabled (138): 0», so I don't really know what is going on. Is there any other way of disabling input devices?
(In reply to Martin Sandsmark from comment #3) > According to evemu-record, the the touchpad still sends events even after > disabling with «xinput disable "SynPS/2 Synaptics TouchPad"». that's correct behaviour, evemu record listens to the kernel events which are the same events libinput receives. disabling devices is handled at the X level which is where the devices should be discarded. so evemu should see events. does xinput test-xi2 show events from the touchpad when it is disabled?
> (In reply to Peter Hutterer from comment #4) > does xinput test-xi2 show events from the touchpad when it is disabled? No events are shown when interacting with the touchpad in the window that pops up (moving, clicking, scrolling, etc.).
huh? so you can interact with the window but it doesn't show any events??
(In reply to Peter Hutterer from comment #6) > huh? so you can interact with the window but it doesn't show any events?? I can only interact with the window with the trackpoint. But if I hold down two fingers on the touchpad (as described in the initial comment) at the same time as I try interacting with the trackpoint (e. g. clicking), it sometimes fails to get any events (I'm not sure if that is because I'm just bad at holding my fingers correctly on the touchpad).
confirmed on my T450 which has the same touchpad hardware. Punting to benjamin though, this is either a kernel bug or more likely a hardware bug. Benjamin: T450, two fingers held on the touchpad and physical button clicks on the trackpoint are discarded randomly. Only with two fingers, one finger on the touchpad is fine. On this hardware, the trackpoint buttons are actually wired to the touchpad and the kernel re-routes them through the correct device node instead. So I suspect what is happening is that the physical hardware is getting a bit swamped with events.
Created attachment 124193 [details] ps2emu recording Recording: two fingers held down in place, several trackpoint left button clicks (10 or so) approximately one second apart each.
Created attachment 124203 [details] ps2emu recording of 2 finger touch, middle press, trackpoint move, middle release one more ps2emu recording of 2 finger touch, middle press, trackpoint move, middle release. There is only one top button press/release in this sequence, and the PS/2 recording only show one frame with ext button detection.
Created attachment 124204 [details] parsed output of the ps2emu recording with only one middle click For the record, the nearly parsed and assembled output of the previous recording.
Created attachment 124205 [details] parse_synaptics.py My script for synaptics recordings that assemble the events into frames and parses X/Y
Looking at the parsed output on the recording I just submitted, there is only one event (at 2.605918) which has the ext button flag. In the synaptics.c source, the ext button event is marked with ((buf[0]^buf[3]) & 0x02). buf[3] is only at 0xc2 in the recording at the end, when I release the middle button. So the events are not provided correctly to the kernel, and that's why the kernel doesn't emit events it can't see. To be sure whether it was a hardware failure or a firmware issue, I switched the touchpad on my t450s to RMI4 over SMBus. In this case, I can not see such failure to transmit events, and so the hardware sees those events, but the firmware messes up while on pure PS/2. That's one more bug over pure PS/2 that can be solved only by switching to RMI4, and so I'll try to push forward the acceptance of the SMBus Host Notify piece right now. This piece blocks us to get the RMI4 over SMBus accepted upstream.
closing this bug just so it doesn't show up in my search queries :) Please do post updates here as the kernel fixes progress. thanks.
I am using Kernel 4.7.0 on Debian Testing. It was a lot worse under Ubuntu, but I can confirm it is still an issue. I am using a T460 and when browsing, the trackpoint gets stuck in scroll mode (can recreate behavior by using scrolling with fingers on touchpad despite it being disabled). Any idea what I could do now?
> so I'll try to push forward the acceptance of the SMBus Host Notify piece right now. This piece blocks us to get the RMI4 over SMBus accepted upstream. Could you provide some bug tracker or mailing list links to those patches? I'd like to follow their progress/contribute/test if I can. I'm highly motivated, the "stuck button" behavior is extremely bothersome.
The patches are here: https://patchwork.kernel.org/patch/9167249/ This is the last discussion I saw about them: https://lkml.org/lkml/2016/6/9/371
The support of the I2c/SMBus part is now upstream and will be in the v4.8 final: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/i2c/i2c-smbus.c?id=e456cd37bc28abe47dc65189df916ac0510ac1d4 I submitted a while ago (see previous comment) the RMI4-smbus driver but had received some push-back regarding the suspend resume process. I haven't had the time to finish and send an updated and more satisfying version. Once rmi4-smbus will get accepted, we will "just" need to bind the driver from the PS/2 node, but this require some changes in the psmouse driver I am not entirely happy about :(
> we will "just" need to bind the driver from the PS/2 node, but this require some changes in the psmouse driver I am not entirely happy about :( Can you describe these? I am eager to test a complete patch stack -- kernel 4.8, rmi4-smbus, plus this psmouse patch, presumably. Thanks for doing such excellent legwork on this! Presumably Windows is using the SMBUS pathway for its trackpoint driver, which is why Lenovo hasn't fixed this on their side... Also, out of curiosity, what is the "one more bug over pure PS/2 that can be solved only by switching to RMI4"?
(In reply to C. Scott Ananian from comment #19) > > we will "just" need to bind the driver from the PS/2 node, but this require some changes in the psmouse driver I am not entirely happy about :( > > Can you describe these? I am eager to test a complete patch stack -- kernel > 4.8, rmi4-smbus, plus this psmouse patch, presumably. I just updated my tree here: https://github.com/bentiss/linux/commits/synaptics-rmi4-smbus-v4.8-rc1+ (branch synaptics-rmi4-smbus-v4.8-rc1+ then). This is somethign I am more happy about and I think I'll submit those in tomorrow or by Friday. If you are not feeling OK taking my various merges, you can just take a 4.8-rc* and stack up the 12 patches I committed today (from "Input: synaptics-rmi4 - add SMBus support") > > Thanks for doing such excellent legwork on this! Presumably Windows is > using the SMBUS pathway for its trackpoint driver, which is why Lenovo > hasn't fixed this on their side... That's the other side of the story, yes. > > Also, out of curiosity, what is the "one more bug over pure PS/2 that can be > solved only by switching to RMI4"? I can't recall the exact list, but I think the main issue is that the PS/2 version of the driver doesn't track more than 2 fingers, which means we have some weird corner cases when 3 or 4 fingers are put and released. Using RMI4 allows 5 true touches, which is much better :)
Because it is notoriously hard to follow the LKML, is there a kernel Bugzilla entry for this which I can track?
(In reply to Martin Sandsmark from comment #21) > Because it is notoriously hard to follow the LKML, is there a kernel > Bugzilla entry for this which I can track? Well, no. I submitted a v1 here: http://www.spinics.net/lists/linux-input/msg46488.html I got some reviews on part of the code, and when I receive the last requested changes, I'll send out a v2. There is nothing scary in the requested changes, so at least I should have some Ack/rev-by soon enough. Then, it'll be up to the input maintainer to take the patches, but given the series is big, it might take him some time to do a final review and apply the patches.
I am experiencing the same problem on my new Thinkpad T460p. Is there any update on the progress of those patches? Thanks. I tried both the libinput driver and the synaptics driver, with the touchpad enabled and disabled (via xinput or synclient), and in all cases touching the touchpad while pressing or releasing the trackpoint buttons causes some button events to be lost, at random. And touching the touchpad with my thumbs is inevitable. I wish I could disable the touchpad at the hardware level. Maybe I should try taping something over the touchpad.
The patches are slowly making their way into their kernel, but they aren't merged yet. https://www.spinics.net/lists/kernel/msg2360452.html is the latest submission
In the meantime, cardboard (about 1mm thick) and Scotch tape are working.
*** Bug 98733 has been marked as a duplicate of this bug. ***
this is the right branch that got merged in, right?: https://git.kernel.org/cgit/linux/kernel/git/dtor/input.git/commit/?id=ebfb0184ef560897fad35005989e82433419202c which means it might get into 4.10?
yep, and there's a PR waiting for linus to merge it. http://lkml.iu.edu/hypermail/linux/kernel/1612.2/00646.html
FWIW, I still have this issue with 4.10. Is there anything special I need to do to get the touchpad to use rmi4? also fwiw, the psmouse module gets loaded, but none of the rmi4 modules do.
some of the patches missed the merge window, so rmi4 isn't enabled just yet, sorry. Dig around in benjamin's github for a branchname that matches something recent, that's the one to use :)
Good news! There is a respin of my series by the input maintainer[1] and we are getting closer to the inclusion. There is now a high chance it will be in v4.12, so now we just have to request our favorite distributions to backport the series :) [1] http://www.spinics.net/lists/linux-input/msg50162.html
Did the fix make it into 4.12? I am currently running it the problem still seems to be present.
(In reply to Armando Cerna from comment #32) > Did the fix make it into 4.12? I am currently running it the problem still > seems to be present. Yes it did. The X1 Carbon 3rd generation should be now working out of the box. However, please note that if you are running ubuntu, you need to complain to your distribution to un-backlist i2c-i801 which is disabled by default (a grep in /etc should give you which file is at fault)
(In reply to Benjamin Tissoires from comment #33) > (In reply to Armando Cerna from comment #32) > > Did the fix make it into 4.12? I am currently running it the problem still > > seems to be present. > > Yes it did. The X1 Carbon 3rd generation should be now working out of the > box. However, please note that if you are running ubuntu, you need to > complain to your distribution to un-backlist i2c-i801 which is disabled by > default (a grep in /etc should give you which file is at fault) I actually have a t460s i'm running arch and 4.12.8 the module shows up in an lsmod i2c_i801 24576 0 Is there any other output that would be helpuful?
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.