Touchpad and/or trackpoint stop working after S3 suspend on Lenovo X1 Carbon 6th

Bug #1791427 reported by dr_strangehate on 2018-09-08
This bug affects 28 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)

Bug Description

Ubuntu 18.04.1

Terminology in case we use different terms:
touchpad - just the rectangular touch-sensitive surface below the keyboard (xinput lists it as Synaptics TM3288-011)
trackpoint - the red thingy built into the keyboard + 3 physical buttons below the keyboard (trackpoint and buttons are integrated together; listed in xinput as TPPS/2 Elan TrackPoint)

On September 7th, 2018, Lenovo has issued a BIOS update (v1.30), which enables proper S3 deep sleep state - users no longer have to patch DSDT tables to get it. It can be enabled in the BIOS settings. In X1 carbon 6th generation models that have NFC, when laptop wakes from suspend by opening the lid, in most cases both touchpad and trackpoint stop working completely. They are also no longer listed when running xinput command. Sometimes just one of them stops working, usually the trackpoint. In some rare cases it is possible to bring them back by using these commands:

    echo -n none > /sys/devices/platform/i8042/serio1/drvctl
    echo -n reconnect > /sys/devices/platform/i8042/serio1/drvctl
    rmmod psmouse
    modprobe psmouse

These worked properly when waking up from S2Idle sleep state (had these in a script that runs after waking the machine from suspend), but with S3 deep sleep these rarely work and the only way to bring back touchpad and/or trackpoint is turning off the machine and turning it on (restart does not help).

I could not find any pattern that would show when the input devices stop working or start working again using the commands mentioned above. It's completely random from my perspective.

This is happening on the standard issue 4.15.0-33-generic kernel that shipped with my Ubuntu 18.04 (with updates), as well as with newer mainline kernels, such as the newest point versions of 4.17, 4.18 and 4.19 RC2.

This happens regardless of whether "blacklist i2c_i801" is commented out in /etc/modprobe.d/blacklist.conf or not. It happens regardless of whether "psmouse.synaptics_intertouch=1" is passed as grub parameter. Presence of TLP does not make it better, nor worse.

It appears that non-NFC models are not affected. I know at least one Arch Linux user who has the exact same model, but without this issue. I'm using synaptics driver (no libinput installed), he uses libinput and doesn't have synaptics, if that information is of any use. Libinput does not seem to help.

This forum thread also has more details from users who updated their BIOS to get S3 suspend:

Another related thread:

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: linux-image-4.15.0-33-generic 4.15.0-33.36
ProcVersionSignature: Ubuntu 4.15.0-33.36-generic 4.15.18
Uname: Linux 4.15.0-33-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.3
Architecture: amd64
 /dev/snd/pcmC0D0p: maciej 2651 F...m pulseaudio
 /dev/snd/controlC0: maciej 2651 F.... pulseaudio
CurrentDesktop: i3
Date: Sat Sep 8 13:45:43 2018
HibernationDevice: RESUME=UUID=3116dcb0-d91e-4b2a-8166-43b7a9a9d36e
InstallationDate: Installed on 2018-07-21 (49 days ago)
InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426)
 Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
 Bus 001 Device 003: ID 13d3:56b2 IMC Networks
 Bus 001 Device 002: ID 04b4:0060 Cypress Semiconductor Corp. Wireless optical mouse
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
MachineType: LENOVO 20KH006KPB
 1 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.15.0-33-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash psmouse.synaptics_intertouch=1 vt.handoff=1
 linux-restricted-modules-4.15.0-33-generic N/A
 linux-backports-modules-4.15.0-33-generic N/A
 linux-firmware 1.173.1
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install) 08/31/2018
dmi.bios.vendor: LENOVO
dmi.bios.version: N23ET55W (1.30 )
dmi.board.asset.tag: Not Available 20KH006KPB
dmi.board.vendor: LENOVO
dmi.board.version: SDK0J40697 WIN
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: None
dmi.modalias: dmi:bvnLENOVO:bvrN23ET55W(1.30):bd08/31/2018:svnLENOVO:pn20KH006KPB:pvrThinkPadX1Carbon6th:rvnLENOVO:rn20KH006KPB:rvrSDK0J40697WIN:cvnLENOVO:ct10:cvrNone: ThinkPad X1 Carbon 6th 20KH006KPB
dmi.product.version: ThinkPad X1 Carbon 6th
dmi.sys.vendor: LENOVO

dr_strangehate (dr-strangehate) wrote :

This change was made by a bot.

Changed in linux (Ubuntu):
status: New → Confirmed
Thorsten (thorstenr-42) wrote :

Hi, for me the following combination for ubuntu 18.04 using x1c6 with nfc (20KG) seems to be working:

- touchpad and trackpoint both enabled in bios
- nfc disabled in bios (because i dont need it, dont know if it would work)
- linux (s3) sleep in bios
- upgrading to the newest kernel, i am using 4.18.7 from
- removing the blacklisting of i2c_i801 by commenting the line blacklist i2c_i801 in /etc/modprobe.d/blacklist.conf
- enabling the tlp settings in /etc/default/tlp to:


    (source anx1 in, for me the following combination for ubuntu 18.04 using x1c6 with nfc (20KG) seems to be working:

- touchpad and trackpoint both enabled in bios
- nfc disabled in bios (because i dont need it, dont know if it would work)
- linux (s3) sleep in bios
- upgrading to the newest kernel, i am using 4.18.7 from
- removing the blacklisting of i2c_i801 by commenting the line blacklist i2c_i801 in /etc/modprobe.d/blacklist.conf
- enabling the tlp settings in /etc/default/tlp to:


    (source anx1 in )
- upgrading libinput to 1.11.3, by manually downloading libinput10_1.11.3-1_amd64.deb libinput-bin_1.11.3-1_amd64.deb from cosmic (ubuntu 18.10) and installing with sudo dpkg -i libinput10_1.11.3-1_amd64.deb libinput-bin_1.11.3-1_amd64.deb (This one is scary but upgrading didnt break any dependencies... atleast for me). This should at least fix

upgrading libinput was the most important part and other steps maybe can be omited. However, without the tlp settings the trackpoint (sometimes) doesnt survive suspend.)
- upgrading libinput to 1.11.3, by manually downloading libinput10_1.11.3-1_amd64.deb libinput-bin_1.11.3-1_amd64.deb from cosmic (ubuntu 18.10) and installing with sudo dpkg -i libinput10_1.11.3-1_amd64.deb libinput-bin_1.11.3-1_amd64.deb (This one is scary but upgrading didnt break any dependencies... atleast for me). This should at least fix

upgrading libinput was the most important part and other steps maybe can be omitted. However, without the tlp settings the trackpoint (sometimes) doesnt survive suspend.

Thorsten (thorstenr-42) wrote :

a small update: the tlp settings have no effect and are thus not necessary... Even with the settings the trackpoint is sometimes not working after resume. However, an additional suspend/resume does activate the trackpoint again!

