[SP5] Wakes up from Suspend on lid closing (but not on opening) #1060
Comments
|
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.
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: `dmesg` output |
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:
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 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 @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!
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).
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. |
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 My next idea was to use So I think we are left with either (a) adding a (rather larger) quirk to
Yeah, |
|
Hi, |
|
Out of curiosity, what does the surface_gpe module do? I haven't taken a look at the code and I'm pretty bad at wrapping my head around kernel modules and the like. Since I don't know what it's actually doing, I didn't want to blacklist the module, so my version of the work around is temporarily removing it before sleep and reloading it after wake up through the following script in Incase anyone wants to use this workaround, make sure to set the script as executable. |
|
It essentially only prepares the GPIO pin associated with the lid to actually wake up the device when the lid is opened. Unfortunately as this issue shows it doesn't really work that well... (see discussion above). You can blacklist it without any other effects. It literally just deals with the GPIO pin. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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
The text was updated successfully, but these errors were encountered: