03-22-2018 11:55 PM
After applying the patch to make suspend work on Linux (from this thread), I've discovered that the touchscreen on my X1 Yoga Gen 3 doesn't come back after resume.
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M |__ Port 3: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 5000M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/12p, 480M |__ Port 7: Dev 2, If 0, Class=Wireless, Driver=btusb, 12M |__ Port 7: Dev 2, If 1, Class=Wireless, Driver=btusb, 12M |__ Port 8: Dev 3, If 1, Class=Video, Driver=uvcvideo, 480M |__ Port 8: Dev 3, If 0, Class=Video, Driver=uvcvideo, 480M |__ Port 9: Dev 4, If 0, Class=Vendor Specific Class, Driver=, 12M |__ Port 10: Dev 5, If 1, Class=Human Interface Device, Driver=usbhid, 12M |__ Port 10: Dev 5, If 0, Class=Human Interface Device, Driver=usbhid, 12M
$ lsusb -t /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M |__ Port 3: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 5000M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/12p, 480M |__ Port 7: Dev 2, If 0, Class=Wireless, Driver=btusb, 12M |__ Port 7: Dev 2, If 1, Class=Wireless, Driver=btusb, 12M |__ Port 8: Dev 3, If 1, Class=Video, Driver=uvcvideo, 480M |__ Port 8: Dev 3, If 0, Class=Video, Driver=uvcvideo, 480M |__ Port 9: Dev 4, If 0, Class=Vendor Specific Class, Driver=, 12M
Note that port 10 has vanished.
I've tried various things to attempt to rediscover the touchscreen USB device (playing with USB power management, unbinding/rebinding the PCI device for the USB hub), but to no avail.
My best guess at this stage is that it's something along the lines of the touchscreen USB device only doing device enumeration once per power on, but I don't know enough about the USB protocol to test this hypothesis.
Has anyone else experienced this? Or any suggestions for debugging further?
(I'm somewhat doubtful that there's a workaround, and it'll require a firmware update to fix)
03-23-2018 06:56 PM
Forgot to mention:
$ uname -a Linux tekel 4.15.0-1-amd64 #1 SMP Debian 4.15.4-1 (2018-02-18) x86_64 GNU/Linux
I've also discovered it doesn't consistently break after resume, so my hypothesis is wrong and I have no plausible explanation.
03-24-2018 05:47 AM
Same machine X1Y3. My touchscreen and trackpad work fine after suspend (unless it is rotated 180 degrees which happens on occassion) although my keyboard doesn't.
I am using bios 1.10 and 4.15.10-300.fc27.x86_64 with the following kernel parameters:
GRUB_CMDLINE_LINUX="rd.lvm.lv=fedora/root rd.lvm.lv=fedora/swap rhgb quiet resum
e=/dev/mapper/fedora-swap acpi.ec_no_wakeup=1 psmouse.synaptics_intertouch=1"
- acpi.ec_no_wakeup=1 to hopefully get a better low power sleep state without patching
_ psmouse.synaptics_intertouch=1 to hopefully get trackpad working after resume
and also these bios settings:
- trackpoint turned off in the bios
- thunderbold linux compatibility (I forget exactly what lenovo calls this option although linux is mentioned in the notes on the right)
I've tried several combinations of these kernel and bios switches to get suspend working. No matter what I use, coming out of suspend is problematic.
What does work for me is enabling hibernation and using it as the default lid-switch method, except that bluetooth is always turned on when the machine comes out of hibernation. Of course, this means you have to wait around 15 seconds for the machine to wake up, which is far from ideal. Sometimes it wakes up with screen rotated 180 degrees and can't be coaxed out of tablet mode (so keyboard isn't working), but this has been pretty solid for me as a workaround to the poor linux support (compared to my X1 Carbon 2015) of this machine.
03-24-2018 06:51 PM
As of a few days ago the ArchLinux wiki is updated with a solution for this issue.
Following these steps solved the issue for me on Ubuntu 16.04. Lenovo should release a official fix for this though. Alot of people bought this machine with the pretense of it working more or less flawlessly in linux(the ubuntu certification sealed the deal for me, very disapointing!).
03-25-2018 05:06 AM
Thanks, for the link. For me the kernel parameter
along with the thunderbolt setting does indeed allow the machine to reach deep sleep, but we are finding the touchscreen and/or keyboard (for me this is the only thing that isn't working) and/or trackpad unresponsive once the machine wakes up, even with the kernel parameter
My guess is that it will take a bios upgrade to fix this.
BTW: I have found that if I quickly close the lid and reopen after coming out of sleep everything works.
04-03-2018 03:02 PM
The kernel parameter
may save some power but still uses entirely too much of my battery when sleeping.
Looks like the patching mentioned in this other thread is required to get proper sleep, which I believe needs to be re-applied after bios upgrades. Are people still having problems with touchscreens after applying this fix with current (1.11) bios?
Until this gets sorted, I'll stick with hibernation.
04-17-2018 03:00 AM
It seems, that the touchscreen is switched off (by controller or HW) on lid close event to prevent spurious touches.
Just befor suspend in dmesg:
usb 1-10: USB disconnect, device number 5
On my device it is possible to bring back touchpad. First I need to disable suspend on lid close event. Next close and open lid. The touchpad is back.
usb 1-10: new full-speed USB device number 7 using xhci_hcd
usb 1-10: New USB device found, idVendor=056a, idProduct=514a
usb 1-10: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 1-10: Product: Pen and multitouch sensor
usb 1-10: Manufacturer: Wacom Co.,Ltd.
May be it is caused by some race condition between wake up and reconnection of touchscreen.
07-23-2018 02:43 AM
The touchscreen functionality can be restored by freezing system (s2idle):
(as root)# echo 'freeze' > /sys/power/state
and then wake up laptop. It brings back touchscreen and pen.
To automate this I use small systemd unit (tested on ubuntu 16.04):
create a unit file: /etc/systemd/system/wake_wacom_hack.service with content:
Description= s2idle fo 1 second after resume
ExecStart=/usr/sbin/rtcwake -m freeze -s 1
enable in standard way:
(as root)#systemctl enable wake_wacom_hack.service
Wake up takes few seconds longer, but it is still much faster then hibernate.
11-18-2018 12:09 PM
Thanks for the systemd service creation idea.
The driver can be restarted much faster with `xinput`. Use the full name reported by `xinput list`, not the id number which may change. The changing device numbers may be what confuses the driver in the first place, after opening the lid and resuming from suspend. Perhaps the driver itself can switch to using the full device name, or the resume code, kernel, APM, (BIOS?) could see about not changing the device number. Whatever... We have
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ Cypress APA Trackpad (cyapa) id=9 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
And then (example Cypress is from my Chromebook)
xinput disable 'Cypress APA Trackpad (cyapa)'
xinput enable 'Cypress APA Trackpad (cyapa)'
We are getting the problem narrowed down. Maybe it will fix soon. For now, make a systemd service script as before.
11-19-2018 10:43 AM
Freezing (s2idle) the machine does not bring back my touchscreen and pen on debian 9.6 (4.9 kernel).
Are you using any special BIOS settings and/or grub boot parameters?
Are you using the S3 sleep patch with initrd acpi override in your grub.cfg?