So removing the blacklist of i2c_i801 (which is a critical bug: #1786574 ), upgrading libinput and probably updating the kernel to 4.18.x were the important steps for me.

AaronMa (mapengyu) wrote :

Thanks for the detail test.

I have another X1 Carbon 6th, but it cann't reproduce your issue.

Could you isolate which change solve this issue?
1, suspend/resume;
2, kernel update;
3, libinput update.

My X1 Carbon's PnP ID is the same as yours, so I think we have the same touchpad.
But the product ID is not the same.

dr_strangehate (dr-strangehate) wrote :

AaronMa, does your model have NFC? You can tell by a symbol printed on the touchpad just below the middle physical button of the trackpoint, looks like this one:

I'm now on kernel 4.18.7 and that does not help in any way. I also tried installing the libinput driver, but that didn't help either - the touchpad survived a few suspends, but always fails longer suspends, like when I leave it for the night.

Thorsten (thorstenr-42) wrote :

Hi, i did a complete new installation with the ubuntu 18.04.1 iso and the touchpad was always working after suspend/resume only the trackpoints gets lost. Does it make a difference if s3 is available during installation?

The only modification i had to do was to remove the blacklist of i2c_i801 in /etc/modprobe.d/blacklist.conf otherwise my touchpad and the trackpoint are only working
sporadically and dmesg is full of:
[ 28.588451] psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1
[ 28.589633] psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1
[ 28.590844] psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1
[ 28.600959] psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1
[ 28.602151] psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1
[ 28.602153] psmouse serio1: issuing reconnect request
[ 29.327513] psmouse serio1: synaptics: queried max coordinates: x [..5678], y [..4758]
[ 29.359677] psmouse serio1: synaptics: queried min coordinates: x [1266..], y [1094..]
[ 29.812077] psmouse serio2: Failed to reset mouse on synaptics-pt/serio0
[ 35.040078] input: PS/2 Generic Mouse as /devices/platform/i8042/serio1/serio2/input/input20
[ 35.303431] psmouse serio2: Failed to enable mouse on synaptics-pt/serio0

1. remaining issue: tap to click is not working -> fixed by upgrading libinput

2. remaining issue: my trackpoint sometimes does not survive suspend. After an subsequent suspend/resume, it is added again and is useable again. In dmesg i can see that the kernel is adding it:
    [ 8292.603632] PM: suspend exit
    [ 8292.696364] psmouse serio2: trackpoint: Elan TrackPoint firmware: 0x04, buttons: 3/3
    [ 8292.734688] input: TPPS/2 Elan TrackPoint as /devices/rmi4-00/rmi4-00.fn03/serio2/input/input19

The full dmesg is appended. I don't use the trackpoint so that is not a real issue for me.

Changed in linux (Ubuntu):
importance: Undecided → Medium
status: Confirmed → Triaged
tags: added: kernel-da-key

I am on Mint 19 with kernel 20KHCTO1WW on a X1 model 20KHCTO1WW. I would be happy to contribute to any necessary testing. I use the synaptic touchpad driver.

Hua Zhang (zhhuabj) wrote :

I also hit this problem in my x220t + ubuntu 18.04, I successfully fix it by using the following workaround:

org.gnome.desktop.peripherals.touchpad click-method disabled

@Hua Zhang

Thanks. On Mint Cinnamon - which doesn't use the Gnome Desktop Environment - I find that, in Dconf editor, there is no 'disabled' option. (Perhaps you were using a terminal rather than the GUI?) However, there was a 'none' option. Selecting it . . made no difference to the problem. Note that, at least on my system, the problem occurs only after a fairly long (>10 minutes?) period of sleep. Still, I did not try to combine this ostensible fix with any of the many others that are floating around.

Note also this irony: after this webpage has 'slept' - been inactive for a while - trying to post a comment generates this error: (<Bug at 0x7f2b2a450550>, 'newMessage', 'launchpad.Edit'). Well, unless the problem was caused by my pinning the tab in Firefox.

Here's some more dmesg output that I get after the first or second suspend (sometimes third, it's very random). Once I get this, it's impossible to reconnect the trackpad and trackpoint by any means:

[46946.446180] ACPI: Waking up from system sleep state S3
[46946.462033] thinkpad_acpi: unknown possible thermal alarm or keyboard event received
[46946.462035] thinkpad_acpi: unhandled HKEY event 0x6032
[46946.462035] thinkpad_acpi: please report the conditions when this event happened to <email address hidden>
[46946.463425] ACPI: EC: interrupt unblocked
[46946.532283] ACPI: EC: event unblocked
[46946.552921] psmouse serio1: Failed to deactivate mouse on isa0060/serio1
[46946.752420] [drm] Reducing the compressed framebuffer size. This may lead to less power savings than a non-reduced-size. Try to increase stolen memory size if available in BIOS.
[46946.768668] usb 1-8: reset high-speed USB device number 2 using xhci_hcd
[46946.924754] restoring control 00000000-0000-0000-0000-000000000101/10/5
[46946.924756] restoring control 00000000-0000-0000-0000-000000000101/12/11
[46946.960296] rmi4_smbus 0-002c: failed to get SMBus version number!
[46947.004067] rmi4_physical rmi4-02: rmi_driver_reset_handler: Failed to read current IRQ mask.
[46947.047764] rmi4_f01 rmi4-02.fn01: Failed to restore normal operation: -6.
[46947.047767] rmi4_f01 rmi4-02.fn01: Resume failed with code -6.
[46947.047770] rmi4_physical rmi4-02: Failed to suspend functions: -6
[46947.047773] rmi4_smbus 0-002c: Failed to resume device: -6
[46947.048722] OOM killer enabled.
[46947.048723] Restarting tasks ...
[46947.051953] [drm] RC6 on
[46947.061098] done.
[46947.091346] rmi4_f03 rmi4-02.fn03: rmi_f03_pt_write: Failed to write to F03 TX register (-6).
[46947.091878] thermal thermal_zone6: failed to read out thermal zone (-61)
[46947.127785] PM: suspend exit
[46947.135052] rmi4_physical rmi4-02: rmi_driver_clear_irq_bits: Failed to change enabled interrupts!
[46947.234944] e1000e: enp0s31f6 NIC Link is Down
[46947.237124] IPv6: ADDRCONF(NETDEV_UP): enp0s31f6: link is not ready
[46947.266072] rmi4_physical rmi4-02: rmi_driver_set_irq_bits: Failed to change enabled interrupts!
[46947.266088] psmouse: probe of serio4 failed with error -1

