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

This change was made by a bot.

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 http://kernel.ubuntu.com/~kernel-ppa/mainline/
- 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:

        USB_AUTOSUSPEND_DISABLE_ON_SHUTDOWN=1
        USB_AUTOSUSPEND=0
        RUNTIME_PM_BLACKLIST="00:1f.4"

    (source anx1 in https://forums.lenovo.com/t5/Linux-Discussion/X1-Carbon-Gen-6-cannot-enter-deep-sleep-S3-state-aka-Suspend-to/m-p/4200223/highlight/true#M11685Hi, 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 http://kernel.ubuntu.com/~kernel-ppa/mainline/
- 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:

        USB_AUTOSUSPEND_DISABLE_ON_SHUTDOWN=1
        USB_AUTOSUSPEND=0
        RUNTIME_PM_BLACKLIST="00:1f.4"

    (source anx1 in https://forums.lenovo.com/t5/Linux-Discussion/X1-Carbon-Gen-6-cannot-enter-deep-sleep-S3-state-aka-Suspend-to/m-p/4200223/highlight/true#M11685 )
- 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) https://launchpad.net/ubuntu/+source/libinput 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 https://gitlab.freedesktop.org/libinput/libinput/issues/46

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) https://launchpad.net/ubuntu/+source/libinput 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 https://gitlab.freedesktop.org/libinput/libinput/issues/46

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.

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.

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.

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: https://i.redd.it/el9qai4evu811.jpg

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.

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.

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.

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

@dr-strangehate

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

@NJ

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.

@dr-strangehate

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.

For reference, this is the link to the Redhat/Fedora bug: https://bugzilla.redhat.com/show_bug.cgi?id=1442699 (no solution there as for now)

Has anyone filed a bug for the kernel so far?

@rriemann

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?

https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1797322

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.

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?

Hi all:

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

https://pcsupport.lenovo.com/us/en/products/laptops-and-netbooks/thinkpad-x-series-laptops/thinkpad-x1-carbon-6th-gen-type-20kh-20kg/downloads/ds505032

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.

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";
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.

Cf. perhaps the following.

https://forums.lenovo.com/t5/ThinkPad-T400-T500-and-newer-T/Synaptic-Firmware-updater-throwing-an-exception-and-not-updating/td-p/1693373

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).

@dr_strangehate, thanks for test details.

I will report this feedback to Lenovo.

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

[Unit]
Description=Restore Touchpad on suspend
Before=sleep.target
StopWhenUnneeded=yes

[Service]
#Type=oneshot
Type=idle
RemainAfterExit=yes
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'

