Open ceever opened 1 year ago
The "waking up on lid close" problem is one that I've wanted to look into for a while but never got around to. For this we might need to register the GPE with the lid device, but I'm not entirely sure yet.
However, the Suspend mode is not interrupted on lid opening either, even though the Typecover (aka lid) starts illuminating the keys after a few seconds delay. No key will wake the device, only the Power Button will do this.
This sounds a bit like it's waking up but then going back to sleep, i.e. like what should happen on closing. One possibility is that the lid state isn't being updated in time. Another is that something in user-space sends it back to sleep. Can you post a full dmesg log from this?
Unfortunately, I could not reproduce the lack of wakup from Suspend when the lid is opened. Now, it actually works.
The main issue however is still exists, waking up when closing the lid.
Btw. would it make sense to mention in the blacklisting of this kernel module as workaround for potential lid/wake issues? I was really struggeling before finding out about this, and I would guess other people would also like to have more control over the lid behaviour. If I can add it myself to the wiki, can you point me to the right direction?
Here some dmesg:
Btw. would it make sense to mention in the blacklisting of this kernel module as workaround for potential lid/wake issues?
Yeah, I guess. Feel free to add that to the wiki.
Yeah, same happens on SP6. Fedora 38, latest linux-surface. Anyway, a incrediblyawesome workaround, works like a charm, thanks, ceever ❤️
also experiencing this issue on SB2 running PopOS w/ Surface kernel
ceever's workaround worked wonders tho :)
I'm having the same issue with the screen waking on lid close. It also often causes the system to hang and a repeated audio sound coming from the speaker every second or so. Hard rebooting is the only way to recover.
Check wiki, faq section. There is incredible workaround by ceever for this issue!
Experiencing the same issue on a SP8! Great thing there is a pretty smart work-around on the FAQ.
I recently installed Arch Linux on my Surface Pro 5 and ran into this issue. The device resumes fine when opening the closed lid but also when the lid is closed after suspending it. I decided to dig deeper and here's what I found:
s2idle_loop
function defined here: https://github.com/torvalds/linux/blob/70293240c5ce675a67bfc48f419b093023b862b3/kernel/power/suspend.c#L120surface_gpe
is triggered which asserts the ACPI SCI and wakes up the device.acpi_s2idle_wake
function is called to determine whether the wake-up was actually valid: https://github.com/torvalds/linux/blob/70293240c5ce675a67bfc48f419b093023b862b3/drivers/acpi/sleep.c#L736acpi_ec_dispatch_gpe
is hit, it returns true
because first_ec
is NULL
and the GPE was triggered.I'm not sure how to continue here without actually modifying the kernel's ACPI code. Ideally, the kernel would also cancel the wake-up for the lid switch GPE until it hits the acpi_button
driver which only wakes up the system if the lid is actually open.
I've also tried to find out why this is not handled correctly by user space. KDE's PowerDevil service actually tries to suspend the system again when it is spuriously woken up but fails with There's already a shutdown or sleep operation in progress
when calling org.freedesktop.login1.Manager.Suspend
via D-Bus. It seems like systemd
is still resuming the system while KDE tries to suspend it again.
@qzed Any thoughts on how this could be fixed?
@medusalix, how this can be fixed - no idea, but workaround is detailed here. the way I used my device for a year: go to sleep by pressing shutdown button and create desktop icon to turn off screen (make brightness zero). keyboard was just inactive.
@farline99 I know about the workaround but I'm looking for a proper fix. If it works on Windows there's no reason why it shouldn't work on Linux too.
@medusalix Thanks for looking into this!
I'm not sure how to continue here without actually modifying the kernel's ACPI code. Ideally, the kernel would also cancel the wake-up for the lid switch GPE until it hits the
acpi_button driver
which only wakes up the system if the lid is actually open.
Yeah I think at this point it would need some ACPI/resume related code changes... unless there's some option to not have the GPE fully wake up the system, which I don't think there is. On a related note: I think we will also need something like this to make wakeups via the Surface EC work (basically, that has a wakeup GPIO but it should not wake up unconditionally when it's been triggered, instead it should check some messages/state of the EC first and then decide if the device needs to be woken up).
I've also tried to find out why this is not handled correctly by user space. KDE's PowerDevil service actually tries to suspend the system again when it is spuriously woken up but fails with
There's already a shutdown or sleep operation in progress
when callingorg.freedesktop.login1.Manager.Suspend
via D-Bus. It seems likesystemd
is still resuming the system while KDE tries to suspend it again.
Hmm, IIRC systemd has some timeout (for lack of a better word) that prevents the system from reacting to lid events directly after being woken up, but that doesn't sound like that would not be relevant here... Maybe there's something similar for suspend in general? Apart from that I have no idea.
Yeah I think at this point it would need some ACPI/resume related code changes... unless there's some option to not have the GPE fully wake up the system, which I don't think there is. On a related note: I think we will also need something like this to make wakeups via the Surface EC work (basically, that has a wakeup GPIO but it should not wake up unconditionally when it's been triggered, instead it should check some messages/state of the EC first and then decide if the device needs to be woken up).
I spent some time this week trying to figure out the best way to fix this. My first idea was to just ignore the wake-up from the lid GPE in acpi_ec_dispatch_gpe
. I was then expecting the acpi_button_driver
to wake-up the system if the lid is actually open. This assumption turned out to be wrong, as device drivers aren't resumed when the wake-up is cancelled by acpi_ec_dispatch_gpe
:(
My next idea was to use s2idle_set_ops
to override the .wake
callback with a custom function for Surface devices. This also turned out to be difficult, as all the other standard callbacks that need to be set in platform_s2idle_ops
are not exported by the kernel.
So I think we are left with either (a) adding a (rather larger) quirk to acpi_s2idle_wake
to check the lid status for Surface devices or (b) exporting all required acpi_s2idle_*
callbacks for custom platform_s2idle_ops
in surface_gpe_init
.
Hmm, IIRC systemd has some timeout (for lack of a better word) that prevents the system from reacting to lid events directly after being woken up, but that doesn't sound like that would not be relevant here... Maybe there's something similar for suspend in general? Apart from that I have no idea.
Yeah, HoldoffTimeoutSec
has no effect unfortunately. I couldn't find any other related options.
Hi, I'm experiencing the same issue, is there any progress on fixing it ? Thanks
Issue
Whenever I turn my Surface into suspend mode, it will wake up on lid (aka Typecover) closing, but not on lid opening.
This way unfortunately I can never put my Surface into Suspend and then close the lid. Therefore currently, I am running Suspend with a 5 seconds delay, so the lid can be closed before Suspend is executed. When the lid is closed before Suspend is initiated, the Surface remains in Suspend afterwards.
However, the Suspend mode is not interrupted on lid opening either, even though the Typecover (aka lid) starts illuminating the keys after a few seconds delay. No key will wake the device, only the Power Button will do this.
My current workaround is to deactivate the Surface GPE: "sudo modprobe -r surface_gpe" ... after which I can close and open the lid without affecting the Suspend mode of device. I have blacklisted the module for now.
Expected behaviour
Surface does not wakeup at all on closing the lid/Typecover.
Environment
`dmesg` output
``` [304232.588710] PM: suspend entry (s2idle) [304232.704155] Filesystems sync: 0.115 seconds [304232.853405] Freezing user space processes ... (elapsed 0.005 seconds) done. [304232.858440] OOM killer disabled. [304232.858444] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. [304232.860030] printk: Suspending console(s) (use no_console_suspend to debug) [304232.882933] ipts 0000:00:16.4-3e8d0870-271a-4208-8eb5-9acb9402ae04: Stopping IPTS [304233.204481] intel_pch_thermal 0000:00:14.2: CPU-PCH is cool [35C] [304238.700076] OOM killer enabled. [304238.700080] Restarting tasks ... [304238.700180] ipts 0000:00:16.4-3e8d0870-271a-4208-8eb5-9acb9402ae04: Starting IPTS [304238.700295] usb 1-7: USB disconnect, device number 26 [304238.703891] mei_hdcp 0000:00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04: bound 0000:00:02.0 (ops i915_hdcp_component_ops [i915]) [304238.706328] done. [304238.714049] ipts 0000:00:16.4-3e8d0870-271a-4208-8eb5-9acb9402ae04: Device 1B96:001F ready [304238.730492] PM: suspend exit [304240.171717] usb 1-7: new full-speed USB device number 27 using xhci_hcd [304240.325215] usb 1-7: New USB device found, idVendor=045e, idProduct=09c0, bcdDevice= 0.07 [304240.325232] usb 1-7: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [304240.325238] usb 1-7: Product: Surface Type Cover [304240.325243] usb 1-7: Manufacturer: Microsoft [304240.334708] input: Microsoft Surface Type Cover Keyboard as /devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.0/0003:045E:09C0.0013/input/input348 [304240.392417] input: Microsoft Surface Type Cover Mouse as /devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.0/0003:045E:09C0.0013/input/input349 [304240.392999] input: Microsoft Surface Type Cover Consumer Control as /devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.0/0003:045E:09C0.0013/input/input350 [304240.393310] input: Microsoft Surface Type Cover UNKNOWN as /devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.0/0003:045E:09C0.0013/input/input351 [304240.393619] input: Microsoft Surface Type Cover Touchpad as /devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.0/0003:045E:09C0.0013/input/input352 [304240.394009] input: Microsoft Surface Type Cover UNKNOWN as /devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.0/0003:045E:09C0.0013/input/input353 [304240.394275] input: Microsoft Surface Type Cover UNKNOWN as /devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.0/0003:045E:09C0.0013/input/input354 [304240.394553] input: Microsoft Surface Type Cover UNKNOWN as /devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.0/0003:045E:09C0.0013/input/input355 [304240.394893] input: Microsoft Surface Type Cover Tablet Mode Switch as /devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.0/0003:045E:09C0.0013/input/input356 [304240.395130] input: Microsoft Surface Type Cover Tablet Mode Switch as /devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.0/0003:045E:09C0.0013/input/input357 [304240.395419] input: Microsoft Surface Type Cover Tablet Mode Switch as /devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.0/0003:045E:09C0.0013/input/input358 [304240.395708] input: Microsoft Surface Type Cover Tablet Mode Switch as /devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.0/0003:045E:09C0.0013/input/input359 [304240.395947] input: Microsoft Surface Type Cover Tablet Mode Switch as /devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.0/0003:045E:09C0.0013/input/input360 [304240.396173] input: Microsoft Surface Type Cover Tablet Mode Switch as /devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.0/0003:045E:09C0.0013/input/input361 [304240.396407] input: Microsoft Surface Type Cover Tablet Mode Switch as /devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.0/0003:045E:09C0.0013/input/input362 [304240.396620] input: Microsoft Surface Type Cover Tablet Mode Switch as /devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.0/0003:045E:09C0.0013/input/input363 [304240.396846] input: Microsoft Surface Type Cover Tablet Mode Switch as /devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.0/0003:045E:09C0.0013/input/input364 [304240.397040] input: Microsoft Surface Type Cover Tablet Mode Switch as /devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.0/0003:045E:09C0.0013/input/input365 [304240.397446] hid-multitouch 0003:045E:09C0.0013: input,hiddev0,hidraw0: USB HID v1.11 Keyboard [Microsoft Surface Type Cover] on usb-0000:00:14.0-7/input0 [304243.702776] mwifiex_pcie 0000:01:00.0: info: trying to associate to bssid 00:e0:20:5e:2a:9d [304243.725664] mwifiex_pcie 0000:01:00.0: info: associated to bssid 00:e0:20:5e:2a:9d successfully ```