tags: added: kernel-bug-exists-upstream


Sorry if this is an obtuse question, but you are saying that this problem owes to a bug in the Linux kernel?


That is my understanding - the driver itself works (both synaptics and libinput, we can use the devices after turning on the laptop), but the kernel is not handling the suspend and wakeup for these devices properly. That being said, I am far from being an expert, so I can be wrong. In which case I will remove that tag, please let me know.


Thanks. I am no expert either. It seems to me that the problem could owe either to Lenovo's hardware, or to the kernel, or to Ubuntu, or to Debian. Complicating matters, if Lenovo's driver is buggy then it is the kernel's job to compensate for that, I suppose. If the bug should be reported to the kernel, the questions arise: has it been and, if it has not been, who is going to do it? I myself have no experience reporting bugs to/for the kernel itself.

This same thing happens to all distros - I've seen a bug report like this on Redhat's bug tracker (Fedora), and tried other distros, such as Manjaro. So it's not just Debian or Ubuntu I guess. I assume developers that take care of individual distros can make changes to the kernel and then send them up to the mainline version to be available for everyone. It's just that nobody cares enough, since it's not a super popular model I guess.

Robert Riemann (rriemann) wrote :

For reference, this is the link to the Redhat/Fedora bug: (no solution there as for now)

Has anyone filed a bug for the kernel so far?


As I said, I've no experience of filing kernel bugs. I have no filed one about this.

Is the patch described on the following webpage - a patch has arrived on my system - relevant?

