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
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.
@Martin: This is most likely a separate issue as you seemingly have a completely different trackpoint in your machine.
Do you have CONFIG_RMI_F03 "RMI4 Function 03 (PS2 Guest)" enabled?
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.
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?
However, CONFIG_RMI4_F03 is enabled. I'm assuming this is what you were referring to?
./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
Martin, you issus is being handled here: https://bugzilla.kernel.org/show_bug.cgi?id=196929 Edvard: can you please try these 3 patches: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git/commit/?h=next&id=a1ab69021a584d952e6548a44b93760547b1b6b5 https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git/commit/?h=next&id=6abe534f0776d2437c8302f58d8eb5abd483e926 https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git/commit/?h=next&id=9f87b9fc369f7719ccdac5077855c5c03b625571
Dmitry, compiled the kernel with your supplied patches and now both trackpoint and touchpad works perfectly it seems! Awesome! Do you want any logs?
However, resuming from hibernation renders the trackpoint unusable again. I will investigate the logs and see if I find any clues.
Correction, just tried hibernation again and the trackpoint works. I'll report back later with more info.
Quick update. When resuming from sleep or hibernation the trackpoint will quite often fail. dmesg log here: https://gist.github.com/anonymous/db83bc75b58d41c3edba311a51fae950
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!
This issue has been fixed and the Trackpoint now works just fine when resuming.
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.
Linux 5.16.0-trunk (Debian) has the same problem.