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 21 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)
104 comments hidden view all 184 comments

Not sure if the patches are needed. I've updated my BIOS, trackpad and trackpoint firmware (using Windows 10), did a fresh Ubuntu 18.04.2 install, apt upgrade, restart, and now the trackpoint and trackpad work fine without any issues, even after all-night suspends, no dmesg errors/warnings. No changes in the blacklist or in the kernel boot params.

AaronMa (mapengyu) wrote :


That is expected.

Your touchpad/trackpoint is working in PS/2 mode in the latest touchpad/trackpoint firmware.
That's what I have explained for many times above.

Ah, true. Sorry :)

Thorsten (thorstenr-42) wrote :

i am now using 5.0.x with your patches and it is working great!

I am sorry, but what is going on?

The authors of some posts in this thread say that they are using a patched kernel. Yet, the developer, Aaron, seems to say one does not need patches . However, that same developer seems to say that his work has *not yet* become incorporated into the kernel. (Meanwhile I continue to try various combinations to get my touchpad to work after deep sleep and it still does not.)

If the patches *are* now incorporated into a version of the Linux kernel, then *which kernel version(s)* is/are at issue?

If the patches are *not* yet incorporated into a version of the Linux kernel, then - as I asked previously - how does one apply the patches? Can one do so without compiling the kernel oneself?

Thorsten (thorstenr-42) wrote :

@ALinuxUser: the patches are not yet upstream and thus one has to build a patched kernel yourself. You can follow the upstream process in the links posted from aaronma.

For some people it is working because they have a different touchpad. But according to the above discussion even the patches probably wont work for you :/

at your own risk!!!
For building a kernel you first have to install all dependencies, should be the following:
    apt-get install build-essential git wget kernel-package fakeroot dpkg-dev \
                libncurses5-dev libssl-dev ccache flex bison libelf-dev tzdata

then you need to git clone the kernel source:
    git clone --depth 1 --branch v5.0.1 git://

get the patches
    wget -O first.patch
    wget -O second.patch

apply the patches
    cd linux
    git apply ../first.patch
    git apply ../second.patch

clean the repo (just in case)
    make clean && make mrproper

copy the config of your current kernel
    sudo cp /boot/config-`uname -r` .

adjust the config
    yes '' | make oldconfig

and now compile it, can take a while
    make deb-pkg

at your own risk! you can then install the generated deb files

Aleksei Gusev (hron) wrote :

FYI, I've compiled the kernel using the instructions (thank you so much for them!) and it seems my laptop survived a night and touchpad works. I have Thinkpad X1 Yoga 3rd generation. It's mostly X1C6 as far as I know.

@Thorsten: thank you. I presume I could use the 5.0.0 kernel (you have '--branch v5.0.1') because I seemed to have some new trouble with the touchpad with 5.0.1.

Here is a datapoint.

System at issue: X1CG6 with NFC, with BIOS 1.37 and all firmware updated as much as possible (via both `fwupdmgr` and a WindowsLive external USB harddrive).

Method of attempted fix: using a patched vrsion of kernel 5.0.2; having the 'psmouse' value set as 1 in the boot string.

Time spent on trying to get sleep working on my very expensive laptop: I've lost track.

Did the fix work? No. After a long sleep, the touchpad was dead.

I could provide further details if necessary.

Using kernel 5.0.2 with the patches applied on X1C6 does not reliably fix the issue for me. The touchpad will always work after a suspend (it did so without the patches already), but the trackpoint and the 3 physical keys are still sometimes gone, and not responding, after suspend.

There might be something not yet covered by the patches.

Thanks everyone for your work on this issue.

While the definitive fix is in development, and I need to get on with my X1 Carbon Gen6, I found a practical workaround that makes the problem a lot less severe to me. In my case, the following steps mentioned here earlier, bring back touchpad keys and trackpoint 100% of the time:

echo -n "none" | sudo tee /sys/bus/serio/devices/serio1/drvctl
echo -n "reconnect" | sudo tee /sys/bus/serio/devices/serio1/drvctl

I saved this to a script in /usr/local/bin/, and defined a keyboard shortcut in Gnome to Windows Key + T that runs this script. If my laptop wakes up without the touchpad, it takes just a key combination to make it work again.

Sharing in case anyone else finds it useful too.

Christian Zosel (czosel) wrote :

@Jarek: Thank you for sharing the workaround, it also works for me 100% of the time!