It looks like it is not, but I am unsure (and don't fancy doing a load of testing if it is not).

To answer my own question: that update removed a blacklisting in blacklist.conf. The result of that removal, on my system, was that the touchpad stopped working after suspend, even when S3 was not enabled. A few hacks get the touchpad working again, but not properly - edge-scrolling, and I suspect some other functions, are lost.

AaronMa (mapengyu) wrote :

Root cause should be broke communication via PS/2 bus.

Current touchpad with smbus support still needs PS/2 commands to confirm the info and capabilities.

This bug had been reported to Lenovo, waiting for fw update to fix this issue.

That is informative. Thank you. However: Lenovo support tends to be
clueless with Linux, so finding out from Lenovo when this fix will ever
appear is hard. Might you or someone else be able to advise on that?

AaronMa (mapengyu) wrote :

Hi all:

Got response from Lenovo, they suggest user to update touchpad fw to fix this issue.

Release Note:
(Fix) Trackpoint FW update will fail on systems with NFC model

Quick test on X1C6, PS/2 works(with psmouse.synaptics_intertouch=0).
20 times S3 resume, touchpad works fine.

That release note is so poorly written that I thought it meant: this update will not install on computers with the NFC model. Still, after a while I released that this update is meant to *fix* that problem with Linux. Hurrah!

Yet, it looks as though this update will install . . only on Windows. For, it is an 'exe'. Moreveover, the release notes say: 'The UltraNav driver needs to be installed to install this firmware.' That may mean that a Windows PreBoot Environment - which I use for installing Windows-only stuff Lenovo provides - will be unable to install the update. We will see.

The install does has the aforementioned prerequisite, namely the Synaptics 'ultraNav' driver-cum-firmware.

Both installers at issue merely install firmware updates that the installers then prompt one to run, having told the user that the installation is finished; it is pretty confusing.

I managed to get the fix installed, via the Pre-Boot environment, by: installing the prerequisite firmware and driver; rebooting; installing the prerequisite *again*; installing the fix (without rebooting).

How poorly Lenovo treats its Linux users (and it does not design UIs well either).

I hope that the Linux firmware updater (fwupdmrg) will get this update. However, thus far that service does not offer updates to touchpad stuff.

I shall now enable S3 sleep and see whether the fix actually works.

First results: a recent update from Debian removed (on my Mint system) a blacklisting in blacklist.conf for '12c_i801'. I find that, unless I reactivate that blacklisting, touchpad edge scrolling does not work - from boot and before any sleep. So that is a problem that this update from Lenovo (presuming it installed properly) does not fix.

Next, more important result: no, *the touchpad still doesn't work* after (a fairly long) suspend.

AaronMa (mapengyu) wrote :

Could you confirm the following info?

1, On Windows, use cmd tool; cd touchpadfw ; SynReflash.exe /Q; wait for 1 min. until it show version info and then check "FW Version: 1.3".
If it is 1.3, then you have upgraded fw successfully.

2, If not 1.3, please update fw again; use cmd tool; synreflash.exe /f 1 /s 1 /y /i "filename";
TM3289: PRxxx-TM3289-XXX.img
TM3288: PRxxx-TM3288-XXX.img

3, on Linux, Boot with kernel cmd "psmouse.synaptics_intertouch=0". please confirm touchpad works well on PS/2 mode
check $ dmesg |grep serio
touchpad should be shown on PS/2 mode.

After touchpad fw update, touchpad should work on both PS/2 mode and smbus mode on Linux.

Thanks. It was hard even to run 'SynReflash.exe /Q': I had to install a touchpad driver/update, or two and then locate the relevant folder. (All this on a Windows PreBoot Environment. I tried to use a WindowsToGo installation, but after hours of creation and booting it errored out. When the command did run, it showed 'version 0.0' (*sic*).

Next I tried to follow your instructions for the next command - instructions that, frankly, could have been clearer. Am I meant to put a semicolon in the command? Quotes? How to interpret your linebreak? Do I install both those img files? I settled upon:

synreflash.exe /f 1 /s 1 /y /i PR2698617-TM3289-021_1128.img

which produced a window entitled 'Reflash failed' and containing the text: 'Error code(0x0)' (*sic*).

So I tried the same command, but with the other .img file in the folder. So doing generated the same error code.

Then I tried to enter your command literally, including the quote marks, but the Pre-Boot Environment had quotes mapped to the wrong key, and I couldn't find the right key, and the Start Button Search . . cannot find anything.
Then - why not? - I ran the .bat file in the same folder. Result: the same error code.

I wasted a (further) day trying to install this stuff in a way I should not even have to, namely via WindowsToGo, which doesn't work properly, at least on my hardware. (I tried three USB sticks, multiple burners, endured endless Windows setup screens and hangs.) And the fixes did not work anyway. Or perhaps they did not install in the first place - it was hard to tell.

So, I've decided to check the new firmware. I installed Windows 10 (wiping out my Ubuntu install in the process), installed Lenovo Vantage and installed all firmware updates that it allowed me to, including touchpad and trackpoint firmware.

Then I installed fresh new Ubuntu 18.04.1. One good thing is that the installer allowed me to use touchpad and trackpoint properly (they did not work the last time I was running the installer, had to use external mouse).

Unfortunately, longer suspend (like through the night) still kills touchpad and/or trackpoint. And even the "none"/"reconnect" trick doe snot bring them back, neither does rmmod and modprobe on psmouse (module (which used to be a working solution at some point when S3 did not work).

AaronMa (mapengyu) wrote :

@dr_strangehate, thanks for test details.

I will report this feedback to Lenovo.

mr_tron (tr0n) wrote :

I have same bug on thinkpad t440s.
And that fix works for me:
# /etc/systemd/system/touchpad-sleep.service
# restore touchpad on suspend

Description=Restore Touchpad on suspend

ExecStart=/bin/bash -c 'echo "0000:00:1f.4" > /sys/bus/pci/drivers/i801_smbus/unbind'
ExecStop=/bin/bash -c 'echo "0000:00:1f.4" > /sys/bus/pci/drivers/i801_smbus/bind'



Thanks, but (1) I am hesitant to try yet another work-around, at least without knowing whether you have the NFC model. (2) Where did you get those echo values, please? Might they differ system to system? (If this works, though, then I will be most pleased, though it won't mean Lenovo doesn't have a bug to fix.)

The above fix has a chance of working only if one's blacklisf.conf (/etc/modprobe.d/blacklist.conf, on my Linux Mint system) does *not* to blacklist 'i2c_i801'. Debian did recently remove that blacklisting.

mr_tron (tr0n) wrote :


I got this script on archlinux forum. I changed their value 0000:00:1f.4 to my 0000:00:1f.3.

# ls /sys/bus/pci/drivers/i801_smbus/
0000:00:1f.3 bind module new_id remove_id uevent unbind

Also i have nfc, but i don`t is it realy work.

Thanks for that. The ls reveals 1f.*4* on my system, but using that in the file does *not* work for my system, at least not after a long sleep.

*Is any kernel switch (aka grub boot string) required for this*?

*WHERE on the Arch forum did you get this workaround? And was it really a forum rather than the ArchWiki?*

Bryan Quigley (bryanquigley) wrote :

Try this:
1. Edit /etc/gdm3/custom.conf as root/with sudo
2. Uncomment the line WaylandEnable=false so it looks like below:
# Uncoment the line below to force the login screen to use Xorg
3. Reboot and see if the issue still occurs.

C'mon guys, this stuff is hopeless. As I said, I'm using Linux Mint. It lacks the /etc/gdm3 folder - perhaps because (I don't know) it uses a different 'greeter'. Nor does Mint use Wayland.

Changed in linux (Ubuntu):
assignee: nobody → AaronMa (mapengyu)
Brad Figg (brad-figg) on 2019-07-24
tags: added: ubuntu-certified
141 comments hidden view all 221 comments

I don't know what is the state of the fix in the kernel, but what you can do is update your touchpad/trackpoint firmware under Windows (unfortunately it's not supported in fwupdmgr), which fixes the issue completely for Linux, at least it did in my X1 Gen6 and a few others I know.

> what you can do is update your touchpad/trackpoint firmware under Windows (unfortunately it's not supported in fwupdmgr), which fixes the issue completely for Linux, at least it did in my X1 Gen6 and a few others I know.

Suppose that is true. Then it merits a response of 'for goodness sake!' to Lenovo and/or to the fwupd people.

Suppose alternatively the quoted claim is false (which I can well believe). In that case, a 'for goodness sake!' is in order in the direction of those who say the problem is fixed when it isn't. This problem has persisted through various attempted fixes and workarounds for certain users; let's not claim the problem can be banished for all people until we are sure about that. dr_strangehate: are you sure? You might say: those still affected after the Windows-only-update have (truly) defective hardware. Have we really verified such a claim, though?

I'm just a user. I can only say it worked for me and all the people I asked and who listened, which was very few. So I cannot give you any guarantees if that is what you want :). Most people don't want to try it because it's either too much hassle (windows install) or think that for some reason an update through windows will break the laptop.



I keep a Windows-to-Go drive around for just this sort of nonsense. I haven't run it for months. Running it now, and running the Lenovo update program, the only firmware update that I see (as against Windows software updates) is for Intel ME. So I suspect the following. I have the firmware update that you had in mind installed *already* (installed earlier via the same method) and it does not fix the problem for me.

jnns (jnns) wrote :

What is the most effortless way of running the Windows firmware updates on a Linux machine? Are there live CD images I could use for this?

Pavel (pablobablo) wrote :

Hi guys! I've change BIOS settings bellow and the bug disappear.

BIOS > Config > USB > Always on USB > Enabled > Charge in Battery mode > Enabled


That sounds helpful. However, I'm going to need some reassurance before I change all my settings. ('All' because I seem to remember that I have to change more than the BIOS sleep mode to get the system to use S3. I think I have to unblacklist some module and change some kernel boot parameter.) So: really? Are you sure? Also: do you have that bloomin' NFC thing? Thanks.

ssss (sergeylarionov) wrote :

@pavel just tried it on the model with NFC and it didn't help or change anything. (20KH006HRT)

Pavel (pablobablo) wrote :

I was happy early because the bug appeared again :(

Thorsten (thorstenr-42) wrote :

The touchpad problem seems to be solved (for me) using linux 5.3. The trackpoint sometimes still dies but the touchpad keeps working. Luckily, i don't care about the trackpoint...

I was using mainline 5.3 since 4 weeks on ubuntu 19.04 and i am now using 19.10 (uses 5.3 by default) since a week and the touchpad has survived every suspend since using 5.3. For comparison, using linux 5.2 without the patches from Aaron and the touchpad dies within ~5 suspends.

It is a pity that there was no more answers from Aaron here lately and all the work was in vain and the problem was probably solved in other ways. But at least it is (probably) solved.

People claim repeatedly that the problem is fixed when it is not. I will believe it only when I see it and indeed I will test it only with further reason to believe it. Sad, but reasonable.

ssss (sergeylarionov) wrote :

I'm on 5.3 and it doesn't work:

`Linux larionov-arch 5.3.7-arch1-2-ARCH #1 SMP PREEMPT @1572002934 x86_64 GNU/Linux`

Tetrix (porjazovskideni) wrote :

Same here, I have Ubuntu with 5.3.11 kernel and the issue is still there

Thorsten (thorstenr-42) wrote :

I do not just claim that, I am just sharing what helped me... With older kernels my touchpad hardly survived 5 suspends. With 5.3 it just works (4 weeks without a dead touchpad with at least 50 suspends). Okay the trackpoint issue is still there but i give a ...

Before that I had to build my own kernels with the patches from Aaron. If these patches didn't help you, then maybe 5.3 won't help you either. Most likely this problem has several causes (firmware/bios/different touchpad types etc...) and therefore a solution might only help some people.

I could make a kernel bisect and find out which commit finally helped me. But as long as nobody keeps working on the patches, that would be a waste of my time.

For me the problem is finally solved and I don't have to build a manually patched kernel every few weeks anymore... so i am out here. But my next laptop will not be a lenovo anymore.

Pavel (pablobablo) wrote :

How to reproduce this bug on Lenovo X1 Carbon 6th

Step 1.
sudo systemctl suspend

Step 2.
Wait 10 sec.

Step 3.
Quickly press the key combination FN+CTRL+Z twice.

ssss (sergeylarionov) wrote :

@thorsten Do you have a model with NFC?

Kai-Heng Feng (kaihengfeng) wrote :

Does the nosleep workaround work for everyone?

Thorsten (thorstenr-42) wrote :

@sssss: Yes, I have a model with nfc typ: 20KGS03900

@Kai-Heng Fen: I didn’t need the nosleep workaround (second patch). The first patch from Aaron ( was sufficient. (The nosleep option has only been necessary for the kernels provided by Aaron which were based on an early rc. All final kernels worked fine with the first patch.)

I don't think anyone but me has built kernels with these patches. You probably would have to build/provide them if you want more feedback.

Jeroen (jeronimo-92) wrote :

@thorstenr-42: Also have a nfc model so still facing the same dead touchpad issues.
I've never built a custom kernel before, just loaded a kernel module for a wifi nic that didn't have drivers in the kernel. How do you go about building and running this?

Also I'm wondering what would be necessary, or what I can do, to finally get these patches upstream?

Pavel (pablobablo) wrote :

Guys, try to set sleep state from Linux to Windows in BIOS settings. It seems worked for me.

Yes, but now your battery will die in like 4 hours in sleep mode, because you're not getting S3 mode.

jnns (jnns) wrote :

@thorstenr-42: Very good to hear that it works for you since kernel 5.3! Could you tell us whether you have a certain configuration in the following files?

- /etc/default/grub (kernel parameters for psmouse?)
- /etc/modprobe.d/psmouse.conf
- /etc/modprobe.d/blacklist.conf (i2c_801 blacklisted or not?)
- BIOS: trackpoint (de-)activated? Or something else that might be related?

jnns (jnns) wrote :

My X1 Carbon 6 Gen still suffers from the problem, no doubt about it. I'm currently using Linux 5.3.0-24-generic.
But I was able to migitate the rate of occurence by a large degree using the following configuration. Please not that I have no idea if anything of this is actually relevant or just me being a superstitious pidgeon. Hope it helps someone.

cat /etc/modprobe.d/blacklist.conf | grep i2c_i801
# blacklist i2c_i801

cat /etc/modprobe.d/psmouse.conf
options psmouse synaptics_intertouch=1

cat /lib/systemd/system-sleep/fixtouchpad

if [ "$1" = "post" ]; then
    printf 'Reconnecting touchpad/trackpoint...' | systemd-cat -t '/lib/systemd/system-sleep/fixtouchpad'
    echo -n none > /sys/devices/platform/i8042/serio1/drvctl
    sleep 1
    echo -n reconnect > /sys/devices/platform/i8042/serio1/drvctl
exit 0

cat /etc/default/tlp | grep SUSPEND


I appreciate the sentiment but (1) that is a workaround whereas a fix is needed, (2) some (most?) of us here have tried all the fixes, including the ones you mention, and to no avail.

Linus Su (linsu482) wrote :

Hi guys, I also suffer from this problem on my X1 6th gen on Ubuntu as well as Fedora.

Looks like there was a change made in Kernel 5.5 addressing the issue (see the last sentence in the commit message, "With this change I can read out the touchpad data correctly on my
Lenovo X1 Carbon 6th Gen laptop"):

Generally speaking, there are a lot of changes in the rmi4 driver since April 2019 or Kernel 5.1 (see Unfortunately I'm still having this problem on Kernel 5.3 so I was hoping 5.4 would improve the situation. I guess we'll have to try 5.5 then!

I'm having this issue with my Lenovo x240 , running ubuntu 19.10 with kernel 5.3.0-26-generic

even worse it didn't detect/worked since booting up my laptop. removing from modprobe and adding it back still did not work :(

attached devices , xinput and Xorg log

ssss (sergeylarionov) wrote :

I just did a little experiment and I think now I have trackpad waking up after s3 sleep:

I have 20KH006HRT - Thinkpad Carbon X1 6th Gen with NFC chip, and since I first set it up according to arch wiki I had trackpad not working every time I close and open the lid.
Tried all sugestions, nothing changed anything, and as a last resort I wanted to reinstall everything clean. So what I did was I went to the bios and restored to the factory settings, then I installed windows 10, downloaded lenovo drivers, installed all updates including firmware (it only had ssd firmware to update because I managed to update everything with fwupdmgr before), then I installed latest arch and turns out the trackpad now is keep working after going to sleep!

I figured windows didn't help much because I already had the updates, so I looked into the BIOS configurations changes and turns out that when I disable Fingerprint reader in bios Security tab I/O settings - the trackpad stops working again, so that must be the problem.

I'm attaching the bios configuration that works for me

ssss (sergeylarionov) wrote :

Here is another screenshot that shows that I have Linux sleep enabled.

My kernel is:
Linux larionov-arch 5.4.6-arch3-1 #1 SMP PREEMPT Tue, 24 Dec 2019 04:36:53 +0000 x86_64 GNU/Linux

Hope this helps somebody!


Thank you for the detailed attempt to help.

On my 20KHCTO1WW, with kernel 5.6.19-050619-generic, BIOS 1.49, and the latest updates delivered by fwup, I enabled the fingerprint reader and enabled S3 sleep. I did those things in the BIOS. Then I put the computer to sleep for ten minutes or so. Then I woke it. The trackpoint *still* did not work.

Elvis Stansvik (elvstone) wrote :

Anyone know what happened to Aaron's patch? The discussion at ends on November last year with this question from Kai-Heng:

> Users reported that patch [1/2] alone can solve the issue.
> Do we need more information before making this fix merged?
> Kai-Heng

Would be really great if it could be merged :(

Anyone tried a very recent kernel and can confirm the issue is still there BTW?

'Anyone tried a very recent kernel and can confirm the issue is still there [..]?' I tried 5.6.19, I think it was (so, moderately recently) and I can confirm the problem is there. Also, I've looked at the release notes for various 5.7 kernels and not seen a sign of the patch.

Kai-Heng Feng (kaihengfeng) wrote :

Can someone attach dmesg when it uses S2Idle and when it uses S3?


Do you need those two desmgs from one and the same machine? I will not provide that, because I have had enough of rebooting my non-working machine when I enable S3. I am happy to attach a S2Idle log, though.

Kai-Heng Feng (kaihengfeng) wrote :

Yea they need to come from the same system.
I guess just stick to s2idle then.

Changed in linux (Ubuntu):
status: Triaged → Incomplete


Please be clear. I take it that by your last post you mean this: I should stick to s2idle in the sense, not of (i) sending you only the log for that, but in the sense of (ii) not contributing to the fix. However: will someone who uploads both logs here be contributing to the fix? Subordinate questions: (1) you are a kernel engineer, yes? (2) is there much of a prospect of this bug ever being fixed? Thank you for your time.

plum (plumerlis) wrote :

any news on the patch?
I still have this issue

boehlen (boehlen) wrote :

The problem is still there for me too. Quite often the track point is dead after wake up from sleep (there is never a problem with the track pad) and I have to fix the track point with
echo -n "none" | sudo tee /sys/bus/serio/devices/serio1/drvctl
echo -n "reconnect" | sudo tee /sys/bus/serio/devices/serio1/drvctl
The problem has been around for a couple of years and is quite annoying.

Somewhere in this long thread, I think, an engineer suggested the following.

Somehow, in my particular case - a case in which, on my ThinkPad X1CG6, no work-arounds worked and neither did the test version of the kernel patch - my motherboard was at fault.

Well, the engineer was right. For, I got my motherboard changed - for another reason - and 'deep sleep' now works properly.

Now, as it turns out - and the engineer who changed the motherboard did not tell me this - the new motherboard has a different model number to the old one. So either Lenovo has fixed the problem with a new version of the motherboard. Or else my old motherboard had an idiosyncratic fault.

By the way, did the kernel patch for the problem ever get merged?

Displaying first 40 and last 40 comments. View all 221 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.