Created attachment 282891 [details] dmesg log for a S3 sleep done via lid closing Hello, On a Lenovo X1 Yoga 3rd gen, when suspending the system to S3 (deep) sleep, the touchscreen, which is connected as USB device (Bus 001 Device 012: ID 056a:5146 Wacom Co., Ltd Pen and multitouch sensor) is getting disconnected, when closing the lid of the laptop on resume the touchscreen is then non-functional, because the kernel doesn't know it's there and doesn't automatically re-detects the device. lsusb also doesn't detect the device and the relevant /sys/.../usb/... entries are gone too. The relevant dmesg logs are in deep.log. When instead of using S3 sleep, I just go into s2idle sleep and close the lid the device also gets disconnected, but after the laptop resumes the kernel detects the touchscreen as a new device. The relevant logs are in s2idle.log. It seems that the kernel is not checking for new devices somehow after resume from S3. To revive the touchscreen after a S3 sleep I can go to the freeze state for 1 or 2 seconds and after that the device is added again by the kernel and the touchscreen works again. For the record I first thought this was a Desktop Enviroment issue, so the original bug is https://gitlab.gnome.org/GNOME/gnome-settings-daemon/issues/113. I hope somebody can help me find the issue here. Best regards
Created attachment 282893 [details] dmesg log for a s2idle sleep done via lid closing
Does this issue still exist if you do not use lid but to: echo deep > /sys/power/mem_sleep echo mem > /sys/power/state and wake up via power button?
I just tested it and this indeed does not happen if I use the method you provided. The touchscreen is still functional after wake up.
It seems that if LID is closed and then resumed, the BIOS could not detect the existence of touchscreen, maybe it is an inner connection between the LID and touchscreen in fw.You might also try, echo mem > /sys/power/state, then close the lid, and then open the lid to wake up the system, to check if touchscreen works? I thought this might not be linux specific, but might also be triggered on other OS.
If I close the LID, while sleeping via echo mem > /sys/power/state and then open up the LID the touchscreen doesn't work anymore. ThinkPads have a glowing red dot on the cover, that indicate that the system is running, while sleeping it is pulsing. If I sleep the system, the dot is pulsing (also the power button is pulsing), if I close the LID the dot is glowing constantly for ~5 seconds and then starts glowing again. S I think the laptop wakes up for a few seconds on LID close and then suspends due to LID close and then it breaks the touchscreen(?). That's just my interpretation. I don't have Windows on my harddrive, so I can't test, but its said that on Windows it just uses Modern Standby, which is not really S3 sleep.
I just found a way of bringing the touchscreen back to life after suspend. If I open the laptop lid and the touchscreen doesn't work, I close and re-open the laptop quickly (so it doesn't suspend) and then the touchscreen works again. So maybe this is a fw bug, that the device/bios doesn't gets notified that the lid is open again? It would explain why in s2idle sleep everything works, because the operating system is still "awake" and during deep sleep it is not and thus can't notify the device of a lid change. But I'm just guessing in the blue right now.
> It would explain why in s2idle sleep everything works, because the operating > system is still "awake" and during deep sleep it is not and thus can't notify > the device of a lid change. You're spot on about that. The firmware expects a _Q2A EC query (lid open), but it never happens. Either it doesn't get generated, or it doesn't get passed on by the kernel. _Q2A turns something on with GPIO - this is only done in _Q2A, not in any wake-up handler, unless waking from S4. Manually executing _Q2A brings the Wacom back on the bus: echo '\_SB.PCI0.LPCB.EC._Q2A' >/proc/acpi/call Toggling ec_no_wakeup, which is quirked on for the model, doesn't help.
(In reply to Jasper Mattsson from comment #7) > > It would explain why in s2idle sleep everything works, because the > operating > > system is still "awake" and during deep sleep it is not and thus can't > notify > > the device of a lid change. > > You're spot on about that. > > The firmware expects a _Q2A EC query (lid open), but it never happens. > Either it doesn't get generated, or it doesn't get passed on by the kernel. > _Q2A turns something on with GPIO - this is only done in _Q2A, not in any > wake-up handler, unless waking from S4. > > Manually executing _Q2A brings the Wacom back on the bus: > > echo '\_SB.PCI0.LPCB.EC._Q2A' >/proc/acpi/call > > Toggling ec_no_wakeup, which is quirked on for the model, doesn't help. Just want to confirm that the command indeed brings the wacom device back online.
Oh wow, I wonder if the same trick could work for DELL 7400 2-in-1 https://bugzilla.kernel.org/show_bug.cgi?id=204063 Even though, by now kernel 5.5-rc, s2idle has been performing very well, I feel like S3 deep sleep is no longer a necessity.
> Oh wow, I wonder if the same trick could work for DELL 7400 2-in-1 > https://bugzilla.kernel.org/show_bug.cgi?id=204063 Something similar might work - EC queries are vendor and model specific, I wouldn't run random ACPI calls on a machine out of fear of bricking it.
(In reply to Jasper Mattsson from comment #7) > > It would explain why in s2idle sleep everything works, because the > operating > > system is still "awake" and during deep sleep it is not and thus can't > notify > > the device of a lid change. > > You're spot on about that. > > The firmware expects a _Q2A EC query (lid open), but it never happens. > Either it doesn't get generated, or it doesn't get passed on by the kernel. > _Q2A turns something on with GPIO - this is only done in _Q2A, not in any > wake-up handler, unless waking from S4. > > Manually executing _Q2A brings the Wacom back on the bus: > > echo '\_SB.PCI0.LPCB.EC._Q2A' >/proc/acpi/call > > Toggling ec_no_wakeup, which is quirked on for the model, doesn't help. Is there something I can still do to help?
Can somebody help me and point me to the location, where the EC queries are generated? Or help me understand why the kernel wouldn't notify the firmware of the wakeup?
I digged a little into acpi and got this as acpi events that get generated on LID close/open: ``` ! ~ sudo acpid -d -f -l -n Mi 22 Apr 2020 10:43:44 CEST inotify fd: 3 inotify wd: 1 input layer /dev/input/event0 (Sleep Button) opened successfully, fd 4 input layer /dev/input/event1 (Lid Switch) opened successfully, fd 5 input layer /dev/input/event10 (HDA Intel PCH Mic) opened successfully, fd 6 input layer /dev/input/event11 (HDA Intel PCH Headphone) opened successfully, fd 7 input layer /dev/input/event12 (HDA Intel PCH HDMI/DP,pcm=3) opened successfully, fd 8 input layer /dev/input/event13 (HDA Intel PCH HDMI/DP,pcm=7) opened successfully, fd 9 input layer /dev/input/event14 (HDA Intel PCH HDMI/DP,pcm=8) opened successfully, fd 10 input layer /dev/input/event15 (HDA Intel PCH HDMI/DP,pcm=9) opened successfully, fd 11 input layer /dev/input/event16 (HDA Intel PCH HDMI/DP,pcm=10) opened successfully, fd 12 input layer /dev/input/event2 (Power Button) opened successfully, fd 13 input layer /dev/input/event3 (AT Translated Set 2 keyboard) opened successfully, fd 14 input layer /dev/input/event8 (Video Bus) opened successfully, fd 15 input layer /dev/input/event9 (ThinkPad Extra Buttons) opened successfully, fd 16 netlink opened successfully starting up with netlink and the input layer parsing conf file /etc/acpi/events/videoconf skipping incomplete file /etc/acpi/events/videoconf parsing conf file /etc/acpi/events/powerconf 1 rule loaded waiting for events: event logging is on ``` Here I closed and opened the lid, which resulted in a broken touchscreen: ``` received input layer event "button/lid LID close" 0 total rules matched completed input layer event "button/lid LID close" inotify read bytes: 32 inotify name len: 16 inotify received a delete for: /dev/input/mouse1 inotify read bytes: 32 inotify name len: 16 inotify received a delete for: /dev/input/event5 inotify read bytes: 32 inotify name len: 16 inotify received a delete for: /dev/input/mouse2 inotify read bytes: 32 inotify name len: 16 inotify received a delete for: /dev/input/event6 received input layer event "button/lid LID open" 0 total rules matched completed input layer event "button/lid LID open" received netlink event "ibm/hotkey LEN0268:00 00000080 00006032" 0 total rules matched completed netlink event "ibm/hotkey LEN0268:00 00000080 00006032" received netlink event "ibm/hotkey LEN0268:00 00000080 00006032" 0 total rules matched completed netlink event "ibm/hotkey LEN0268:00 00000080 00006032" received netlink event "battery PNP0C0A:00 00000080 00000001" 0 total rules matched completed netlink event "battery PNP0C0A:00 00000080 00000001" ``` And then I closed and opened the lid quickly to bring the touchscreen back: ``` received input layer event "button/lid LID close" 0 total rules matched completed input layer event "button/lid LID close" received input layer event "button/lid LID open" 0 total rules matched completed input layer event "button/lid LID open" inotify read bytes: 32 inotify name len: 16 inotify about to open: /dev/input/mouse1 inotify read bytes: 96 inotify name len: 16 inotify about to open: /dev/input/event5 inotify name len: 16 inotify about to open: /dev/input/mouse2 inotify name len: 16 inotify about to open: /dev/input/event6 received netlink event "ibm/hotkey LEN0268:00 00000080 00006032" 0 total rules matched completed netlink event "ibm/hotkey LEN0268:00 00000080 00006032" received netlink event "ibm/hotkey LEN0268:00 00000080 00006032" 0 total rules matched completed netlink event "ibm/hotkey LEN0268:00 00000080 00006032" received netlink event "battery PNP0C0A:00 00000080 00000001" 0 total rules matched completed netlink event "battery PNP0C0A:00 00000080 00000001" ``` It looks like something is triggering these delete events, which I suppose is fine, but the open events are not correctly triggered. Maybe this helps a bit.
Created attachment 288663 [details] dmesg.log with acpi debug I tried to debug further and get more info from acpi about what events get emitted and when I'm running a debug kernel with some logging enabled this is what I got. I think the important events are: [ 548.432037] utils-0296 evaluate_integer : Return value [0] [ 548.520912] utils-0296 evaluate_integer : Return value [1] those are happening right before the touchscreen comes back alive, but I wonder why their not emitted by default when resuming.
Apologies if I missed it in the above - but can you share the details of which version of FW you are testing on to produce this issue. The firmware team here looked into this but were unable to reproduce. Their notes are: I have try with latest Ubuntu 21.10 with BIOS#58W/EC#33W, both sleep state “Windows” and “Linux” can’t duplicate the issue. Are there any detail reproduce step? My reproduce step: 1. Set sleep state to “Linux” 2. Enter OS, check Wacom device appear in “hardinfo”, and touch panel can work normally. 3. Put machine into Suspend for 5 minutes. 4. Resume system and check Wacom device appear in “hardinfo”, and touch panel still can work normally. Thanks Mark