Bug 200077 - ThinkPad X1 Carbon Gen5 trackpad no longer works
Summary: ThinkPad X1 Carbon Gen5 trackpad no longer works
Status: NEW
Alias: None
Product: Drivers
Classification: Unclassified
Component: Input Devices (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: drivers_input-devices
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-06-14 15:23 UTC by C Snell
Modified: 2020-01-24 10:12 UTC (History)
3 users (show)

See Also:
Kernel Version: 4.16.15
Subsystem:
Regression: No
Bisected commit-id:


Attachments

Description C Snell 2018-06-14 15:23:22 UTC
There has been a regression between 4.16.13 and 4.16.15 with the trackpad on my Lenovo ThinkPad X1 Carbon Gen5. When I start X11, the trackpad does not function at all.  The Trackpoint stick pointer, however, continues to work just fine.  The 'synclient' utility doesn't produce any errors and appears to function normally.

This can be reproduced 100% of the time.  The laptop functions completely normally under 4.16.15 and worked fine on prior kernels so it appears that this is a recent regression.


Steps to reproduce: boot 4.16.15 kernel on this laptop

Steps to resolve:  boot 4.16.13 or earlier kernel on this laptop.
Comment 1 C Snell 2018-06-14 19:14:59 UTC
I noticed something interesting about the symptoms: the Trackpad actually *does* work, but only the rightmost 1/2" responds to touch. Most of the trackpad is dead. 

I noticed a few recent commits in 4.16.4 related to trackpad identification that might be relevant. 

https://github.com/torvalds/linux/commit/59d895f17023e75dcb302934b4ecc5b4686ba080

https://github.com/torvalds/linux/commit/ad8fb554f04e38f155c9bc34bbf521fc592ceee7
Comment 2 Dmitry Torokhov 2018-06-15 17:31:57 UTC
Do you see events from entire touchpad if you run "evtest" utility on its device? IOW I'm trying to find out if it is userspace or kernel issue.
Comment 3 C Snell 2018-06-15 17:45:02 UTC
I will test that next time I'm in a broken kernel.  I'm in the middle of bisecting and testing.  I believe that the issue was introduced in one of these commits but not sure which one yet:

9b2071028f8def49971a3b213ab6efd02a7e56e8
ad8fb554f04e38f155c9bc34bbf521fc592ceee7
0044cdeb731313f20b63cb5644de7588731de32b
Comment 4 C Snell 2018-06-16 03:16:31 UTC
Dmitry, evtest does produce events from the entire trackpad even though only the rightmost portion of the pad produces mouse movement.  The device in question is the Synaptics TM3289-002.
Comment 5 C Snell 2018-06-16 03:20:10 UTC
Another strange aspect of the behavior:  if you start a movement on the right side portion of the trackpad that does work and drag it to the left across the trackpad, the mouse will move in any direction that you want so long as you don't lift your finger off the pad.  You just have to start on the right-most side of the pad.
Comment 6 C Snell 2018-06-16 03:28:39 UTC
Ha, I figured out what was causing this.  In my Xorg startup, I ran "synclient" to create a zone of non-sensitivity around the edge of the touchpad to keep random palm touches from moving the mouse:

synclient AreaLeftEdge=1800 AreaRightEdge=5200 AreaBottomEdge=5000

Something changed with the RMI4 driver making the configuration above no longer correct.  Do you have any idea what might be affecting this?

(Commenting out the synclient call above makes everything work again, although I now have a trackpad that's prone to palm movements once again)
Comment 7 C Snell 2018-06-16 03:44:04 UTC
Sorry for blowing this bug up... figured out what's going on with synclient: the scales changed.  The width of the trackpad prior to these kernel changes was about 7000 "units", but with the new driver, it's around 1860 units.  Thus, AreaLeftEdge=1800 puts the left edge almost at the right edge of the physical pad.

If this new scale is going to be the way things are going forward, fine...but many users are going to be confused if they've already set up their synclient configs..
Comment 8 Dmitry Torokhov 2018-06-18 17:38:52 UTC
Hm, we do need to get off the PS/2 emulation so RMI4 is indeed the way to go forward. Users need to pay attention to the limits of ranges exported by the devices, hopefully there are not too many people hardcoding this in startup scripts, especially with synclient being phased out and not working with libinput.
Comment 9 C Snell 2018-06-18 18:51:43 UTC
I agree mostly, although I don't think that it's reasonable to expect users to pay attention to something like device ranges across every kernel revision.   Is it really true that synclient doesn't work libinput?  It seems like it worked on my laptop.   

Since the ranges are changing and synclient is deprecated, could the driver be changed so that synclient is intentionally and completely broken and not able to put the input in a non-functional state?

Note You need to log in before you can comment on or make changes to this bug.