Bug 198223

Summary: Thinkpad X1 Carbon Gen 5 ALPS trackpoint not working.
Product: Drivers Reporter: Edvard (edvard.holst)
Component: Input DevicesAssignee: drivers_input-devices
Status: RESOLVED CODE_FIX    
Severity: high CC: alexander_schier, bjo, dmitry.torokhov, kai.heng.feng, kernel, postix
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 4.14.6 Subsystem:
Regression: No Bisected commit-id:
Attachments: dmesg log with the debug patch applied.

Description Edvard 2017-12-21 10:02:25 UTC 
Created attachment 261287 [details]
dmesg log with the debug patch applied.

This bug report is a result of extensive troubleshooting with great help from Aaron Ma at Canonical.

Lenovo multi-sources the trackpoints for the Thinkpad X1 Carbon Gen 5. So far I have identified three different models. One Elantech model and two different ALPS variant. The older ALPS model (LEN0072) has had Linux support ever since Aaron Ma, with Lenovo's help, added support for it quite some time ago. However, Lenovo only provided data on that particular trackpoint and not the other models. Furthermore, there is now a patch that provides support for the Elantech trackpoint which has been merged in Fedora's kernel source (and I believe now it's merged upstream as well) so that's looking good. This leaves us with the newer ALPS trackpoint which is currently not supported at all. The only way to make it work at all is to boot with psmouse.proto=imps but this leaves you with a touchpad without any support for gestures or palm rejection.

After debugging the trackpoint, psmouse, alps and elantech drivers we analyzed the dmesg logs. It seems like the ps2_command(ps2dev, param, PSMOUSE_CMD_GETID) command fails and returns without any ID. Linux seems to still use the ps/2 passthrough to control the trackpoint even though SMBus is used with the touchpad. This might explain why the trackpoint works under Windows. It's also confusing to us why we see pnp ID LEN0073 in dmesg this is the same ID used by the Elantech trackpoint. I believe the older ALPS variant also used on the X1 Carbon is LEN0072. 

I'm attaching the following: 

- 20171020_TrackPointDetect_.log - Output from Lenovo's TrackpointDetect.exe tool which prints out hardware information regarding the trackpoint device.
- 20171130_dmesg.log - dmesg log with the debug patch applied. 
- 0001-X1-Carbon-trackpoint-debug.patch - The final version of the debug patch we used to troubleshoot the issue. 

There are a bunch of forum and blog posts floating around regarding The X1 Carbon Gen 5 and trackpoint issues with Linux but what many don't realize is the fact that Lenovo multi-sources the trackpoints so while some may have functional trackpoints because they have the old ALPS model, those of us stuck with other variants have no support in Linux at all. Even more annoying is the fact that Lenovo specifically lists the 5th gen X1 Carbon as "Linux Certified" https://support.lenovo.com/no/en/solutions/pd031426 which by their own definition should mean that mouse input should work fine out of the box. 

This might end up being a firmware issue but I'm posting it here regardless hoping that someone more knowledgeable than me can figure this out.

Thanks
Comment 1 Martin Dirichs 2018-01-03 17:45:43 UTC 
This bug seems to affect other Lenovo models as well, I am experiencing the same issue with a Thinkpad L570. The ID of the trackpoint device as shown in dmesg is slightly different, though:

[    0.247469] pnp 00:06: Plug and Play ACPI device, IDs LEN001c PNP0f13 (active)

So possibly this is another trackpoint device that is not currently supported in kernel 4.14.6. On startup, it is incorrectly detected as GlidePoint device (which means touchpad without trackpoint):

kernel: [ 2.997182 ] input: AlpsPS/2 ALPS GlidePoint as /devices/platform/i8042/serio1/input/input6

If this issue is better reported separately, I can open a new bug report.
Comment 2 Edvard 2018-01-04 17:43:10 UTC 
@Martin: This is most likely a separate issue as you seemingly have a completely different trackpoint in your machine.
Comment 3 Dmitry Torokhov 2018-01-05 00:48:10 UTC 
Do you have CONFIG_RMI_F03 "RMI4 Function 03 (PS2 Guest)" enabled?
Comment 4 Edvard 2018-01-05 12:10:38 UTC 
Dimintry, I'm not sure. My X1 Carbon is currently being returned to me from Lenovo after they refused to look into the issue. Even though they list the X1 Carbon 5 as "Linux Certified" they wont provide any support for Linux specific issues. 

However, I did not explicitly enable CONFIG_RMI_F03 when compiling the kernel for Fedora but I can confirm that I am able to reproduce this issue reliably across several distro's with their included kernels. Ubuntu, Fedora and Arch Linux included.
Comment 5 Edvard 2018-01-29 16:30:00 UTC 
Dmitry - I just got my X1 back and checked my kernel config. CONFIG_RMI_F03 is not enabled. Would you want me to compile with it and see if that changes anything?
Comment 6 Edvard 2018-01-29 16:30:52 UTC 
However, CONFIG_RMI4_F03 is enabled. I'm assuming this is what you were referring to?
Comment 7 Edvard 2018-01-29 16:33:02 UTC 
./config-4.14.14-300.fc27.x86_64:CONFIG_RMI4_CORE=m
./config-4.14.14-300.fc27.x86_64:CONFIG_RMI4_I2C=m
./config-4.14.14-300.fc27.x86_64:CONFIG_RMI4_SPI=m
./config-4.14.14-300.fc27.x86_64:CONFIG_RMI4_SMB=m
./config-4.14.14-300.fc27.x86_64:CONFIG_RMI4_F03=y
./config-4.14.14-300.fc27.x86_64:CONFIG_RMI4_F03_SERIO=m
./config-4.14.14-300.fc27.x86_64:CONFIG_RMI4_2D_SENSOR=y
./config-4.14.14-300.fc27.x86_64:CONFIG_RMI4_F11=y
./config-4.14.14-300.fc27.x86_64:CONFIG_RMI4_F12=y
./config-4.14.14-300.fc27.x86_64:CONFIG_RMI4_F30=y
./config-4.14.14-300.fc27.x86_64:CONFIG_RMI4_F34=y
./config-4.14.14-300.fc27.x86_64:# CONFIG_RMI4_F54 is not set
./config-4.14.14-300.fc27.x86_64:CONFIG_RMI4_F55=y
Comment 9 Edvard 2018-01-31 08:14:43 UTC 
Dmitry, compiled the kernel with your supplied patches and now both trackpoint and touchpad works perfectly it seems! Awesome! Do you want any logs?
Comment 10 Edvard 2018-01-31 14:33:52 UTC 
However, resuming from hibernation renders the trackpoint unusable again. I will investigate the logs and see if I find any clues.
Comment 11 Edvard 2018-01-31 14:37:44 UTC 
Correction, just tried hibernation again and the trackpoint works. I'll report back later with more info.
Comment 12 Edvard 2018-02-01 21:09:21 UTC 
Quick update. When resuming from sleep or hibernation the trackpoint will quite often fail.

dmesg log here: https://gist.github.com/anonymous/db83bc75b58d41c3edba311a51fae950
Comment 13 Edvard 2018-02-16 21:41:45 UTC 
Quick update on this. I have not been able to figure out what causes the trackpoint to fail on resume but it seems to happen about 8/10 times. If it fails after resume I sometimes manage to get it back up again by suspending and resuming once more. 

I can't really see anything useful in the dmesg logs either but if anyone finds anything that would be great!
Comment 14 Edvard 2020-05-26 22:01:01 UTC 
This issue has been fixed and the Trackpoint now works just fine when resuming.
Comment 15 Alexander Schier 2022-02-06 18:25:09 UTC 
I have the same problem with Linux 5.13.0 after I got a replacement keyboard. The touchpad is still the same, still the buttons over the touchpad don't work. The hidden buttons under the touchpad work. The psmouse workaround works as well, but then the touchpad loses it's multitouch function, i.e., two-finger scrolling doesn't work anymore.
Comment 16 Alexander Schier 2022-02-06 18:26:41 UTC 
Linux 5.16.0-trunk (Debian) has the same problem.