[Install]
WantedBy=sleep.target
```

mr_tron

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.

ALinuxUser

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?*

Try this:
1. Edit /etc/gdm3/custom.conf as root/with sudo
2. Uncomment the line WaylandEnable=false so it looks like below:
[daemon]
# Uncoment the line below to force the login screen to use Xorg
WaylandEnable=false
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.

Hi, I also have the 0000:00:1f.4 and the nfc model (20KG-S03900) and I don’t have this issue. Even my trackpoint now survives resumes/suspends since using 4.19.1 and upgrading all firmware (using windows) (touchpad/trackpoint/bios/thunderbolt).

I can just repeat the steps, which where necessary for me on ubuntu 18.04.1:

1. Removing the blacklisting of i2c_i801 in /etc/modprobe but this is now default in ubuntu 18.04 (see: https://bugs.launchpad.net/hwe-next/+bug/1786574 )
2. Installing a newer kernel from mainline ppa: currently using 4.19.2
3. Using libinuput 1.12.1-1 and xserver-xorg-input-libinput with:
sudo dpkg -i libinput10_1.12.1-1_amd64.deb libinput-bin_1.12.1-1_amd64.deb xserver-xorg-input-libinput_0.28.1-1_amd64.deb the files are available here: https://launchpad.net/ubuntu/+source/xserver-xorg-input-libinput and https://launchpad.net/ubuntu/+source/libinput
(4.) I also use the padoka stable mesa ppa.

Maybe it would help if we identify the differences between our devices.
Have you tested if a second suspend/resume cycle revives the touchpad?

@Thorsten

My config: NFC; new BIOS; i2c_i801 unblacklisted; 4.19 kernel; firmware up to date (I think; the Windows only nature of some of the updates makes its hard to tell); synaptics. Maybe the synaptics is the problem - perhaps I need libinput and indeed in the version you mention. So that is yet another thing to yest (isn't this someone's actual job?). Also, I *like* synaptics; I do not want to use libinput.

> Have you tested if a second suspend/resume cycle revives the touchpad?

I think so.

Hi dr_strangehate:

If you have updated touchpad fw,
Could you test your laptop with passing "psmouse.synaptics_intertouch=0" in kernel cmdline?

Thanks,
Aaron

Looks like there was a BIOS (1.34) release on the 23rd - has anyone tried that yet? https://pcsupport.lenovo.com/us/en/products/LAPTOPS-AND-NETBOOKS/THINKPAD-X-SERIES-LAPTOPS/THINKPAD-X1-CARBON-6TH-GEN-TYPE-20KH-20KG/downloads/DS502282

I have yet to play roulette with the update - I installed it, but have not tried to enable S3 yet. As I said in am email that seems not to have reached this page: it is unclear that this BIOS update will help; the release notes (such as they are) do not suggest it will.

While I am here, and might have someone's ear: as I and other have said elsewhere before: that internal beeping during BIOS updates *HAS GOT TO STOP*. I had to swadle my ThinkPad in a blanket; and that irregular cacophany of beeps would be of no help in diagnosing any problem. I complained about this to the 'managed support' and in their innocence they had no idea what I was talking about. TURN IT OFF. Really: STOP IT NOW. It is stupid and deeply irritating and no-one seems to care.

Hi All:

If you have updated touchpad fw,
Could you test your laptop with passing "psmouse.synaptics_intertouch=0" in kernel cmdline?

I have tested for several days without any issue.

I have tested the new touchpad and trackpoint fw on my 20KH model with intertouch=0, unfortunately, no change :(

Hi dr_strangehate:

Could you upload dmesg?
Booting with "psmouse.synaptics_intertouch=0", when failed to detect touchpad.

Thanks,
Aaron

An interesting observation: I've nuked my installation again with a new Ubuntu install (I've also updated the BIOS and brought back factory settings - I just enabled S3, disabled secure boot and turned Thunderbolt support). A fresh install (WITHOUT ANY UPDATES) detects the touchpad as SynPS/2 Touchpad. As long as it stays like this, S3 and resume work fine, without issues. When I do apt update and upgrade, after restart the touchpad is detected as Synaptics Touchpad (so a bit different than before), it starts acting weird again after resume. Does anyone know a way to enforce this PS/2 mode?

Was the kernel updated? Trying running an older kernel and see if it might just be a regression in our kernel..

I think it just got a point update, from 4.15.0-36 to 4.15.0-39. I'll check later what happens if I run the previous version and will let you know here.

Also affecting 2nd gen X1 Carbon.

Booting with "psmouse.synaptics_intertouch=0" will enforce PS/2 mode.
Please try.

If you have issues, please upload dmesg.

If fresh install used SynPS/2 touchpad, it should be that kmod add i2c_i801 in blacklist.
In a newer kmod version, i2c_i801 is removed from blacklist.

You can check /etc/modprobe.d/blacklist.conf.

Please add i2c_i801 in this blacklist. and update-initramfs -u -k <kernel-version>.
"lsmod |grep i2c" to check if i2c_i801 is loaded.

either blacklist i2c_i801 or "psmouse.synaptics_intertouch=0" will enforce PS/2 mode.

I was rather shouty above, for which I apologise, but it is hard to remain calm when things such as the following happen.

I tried up update the trackpad firmware, hoping this would help with the S3 sleep / touchpad problem. I had use a Window pre-boot environment to do to that. The new trackpad firmware would not install previously because of a bug. A BIOS update was meant to allow it to install. It will should not install - but then I remembered I have the trackpoint disabled in BIOS. (The firmware updater did not mention this.) I enabled the trackpoint in the BIOS. The firmware updater seemed to flash alright - but then re-flashed, twice, taking ages each time, giving no message, and making me think my machine was in an infinite loop and that aborting - if I could; the trackpad and touchpoint were not working - would cause serious problems. Eventually the flasher gave an error message and aborted. Possibly the problem was that the flasher needs a Synaptics driver installed and a reboot; in the pre-boot environment I could install that driver but after the reboot it seemed that the driver was no longer install. What a total nightmare.

I have the non-NFC model. I'm running Ubuntu 18.10 with the latest stable kernel (4.19.6) and latest libinput (1.12.1). I have set the kernel boot parameter psmouse.synaptics_intertouch=0.

I have BIOS 1.34 and the very latest touchpad firmware (released 4th Dec) (I booted into Windows to install the FW update).

During my initial testing the touchpad has survived multiple suspends which was most definitely not the case before. For my setup the crucial thing was the touchpad FW update along with the boot parameter.

I will report here if I encounter further problems.

It may be worth my repeating that, despite trying a Windows PreBoot Environment and a Windows Live Environment - but not full windows, because I don't have that on the machine - I can't get the latest touchpad firmware installed.

Oh well... The issue is not fixed even if it seemed to be as I reported yesterday. Full night in sleep and the mouse died again.

Could you guys upload dmesg when your touchpad failed?

Otherwise no info just fail result will not help debug issues/

My dmesg output immediately after resuming from suspend. I had enabled S3 in BIOS and consequently the touchpad was not working. However, I had a USB mouse on the go - for, otherwise, I would have trouble using the computer in that state.

Extra information - namely, the output of several relevant commands.

I also have this problem on an X1C 6th gen (gray if that somehow matters), non-NFC. I've enabled the Linux support for sleep state and Thunderbolt in BIOS, and disabled AMT.

It's exactly as described at https://forums.lenovo.com/t5/Linux-Discussion/Troubles-with-X1-Carbon-2018-X1C6-TouchPad-and-TrackPoint-under/td-p/4004815

Here's the dmesg output:
https://gist.github.com/dandv/d2ed219103f8d03f980fcbb660d05ef1

There are many "Failed to reset mouse on synaptics-pt/serio0" and "psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1" messages.

Both the touchpad and trackpoint do work on Ubuntu Budgie 18.04.1.

I'm a web developer and Linux user, but not familiar with Linux internals. A TL;DR of the discussion above would be great. And maybe someone more knowledgeable could look at why these peripherals do work in Budgie.

New dmesg output, this time running libinput rather than synaptics (and where I have the same problem, i.e. changing to libinput does not allow the touchpad to work after deep sleep).

dmesg attached. Still dying half of the time when waking up from suspend.

Yet another dmesg.

The mouse was dead after waking from suspend, but

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

brought it back to life. Something to note is that running these commands don't work too often, maybe 1 of 10 tries.

Also:

dmesg | egrep "rmi4|serio"
[ 2.075930] serio: i8042 KBD port at 0x60,0x64 irq 1
[ 2.075965] serio: i8042 AUX port at 0x60,0x64 irq 12
[ 2.078462] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input3
[ 3.184888] psmouse serio1: synaptics: queried max coordinates: x [..5678], y [..4758]
[ 3.223562] psmouse serio1: synaptics: queried min coordinates: x [1266..], y [1094..]
[ 3.223567] psmouse serio1: synaptics: Trying to set up SMBus access
[ 4.975525] rmi4_smbus 0-002c: registering SMbus-connected sensor
[ 5.025315] rmi4_f34 rmi4-00.fn34: rmi_f34v7_probe: Unrecognized bootloader version
[ 5.027254] rmi4_f34: probe of rmi4-00.fn34 failed with error -22
[ 5.049435] rmi4_f01 rmi4-00.fn01: found RMI device, manufacturer: Synaptics, product: TM3288-011, fw id: 2812761
[ 5.136652] input: Synaptics TM3288-011 as /devices/rmi4-00/input/input8
[ 5.147113] serio: RMI4 PS/2 pass-through port at rmi4-00.fn03
[ 5.266581] psmouse serio2: trackpoint: Elan TrackPoint firmware: 0x06, buttons: 3/3
[ 5.304786] input: TPPS/2 Elan TrackPoint as /devices/rmi4-00/rmi4-00.fn03/serio2/input/input15
[ 2414.940959] psmouse serio1: Failed to disable mouse on isa0060/serio1
[ 2415.772720] psmouse serio1: Failed to deactivate mouse on isa0060/serio1: -5
[ 2416.012269] rmi4_f01 rmi4-00.fn01: Failed to write device_control register: -6
[ 2416.012272] rmi4_f01 rmi4-00.fn01: Config failed with code -6.
[ 2416.056022] rmi4_f01 rmi4-00.fn01: Failed to restore normal operation: -6.
[ 2416.056026] rmi4_f01 rmi4-00.fn01: Resume failed with code -6.
[ 2416.056029] rmi4_physical rmi4-00: Failed to suspend functions: -6
[ 2416.056033] rmi4_smbus 0-002c: Failed to resume device: -6
[ 2416.101390] rmi4_f03 rmi4-00.fn03: rmi_f03_pt_write: Failed to write to F03 TX register (-6).
[ 2416.143286] rmi4_physical rmi4-00: rmi_driver_clear_irq_bits: Failed to change enabled interrupts!
[ 2416.230749] rmi4_physical rmi4-00: rmi_driver_set_irq_bits: Failed to change enabled interrupts!
[ 2416.230775] psmouse: probe of serio2 failed with error -1
[ 2434.342828] psmouse serio1: synaptics: queried max coordinates: x [..5678], y [..4758]
[ 2434.375534] psmouse serio1: synaptics: queried min coordinates: x [1266..], y [1094..]
[ 2434.375539] psmouse serio1: synaptics: Trying to set up SMBus access
[ 2434.379242] rmi4_smbus 0-002c: registering SMbus-connected sensor
[ 2434.426969] rmi4_f34 rmi4-01.fn34: rmi_f34v7_probe: Unrecognized bootloader version
[ 2434.426978] rmi4_f34: probe of rmi4-01.fn34 failed with error -22
[ 2434.446648] rmi4_f01 rmi4-01.fn01: found RMI device, manufacturer: Synaptics, product: TM3288-011, fw id: 2812761
[ 2434.529343] input: Synaptics TM3288-011 as /devices/rmi4-01/input/input19
[ 2434.541110] serio: RMI4 PS/2 pass-through port at rmi4-01.fn03
[ 2434.658886] psmouse serio3: trac...

@Pietari,

Please booting with "psmouse.synaptics_intertouch=0" to enforce PS/2 mode.
And upload dmesg after S3/resume when touchpad lost.

your log shown rmi_smbus is still in use.

@ALinuxUser,

What is the issue on your laptop.
1, You use "psmouse.synaptics_intertouch=0" in 4.19 kenrel, Does touchpad work well?

2, Not fully dmesg uploaded after S3 resume, does touchpad work after resume?

Could you upload dmesg after touchpad lost ?

@mapengy

What you write is unclear.

Re 1: Are you asserting that I at present I am using that kernel switch? Or are you rather suggesting that I try out that kernel switch? At any rate: I do use that switch already (on a 4.19 kernel) and, no, the touchpad does not work after suspend.

2: What?

As to, 'Could you upload dmesg after touchpad lost ?': I have uploaded it already. If you need me to upload it again or in some new fashion, then please (i) tell me clearly what you need, (ii) give me some indication that going to the trouble will be worth my while.

@ALinuxUser:

There are 2 modes for touchpad, One is PS/2 mode, the other is smbus mode.

1, Old touchpad firmware:
touchpad can *not* work in PS/2 mode.
Only smbus mode is available

2, latest touchpad firmware:
Both PS/2 and smbus work well except after S3.
For now I didn't reproduce touchpad lost issue after S3 on PS/2 mode.
and dr_strangehate confirm PS/2 works well from S3 after updated to latest firmware.

From your log, touchpad firmware is old ( not updated to latest version).
But you used PS/2 mode, it looks like your touchpad worked on PS/2 mode.
This should not be expected on old firmware.

And for your log, it is not completed, it didn't show any issues of touchpad.

For smbus mode, there should be some firmware/driver issue, not found yet.

oky, i now also experienced the issue a couple of times but it only occurs in 1 out of 10 times and i resolved by an additional suspend/resume.

In dmesg i see:
psmouse serio1: Failed to disable mouse on isa0060/serio1

*more info: i am using ubuntu 18.04.1, 4.19.9 from mainline, libinput 1.12.1, attached is my dmesg, the last but one suspend/resume deactivated the touchpad and the last one restored it.
i had psmouse.synaptics_intertouch=1, i am now testing psmouse.synaptics_intertouch=0

oky i could reproduce it with psmouse.synaptics_intertouch=0. Here my dmesg. As above the last suspend/resume restored the touchpad and the last but one deactivated it.

Hi Thorsten:
From your log in comment #72 in PS/2 mode:
supended 2 times:

1, [ 1241.205049] PM: suspend entry (deep)
touchpad resume good:
[ 1242.947401] psmouse serio1: synaptics: queried max coordinates: x [..5678], y [..4758]
[ 1242.979820] psmouse serio1: synaptics: queried min coordinates: x [1266..], y [1094..]

2, [ 1280.646581] PM: suspend entry (deep)
touchpad resume good:
[ 1282.294734] psmouse serio1: synaptics: queried max coordinates: x [..5678], y [..4758]
[ 1282.327655] psmouse serio1: synaptics: queried min coordinates: x [1266..], y [1094..]

Could you clarify what was your problem?
Because no issue found in dmesg.

Hi, thanks for the reply. The touchpad stopped working and was completely unresponsive and was reactivated by the subsequent suspend/resume. (The trackpoint was working all the time) Is there an advanced logging which i could activate?

Here's a dmesg that shows my problem. See the attached file.

grep serio dmesg.txt
[ 2.077870] serio: i8042 KBD port at 0x60,0x64 irq 1
[ 2.077907] serio: i8042 AUX port at 0x60,0x64 irq 12
[ 2.080498] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input3
[ 3.178397] psmouse serio1: synaptics: queried max coordinates: x [..5678], y [..4758]
[ 3.216922] psmouse serio1: synaptics: queried min coordinates: x [1266..], y [1094..]
[ 3.290323] psmouse serio1: synaptics: Touchpad model: 1, fw: 9.16, id: 0x1e2a1, caps: 0xf00ba3/0x940300/0x12e800/0x500000, board id: 3288, fw id: 2812761
[ 3.290330] psmouse serio1: synaptics: serio: Synaptics pass-through port at isa0060/serio1/input0
[ 3.337463] input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio1/input/input5
[ 4.131663] psmouse serio2: trackpoint: Elan TrackPoint firmware: 0x06, buttons: 3/3
[ 4.386550] input: TPPS/2 Elan TrackPoint as /devices/platform/i8042/serio1/serio2/input/input7
[11062.622713] psmouse serio1: synaptics: queried max coordinates: x [..5678], y [..4758]
[11062.655028] psmouse serio1: synaptics: queried min coordinates: x [1266..], y [1094..]
[11123.025305] psmouse serio1: synaptics: queried max coordinates: x [..5678], y [..4758]
[11123.058190] psmouse serio1: synaptics: queried min coordinates: x [1266..], y [1094..]
[11136.130624] psmouse serio1: Failed to deactivate mouse on isa0060/serio1: -5
[11136.149448] psmouse serio1: Failed to enable mouse on isa0060/serio1

To my understanding the failure happens at the time of going into suspend. Then it's unable to do anything.

hi guys,

i own thinkpad x1 carbon 6th gen, model 20KH with ubuntu 18.04 (kernel 4.15.0-43-generic) LTS installed on it. BIOS version 1.31: trackpad DISABLED, trackpoint ENABLED, Linux S3 mode.

BEFORE adding "psmouse.synaptics_intertouch=0" parameter:
- before SLEEP: trackpoint works, touchpad does not work (as expected);
- after SLEEP: trackpoint DOES NOT work, touchpad works (bug).

AFTER adding "psmouse.synaptics_intertouch=0" parameter:
- before SLEEP: trackpoint works, touchpad does not work (as expected);
- after SLEEP: trackpoint works (as expected), touchpad works (bug).

that's it

Hi all,

Before I try these on my 2ND GEN x1c, do you know if it would work? I have ubuntu 16.04 installed and I do not want to change it since it should be very hard to restore some of the software I use on this system. I got this laptop 6 months ago and I do not like(and cannot) spend much money on electronics.

Also do you think pushing lenovo hard on this would make them solve this for linux as well? A few of us sending some requests would be helpful I hope.

Thanks for the effort from more experienced users so far!

tazesimit, do you have issues on 2nd gen? I had this laptop or many years, and it never had any issues with Ubuntu 16.04. Not sure if any of the solutions in this thread will help you, since they are specific for 6th gen and 18.04.

I'm on 2nd gen, and the issue is the same.

Try making a Live USB with some distro, for example 18.04, run it and see if it suspends properly.

Hi all,

Just wanted to add my experience with this. I also have found that my Synaptics touchpad becomes unresponsive after waking from a suspend. It isn't restored by a modprobe -r psmouse / modprobe psmouse. The only thing that restores it is a shutdown (without -r option) followed by a fresh boot.

I noticed also that, when it is showing this unresponsive touchpad symptom,

sudo cat /dev/input/event8 | hexdump

produces nothing at all when i move my finger around on the touchpad (event8 is the touchpad in my system, as shown by /proc/bus/input/devices). Yet, doing:

sudo cat /dev/input/event16 | hexdump

(which is my usb wireless mouse) does produce output when I move my mouse around.

I'm not very familiar with kernel, drivers, firmware, etc. I did think the bit about /dev/input/event8 was interesting though, but I'm not sure what to do with that information.

If anyone is interested, please feel free to suggest a set of commands and their output you might want to see, or procedures to try. I hope this new data point is useful.

Thanks in advance!

Henry

Some other things:

henry@henry-gs65:~$ uname -a
Linux henry-gs65 4.15.0-43-generic #46-Ubuntu SMP Thu Dec 6 14:45:28 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

henry@henry-gs65:~$ sudo lshw | head -n 25
henry-gs65
    description: Notebook
    product: GS65 Stealth Thin 8RF (16Q2.1)
    vendor: Micro-Star International Co., Ltd.
    version: REV:1.0
    serial: 9S716Q211405ZI8000083
    width: 64 bits
    capabilities: smbios-3.1 dmi-3.1 smp vsyscall32
    configuration: boot=normal chassis=notebook family=GS sku=16Q2.1 uuid=FCEFF7B9-5244-47ED-B96D-2A2CF506C220
  *-core
       description: Motherboard
       product: MS-16Q2
       vendor: Micro-Star International Co., Ltd.
       physical id: 0
       version: REV:1.0
       serial: BSS-0123456789
       slot: Default string
     *-firmware
          description: BIOS
          vendor: American Megatrends Inc.
          physical id: 1
          version: E16Q2IMS.110
          date: 10/08/2018
          size: 64KiB
          capacity: 15MiB

henry@henry-gs65:~$ grep -B 1 -A 10 Synaptics /proc/bus/input/devices
I: Bus=0011 Vendor=0002 Product=0001 Version=0000
N: Name="PS/2 Synaptics TouchPad"
P: Phys=isa0060/serio1/input0
S: Sysfs=/devices/platform/i8042/serio1/input/input34
U: Uniq=
H: Handlers=mouse0 event8
B: PROP=1
B: EV=7
B: KEY=70000 0 0 0 0
B: REL=3

henry@henry-gs65:~$ journalctl -b 0 | grep -i touchpad | grep kernel
Jan 06 21:02:58 henry-gs65 kernel: psmouse serio1: synaptics: Your touchpad (PNP: SYN150d SYN1500 SYN0002 PNP0f13) says it can support a different bus. If i2c-hid and hid-rmi are not used, you might want to try setting psmouse.synaptics_intertouch to 1 and report this to <email address hidden>.
Jan 06 21:02:58 henry-gs65 kernel: psmouse serio1: synaptics: Touchpad model: 1, fw: 8.16, id: 0x1e2b1, caps: 0xf00123/0x840300/0x12e800/0x400000, board id: 3414, fw id: 2667658
Jan 06 21:02:58 henry-gs65 kernel: input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio1/input/input6
Jan 09 19:40:09 henry-gs65 kernel: psmouse serio1: synaptics: Your touchpad (PNP: SYN150d SYN1500 SYN000...

Could you try this kernel?

If it works, I will upstream the patch.

Kernel in #82 should use smbus mode.

i2c-i801 should be loaded;
no kernel parameters needed;

Recognized input devices names:
touchpad:
"Synaptics TM3288-011"
Trackpoint:
"TPPS/2 Elan TrackPoint"

thanks for looking into this issue and trying to fix it. I've installed your kernel, however, the issue is still there (at least for me). I've attach my dmesg log. The first suspend/resume at ~122 causes that the touchpad is not working anymore. There is also
"[ 122.097687] psmouse serio1: Failed to disable mouse on isa0060/serio1" in the log. The second suspend/resume at ~197 "revived" the touchpad again.

Hi Thorsten:
Failing log of "XXX Failed to disable mouse XXX" doesn't matter.

Actually in line:
[ 123.824705] psmouse serio2: trackpoint: Elan TrackPoint firmware: 0x06, buttons: 3/3

This means trackpoint works well, I assume touchpad works too.
Did you ever use the touchpad?
Please try to use touchpad by hand.

Hi, the trackpoint worked well but the touchpad did not after the first suspend/resume (I really did try to use it). However, I will test it again.

Ugh, i think i was wrong, it is working. But directly after a resume the touchpad is not working and can it can take quite an amount to work (more than 30s)

I now have performed 5 suspend/resumes and the first 4 times the touchpad did work 5-40s after the resume. However, after the 5th resume the touchpad didn’t wake up again (waited 8min).

I also noticed that I can use the touchpad to perform clicks even if the cursor is not moving (not by using the extra buttons above the touchpad but by pressing down the touchpad). But this is also the case in 4.19.15.

Hi Thorsten:

Your case is very special, I never reproduce it.
Please pass "rmi_core.debug_flags=0x7" to kernel parameter, then boot, test and upload the dmesg.

I added the kernel parameter and did a suspend/resume and attached the dmesg log. Btw I never noticed that the trackpoint didn’t survived suspend/resume (which occasional also happens with 4.19.x)

Hi Thorsten:
Your dmesg is flushed by input log.
please upload "journalctl -b 0 -k"

Hi, here is the journalctl log

Hello,

I have the exakt same thing as Thorsten. Klick works, but the cursor doesn't move. Very odd. Attaching my journalctl log as well.

Changelog:
1, Fix trackpoint (red stick on the keyboard) lost after resume, verified;
2, force enable nosleep mode of RMI;
        I didn't reproduce touchpad lost after resume, this change tries to fix it.
3, add more debug info;

Notes:
1, i2c-i801 module should be loaded. touchpad/trackpoint should work at smbus mode (intertouch=1).
2, If touchpad lost is still reproduced, please do the following steps and upload the log below:
    1) please add "rmi_core.debug_flags=0x7" in kernel parameter;
    2) when touchpad lost after resume,
            $ cat /proc/interrupts |grep rmi > rmi_irq.log
           move mouse curse with touchpad even it is not moving.
            $ cat /proc/interrupts |grep rmi >> rmi_irq.log

Then upload "journalctl -b 0 -k" and rmi_irq.log file.

Thanks for testing.

Hi, I have performed 11 suspend/resumes and no issue! Big thanks for looking into it and fixing it!

nosleep mode sounds like a mitigation so that the bug cannot occur but is not actually fixing it? Is the issue then in the firmware/bios and we have to contact lenovo or is it still there in the kernel? Moreover, nosleep mode of rmi sounds like this would come along with an increased power consumption during suspend? Is this neglectable?

Could you maybe publish your patch already here, so that we can build patched kernels ourself until your patch lands? Your supplied kernel is based on 4.20.rc3 and is therefore not suited for every day use, or?

Finally, glad to hear it helps you.

I will clear my patch and upstream them after more users confirm.

nosleep mode means it should always work at runtime, it should not make more power consumption.
When suspend it will go to sleep too.

AaronMa

Got kernel headers for that kernel, please? (I can boot from the kernel but Wireguard isn't working because of the lack of headers. Since the problem can take some time to manifest itself, I would not mind Internet during the testing phase. I write this from a different computer.)

linux-headers of #94

Thanks for the headers, Aaron (though Wireguard would not build against them).

The patch did *not* work for me: the touchpad failed to work at all upon resume, just as before. I have now added the debugging kernel parameter and followed your further instructions but the log file at issue ended up empty (zero bytes).

hi, more feedback from me: i am now running this kernel since sa morning without any issue with at least 20 suspend/resumes. Just in case, i appended my journalctl log (but without the debug kernelparameter).

@ALinuxUser: do you see any output when typing journalctl -b 0 -k?

> do you see any output when typing journalctl -b 0 -k?

Yes, but what do you have in my specifically? Anyway, at present I am not running the patched kernel, because (1) as I explained, it broke my networking, (2) deblacklisting the touchpad module seemed to cause my touchpad problems (even when the patched kernel was not loaded).

Here is a correction to my previous post (the post immediately above this one). '[W]hat do you have in my specifically': I meant 'have in mind'.

I think you should try it again, even if wireguard is not working. Just for testing and creating a log of your issue, which would probably be very helpful for AaronMa and thus for all of us if this damn bug is finally resolved. Just try somehow to get "journalctl -b 0 -k > journal.log" after a resume/suspend and the other logs as AaronMa described.

Remember this kernel seems to be based on 4.20rc3 so the wireguard issue etc. can be caused by this and could already be fixed in 4.20.3 (current mainline version). You could get 4.20rc3 from https://kernel.ubuntu.com/~kernel-ppa/mainline/ and test if you could reproduce your issue with this version and check if it is fixed in 4.20.3. If you can reproduce it and it is not fixed in 4.20.3 you could/should create a new issue for this bug.

We have a kernel dev looking into this issue who ties to fix the crap lenovo sells. Thus we have to use this chance :)

@thorstenr-42

You are right; and when I did my first test I had failed to see the request for the journal.

I have tested again. As before, the rmi_irq file ended up blank, but I attach the journal file.

As to Wireguard: I think that Wireguard doesn't get set up to work with all release candidate kernels; but once the kernels move out of testing, Wireguard is able to build its module against it.

thanks for doing this! Could you please also add the debug kernel parameter which AronaMa requested in #94: rmi_core.debug_flags=0x7 (it is missing according to your log). Maybe thats also the reason why the other two logs are empty.

@ALinuxUser

Refer to your log in #104, there is no touchpad/trackpoint found.
#63 log, ps/2 mode is set, but no trackpoint found.
Can you use your touchpad/trackpoint?

If not, I think your touchpad/trackpoint fw are broken.
Please try to update fw.

Or I suggest to ask LENOVO service to replace a new touchpad.

Thorsten,

I thought I had added that. I'll add it again and remove most of my other kernel flags, in case they were causing a problem. Indeed I have discovered a problem with the flags that I was using, namely, that as well as having the correct (correct for testing) `psmouse` option, I had additionally a garbled version of that. Apologies.*

This time the interrupt file was *not* empty. Note though that I echoed stuff to it three times (rather than two) because, the second time I did it, I forgot to touch the touchpad first. Note also that I have a wireless mouse on the system.

* Perhaps the reason that I have not been as diligent as I might have been is that this procedure is a chore. For, I must: switch to the special kernel; change kernel flags; change my blacklisting; reboot (which requires entering up to three passwords); change BIOS sleep settings; put the computer to sleep for a good period; wake it up; test the touchpad; gather logs (using a mouse); and then (because of the vpn problem) undo everything and post the results.

@AaronMa

You might want to see the new logs I have posted. But there is indeed a touchpad firmware update that I not applied - but not for want to trying. The update is not available via fwupdmgr, there is no bootable version of the update, the update will not install via virtualised Windows or through a Windows PreBoot Environment, and I do not have real Windows on the machine.

As to, 'Can you use your touchpad/trackpoint': I can use the touchpad, except after S3 (not the 'modern standby'/Windows version) sleep; but if enable the track*point* in the BIOS, then the trackpad starts working very peculiarly indeed. Other people have had the latter problem.

@ALinuxUser

Could you enable trackpoint in BIOS and try again?

Done.

Enabling the trackpoint in the BIOS did not (because of some sort of update since the last time I tried it) cause the touchpad to stop working but the trackpoint did not work at all either (either before or after sleep). Perhaps I have the trackpoint disabled in some further way somewhere.

As to the touchpad, after a (fairly long) sleep: same behaviour as before, i.e. the trackpad is dead.

Thus far I have had `tlp` enabled. Just now I disabled it. Nothing seemed to change, i.e. the trackpad still does not work at all (and the trackpoint does not work under any circumstances - at least if using libinput; when I first got my X1, and used synaptics, the trackpad would work, so long as I disabled the touchpad).

@ALinuxUser

Your touchpad failed to probe at boot, after resetting it, it back to work.
Touchpad responded in a very weird way.
Trackpoint never responded to any commands.

I still suspect your touchpad is in some kind of broken.

I have just now installed the latest firmware updates from Lenovo, by creating a 'WindowsToGo' installation. The problem with the touchpad being dead after S3 sleep remains. (I haven't tested the trackpad.) That affords a little more reason to think that my touchpad is broken; but I think we should try to get some more people, who have the Near Field Communications chip, to see whether the patch here works.

I add that the kernel switch `psmouse.synaptics_intertouch=1`seems to produce spurious middle clicks as desribed on the page https://bugzilla.redhat.com/show_bug.cgi?id=1482640 (even though that page says kernels >= 4.13.6 have fixed the problem).

But I find that my system may not have the latest touchpad firmware - n23gc05w.exe - installed, even though I used WindowsToGo to run Lenovo's auto-update utility. Someone mentioned this firmware update above as a prerequisite for fixing the problem, so I'll install it and report back.

n23gc05w.exe now installed, and the patched kernel still does not work.

@ALinuxUser:

Just install 05w.exe will not update fw of touchpad, it is a known issue of that package.
Please refer to comment #28.

Your issue is *different* from others.
Just complain without debug info uploaded will not help solve your issue.

Highlights:
#98 is meant to solve the issue for @Thorsten and @Michael Andersson.

Unfortunately, I have to report a strange resume: the screen remained black after opening the lid. I pressed the powerbutton and after a few seconds and flickering the screen came back.
The log shows a Kernel Call Trace but also a gnome-shell crash. Thus, I appended my complete journalctl log. (Suspend was at ~18:10 and resume at 8:46).

@alinuxuser: i once had a broken touchpad (half-broken cable) on my old thinkpad which only showed it's errors under linux, while it was working almost fine under windows. However, the windows eventlog was full of error messages -> If you see any errors under windows, call the support and let them replace your touchpad

Thanks, all.

I've verified that I do indeed have version 1.3 of the touchpad software installed (and I am horrified but not surprised that Lenovo managed to get a bug into their firmware updater).

I have looked at the Windows event log and the only repeated errors I see have to do with 'DistributedCom' (and those errors are common in Windows land) and dotnet.

Hi,

I have the same bug on my Lenovo X1 Carbon 6th Gen, Model: 20KGS03800. I am running KDE neon 5.14 and I added psmouse.synaptics_intertouch=1 to the boot parameters.

I attached the output of "journalctl -b 0 -k" before I installed the patched kernel from Aaron (I ran kernel 4.18.13-041813-generic if that is of use) and after installing the patched kernel. (I started testing yesterday evening so there are two logs).

So far the patch does work for me: After every suspend the trackpoint and its buttons did resume and work properly, the touchpad worked all the time for me.

Many thanks so far for the fix, much appreciated!

Sorry for the multiple messages seems I cannot attach more than one file to an answer.

This bug also occurred for me when undocking/redocking my first generation Thinkpad Helix from its keyboard dock, but installing AaronMa's kernel and headers from #94 and #98 and rebooting fixed it.

Me again. Now, I might have faulty hardware, but it occured to me that having 'reboot=w' in my kernel boot arguments might be the problem. I will test - i.e. see whether the patch works if I remove that argument - when I have time. Still, using that argument does have a purpose

Here is some information relevant to this thread.

An update from Ubuntu that 12c_i801 *re*-blacklists just arrived on my Mint PC.

I had it blacklisted on my system anyway. A while ago, it was blacklisted by default, but then a Debian update removed it from the blacklist. Now, for Ubuntu and derivatives at least, it is back on the blacklist.

Hello,

After some very thorough testning I can say that it seems to be working!

Though I noticed that sometimes, not often, tap to click, two finger scroll and two finger right click stops working for a brief moment, up to 20 seconds maybe. Can't say for sure it is related to the fix but I guess it's likley. Attaching journalctl log.

// Michael

@AaronMa: could you please post the patch that you wrote?

@AaronMa: Would be really nice if you could post your patch here, so we could build our own kernels until your patch lands upstream. This would also allow users of other distros to provide feedback. Thanks!

Still on vacation, will upstream patches later.

Upstream patches:

https://<email address hidden>/T/#t

If you met touchpad issue, do the following command:

# echo 1 > /sys/devices/rmi4-00/nosleep

@AaronMa

Thank you.

To be clear, though: you mean the following, yes? If, after applying the patches, one still has a touchpad problem, then one should issue the command you give. Presuming that that *is* your meaning: when should one apply that command? After boot and after every sleep?

After boot, issue the command once. Then nosleep mode will always be enabled.
systemd udev rules can be a better way.

I am sorry to keep banging on, and we are grateful for your work, but, again, you need to be precise. Do you mean (1) udev rules are a better way to run the command at boot (than some other way of running the command at boot), or (2) udev rules are better than running the command at boot, because with udev one can run the command at other times too (for instance, after each resumption from sleep)? I think you mean 1, but I am not entirely sure.

Also: 'nosleep mode'? Is the workaround - the running of the command, in one way or another - an extreme one in that it totally disables sleep? Or something like that?

As I say: thank you for your work (although, as indicated earlier in the thread, the patch may not work for me, possibly because - as you and another suggested - I may have broken hardware).

@ALinuxUser

You can just execute the command after boot.

I tried to say udev rules can set sysfs file value when boot.
Not to execute the command.

For reference:
https://www.freedesktop.org/software/systemd/man/udev.html

@Aaron Ma: Thanks for upstreaming! Have you also found time to look into the crash-on-resume with your kernel, which I reported in #121. Is this somehow related? I have not encountered a crash with 4.20.x from mainline.

Hi Thorsten:

That 4.20-rc3 kernel is only for touchpad test.
Crash is not related to this issue.
If no crash on 4.20.x version kernel, maybe it is fixed in later kernel version.
We can just ignore it and use newer kernel.

Okay, thanks a lot!

small update: i am using 4.20.11 with your patches on top since Friday without any issue! I don't even need the nosleep option.

For others ensure that blacklist i2c_i801 is removed from /etc/modprobe.d/blacklist.conf ...

Please excuse my potentially unqualified question: how can I find if the patch has been picked up and integrated in the ubstream Kernel? Or if it has happened already, how can I find out which version has the patch?

@Robert:

These patches are still in review, not integrated in upstream kernel yet.
After maintainer apply them to maintainer's tree. They will be in Linus's tree soon.
I will update the upstream status here if you want.

@Thorsten:
Thanks for feedback.

More feedback are welcome.

@Thorsten

Might you explain how to apply patches to, say, the 5.0.1 kernel (which I am using, via the Ubuntu Kernel Update Utility, on Linux Mint)? I can't seem to find the information in this thread and I am unsure of the goodness or at least relevance of other instructions that I've found on the web. I'd be most grateful.

.Debs are provided, above, for a patched version of the 4.20 kernel; but you say you managed to run the patches on 4.21 - so perhaps the patches can apply to kernel version 5 as well?

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.

@dr-strangehate

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 :)

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?

@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://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git

get the patches
    wget -O first.patch https://lkml.org/lkml/diff/2019/2/20/700/1
    wget -O second.patch https://lkml.org/lkml/diff/2019/2/20/701/1

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

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/touchpad-reconnect.sh, 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.

@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.

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

Troubleshooting:
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

@thorsten

Thanks.

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.

rmi_irq.log

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.

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!

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

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.

@Thorsten

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: https://download.lenovo.com/pccbbs/mobiles/n23rg11w.txt

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

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.

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.

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.

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

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.

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

but is there any update on this issue?

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

+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.

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.

dr_strangehate:

Thanks.

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.

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?

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

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

@Pavel

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.

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

I was happy early because the bug appeared again :(

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.

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`

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

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.

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.

@thorsten Do you have a model with NFC?

Does the nosleep workaround work for everyone?

@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 (https://lkml.org/lkml/diff/2019/2/20/700/1) 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.

@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?

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.

@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?

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
#!/bin/bash

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
fi
exit 0

cat /etc/default/tlp | grep SUSPEND
USB_AUTOSUSPEND=0
USB_AUTOSUSPEND_DISABLE_ON_SHUTDOWN=1

@jnns

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.

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

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

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!

@ssss

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.

Anyone know what happened to Aaron's patch? The discussion at https://patchwork.kernel.org/patch/10822515/ 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.

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

@Kai-Heng

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.

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

@Kai-Heng

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.

any news on the patch?
I still have this issue

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?

I spoke too soon. Deep sleep works now, and the touchpad keeps working, but only - even with the new motherboard - if I keep the NFC *enabled* in the BIOS. And the trackpoint does not work under Linux. At all. At any time (at least on my distro) and even with a very recent kernel.