I tried the 5.0.1 Kernel with the patches - in the beginning I was hopeful because the touchpad and trackpoint survived a few sleep/wakeup cycles, but starting from day 2 the issues returned (sometimes the touchpad didn't even work after rebooting). Now I'm back on the 4.15.0 where the Trackpoint survives maybe 2/3 of the sleeps and otherwise there's still the workaround above.

I tried Jarek's band-aids - a long time ago, admittedly - and they did not work on my machine.

Thorsten (thorstenr-42) wrote :

Hi, please make sure you have followed all the steps posted by AaronMa (#94):

1. ensure that the i2c-i801 is loaded! Ubuntu currently blacklists this module by default in /etc/modprobe.d/blacklist.conf - Thus, the patches won’t have any effect.
2. ensure that your touchpad AND trackpoint firmware is updated

1. Maybe something went wrong during your kernel build/patching. Try the kernel from AaronaMa in #94. Does the issue still occur?
1. AaronaMa has implemented the touchpad nosleep option as described in #133 and #155
you can activate it with echo 1 > /sys/devices/rmi4-00/nosleep but you have to do this after every boot.

If it is still not working, you have to provide logs like dmesg/journalctl. Moreover, try following the steps in #94



I loaded the kernel from #94, having set the BIOS to use S3 sleep and having removed that driver from the blacklist. Result: after a fairly long sleep (15 minutes, I think) the touchpad stopped working. I tried a workaround, with no success:

    # echo 1 > /sys/devices/rmi4-00/nosleep
    bash: /sys/devices/rmi4-00/nosleep: Permission denied

But perhaps I need still higher privileges for that command.

Touchpad and trackpad drivers: I have installed everything that `fwupdmgr`, and the Lenovo update utility (via a WindowsToGo install) offered me. What versions of what drivers do we need? (I note also that the WindowsToGo install showed no errors about the trackpad in the log, although admittedly I don't think I tried WindowsToGo when I had s3 enabled in the BIOS.)

Logs: `dmesg | grep pad` and `dmesg | grep point` show nothing relevant. `dmesg | grep sleep` yields this:

    [ 160.378036] ACPI: Preparing to enter system sleep state S3
    [ 160.567710] cache: parent cpu1 should not be sleeping
    [ 160.568369] cache: parent cpu2 should not be sleeping
    [ 160.569015] cache: parent cpu3 should not be sleeping
    [ 160.569727] cache: parent cpu4 should not be sleeping
    [ 160.570383] cache: parent cpu5 should not be sleeping
    [ 160.571041] cache: parent cpu6 should not be sleeping
    [ 160.571697] cache: parent cpu7 should not be sleeping
    [ 160.578374] ACPI: Waking up from system sleep state S3
    [ 160.915793] rmi4_f01 rmi4-00.fn01: f01 old_nosleep: 0.
    [ 180.058157] ACPI: Preparing to enter system sleep state S3
    [ 180.237233] cache: parent cpu1 should not be sleeping
    [ 180.237890] cache: parent cpu2 should not be sleeping
    [ 180.238560] cache: parent cpu3 should not be sleeping
    [ 180.239271] cache: parent cpu4 should not be sleeping
    [ 180.239930] cache: parent cpu5 should not be sleeping
    [ 180.240605] cache: parent cpu6 should not be sleeping
    [ 180.241280] cache: parent cpu7 should not be sleeping
    [ 180.247963] ACPI: Waking up from system sleep state S3
    [ 180.583836] rmi4_f01 rmi4-00.fn01: f01 old_nosleep: 1.

Other logs: coming up . .

For comment #160.

The file is the output of: journalctl -b 0 -k

For comment #160.


AaronMa (mapengyu) wrote :

my 2 patches are still pending in review status.

Anyone who still affected by touchpad issues after S3.
Please switch back to suspend-to-idle in BIOS if s2idle is supported.

ThinkPad Carbon 6th and Yoga 3rd do support suspend-to-idle in BIOS->config->power menu.

From 5.0 kernel power consumption of s2idle is less than 1w, pretty much like S3 0.6w.

Touchpad/Trackpoint should work normally in s2idle mode.

Thanks Aaron.

My X1CG6 does have no problems with the trackpad when I use S2idle sleep - well, except power consumption. Still: I did not know that, 'From 5.0 kernel power consumption of s2idle is less than 1w, pretty much like S3 0.6w.' On the other hand, that is a difference of some 30%. Perhaps the review of your patches by the kernel team will find a way of enabling the patch to work successfully upon a greater number of machines. Thank you for your work.

Henry Bigelow (hrbigelow) wrote :

Hi Aaron,

I did:

$ sudo dpkg -i linux-{image,headers}-4.20.0-rc3+_4.20.0-rc3+-6_amd64.deb

# edit /etc/default/grub so it now reads:
GRUB_CMDLINE_LINUX_DEFAULT="acpi_osi=! acpi_osi='Windows 2009' modprobe.blacklist=nouveau rmi_core.debug_flags=0x7"

$ sudo update-grub
$ sudo /sbin/shutdown now

# reboot into kernel 4.20
# touchpad now more responsive - it picks up lighter and faster touches as clicks.
# close lid to suspend. on first two wakeups, touchpad worked
# on third wakeup, touchpad didn't work. then:

$ cat /proc/interrupts | grep rmi > rmi_irq.log

# move finger around on touchpad for several seconds, even though mouse pointer didn't move

$ cat /proc/interrupts | grep rmi >> rmi_irq.log

# rmi_irq.log is empty

$ journalctl -b 0 -k > journalctl.log

# just for curiosity, close lid again, wait 10 seconds, reopen. Still, mousepad is unresponsive.
# Then, without warning, laptop goes into sleep mode (with lid still open. I press the button to resume. Screen blinks about five times, and finally wakes up. Now, mousepad works.

$ journalctl -b 0 -k > journalctl.after_blink.log

$ wc -l journalctl.*
  1735 journalctl.after_blink.log
  1586 journalctl.log

Have attached journalctl.after_blink.log

Thanks in advance for any information you could provide!

andrew (anoadragon453) wrote :

Any progress on getting this sent upstream or has it fallen by the wayside?

Thorsten (thorstenr-42) wrote :

any news? Is the patch submission ignored? This bug is still present in 5.1.6 :/ I am using your patch since you published it and it is working great, no issues at all.

AaronMa (mapengyu) wrote :


Synaptics engineer wants to take time to review it.
I had pong him again.

Hello all

Is the following relevant? 'Fixed an issue where there is an Incorrect Intel ME ICC settings after system resume from S3 or S4 states' - from the changelog of a Intel ME update for the X1CG6. Full changelog:

Thorsten (thorstenr-42) wrote :

Hi AaronaMa,

I‘ve seen that Dmitry Torokhov has some concerns about your patch and would like to try another way of fixing it. I just wanted to let you know that i am still here and able to test your patches :)

best regards

@alinuxuser: the issue is still present for me using the newest bios/firmware and kernel 5.1.14

Brad Figg (brad-figg) on 2019-07-24
tags: added: ubuntu-certified


Sorry, but what is it for a bug report to be ubuntu-certified?

I think this refers to the fact that this laptop (at lest one of its configurations) is ubuntu-certified.

Andrea Orru (andreaorru) wrote :

I can confirm that the problem is present on the 7th Generation X1 Carbon as well.

Andrea: It might be worth saying whether you have a model with the 'NFC' chip. (For - *I think*, and at least with the sixth generation - the following holds. Once one has Lenovo's BIOS updates applied, then only models with the NFC chip have the sleep/pad problem.

Andrea Orru (andreaorru) wrote :

I don't have the NFC chip.

With kernel 5.2.x, it happens always after hibernation, sometimes after suspension, rarely after reboot. I'm occasionally able to restore it by unloading/reloading the i2c_hid kernel module.

With kernel 4.19.61, the issue occurs sporadically, and I can always solve it by unloading/reloading the module.

ssss (sergeylarionov) wrote :

I have this issue on X1 Carbon gen 6, touchpad and trackpoint doesn't work after waking up from S3 suspend every time.

I have NFC chip. Reloading i2c_hid never helps.

Bios: 20KH006HRT 0.1.40, kernel: 5.2.9

Tetrix (porjazovskideni) wrote :

Any update on this issue?
I have Asus ROG model and I am experiencing the same issues with the touchpad.
After opening the lid, the touchpad starts lagging for couple of seconds and becomes disabled after that.
I am currently using the 5.3.1 kernel.
I can't use older kernels than 5.0 because in the earlier kernels there was another issue with the touchpad where it was randomly disconnecting.

I haven't tried the proposed patches by thinking that they will be incorporated in the newer kernel releases but nothing so far.

Kai-Heng Feng (kaihengfeng) wrote :

For the ASUS bug it should be fixed by this commit:
commit 6cb0880f08229360c6c57416de075aa96930be78
Author: Chris Chiu <email address hidden>
Date: Fri Aug 16 17:38:38 2019 +0800

    pinctrl: intel: remap the pin number to gpio offset for irq enabled pin

Thorsten (thorstenr-42) wrote :

but is there any update on this issue?

Tetrix (porjazovskideni) wrote :

Do we know when that change is going to be pushed to the official kernel?

Yousif Kelaita (ykelaita) wrote :

+1, happens to me running Ubuntu 18.04 LTS on an MSI GT70 0ND with a Synaptic touchpad.

Currently I just press Windows key, type touchpad, press enter, tab a few times to where touchpad is set to off, and press enter to turn it on. Happens every time I suspend/resume.

jnns (jnns) wrote :

Can someone summarize the current state of this? Is there anything affected users can do or provide to help fix this issue?

I'm on a Thinkpad X1 Carbon 6th Gen. (20KGS5DU00) with NFC touchpad. Running Ubuntu 19.04 with 5.0.0-31-generic kernel.

fwupdmgr shows no updates currently:
System Firmware is 0.1.41.
UEFI Device Firmware is 184.65.3590.
UEFI Device Firmware is also 0.1.17.

I use S3 sleep mode and when the laptop wakes up with a non-functioning touchpad I run the following command (which is mentioned in the entry post) a few times. If the touchpad doesn't come back to life I suspend again and repeat the cycle until it works.

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

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.

Displaying first 40 and last 40 comments. View all 184 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.