I could’ve sworn I saw this happen once in Windows as well without any changes made to lid close behavior. Haven’t had time to test more in depth though.
But I put my Framework into sleep by pressing the power button, closed the lid, and saw my monitor at my desk light up a few seconds later.
Haven’t been at my desk much since then though to know if it was a one-off.
Unless you accidentally woke the laptop up by hitting a key on an external keyboard, or perhaps nudging the external mouse (both of which I have done in the past), that sounds like you reproduced this issue. Also I see above in the thread that it’s been reproduced in Windows by at least one other person.
@Matt_Hartley can we please get a clarification whether a laptop suspended while the lid is open then resuming on lid close is acknowledged as a bug? Obviously not to be addressed in the 3.03 cycle, seems to have missed that window, just that it’s in the backlog.
For what it’s worth, my current 11 gen FW laptop does not have this bug, and neither had any of previous work laptops (ThinkPads), running various Linux distros, for years/decades before.
I also observe this on Linux.
If I put the notebook into Standby (via the start menu) and then close the lid, it turns back on.
That’s definitely an issue if one would then, unknowingly, put the notebook in a bag, where it could potentially overheat.
Yeah, and again, it also happens when you unplug power after it went to sleep … so it’s not just the lid. So when you put it to sleep with closing the lid, and leave it on the table, and then unplug it to put it in the bag later, it will also turn on by the unplug-event again and also overheat.
For systemctl suspend, then lid close resume, an internal ticket has been filed internally.
In the meantime, we are recommending using default suspend config method with the lid.
For now, this is the recommendation.
I updated the main post with other strange wake behaviors and updated the title
Please keep this thread confined to the resume-on-lid-close bug. If you’d like to make a separate thread for the power-related issues, I encourage you to do so, but unless it’s clear that they’re related, it’s best to keep them separate. They’re similar symptoms, but they’re very likely unrelated.
I didn’t realize this might affect Intel 12/13 platforms too.
@Morpheus636 re: relationship to other symptoms: To the extent this could be due to the EC, I wonder if BIOS 3.19 regresses this on 11th gen laptops too (emphasis mine):
Enhancements
Update Intel CSME package to 5.0.42.2235v2 Corporate.
Move to shared EC branch with 11th, 12th, 13th gen.
The two I have access to are still on 3.17 pending non-Windows installation method. It would be great if someone with 3.19 on a 11th gen machine could try to reproduce the resume-on-lid-close/AC power change behavior.
I don’t know if this is relevant to this thread but my machine (running Arch Linux and bios version 3.02) wakes up when the lid is closed when I plug it to charge it. I believe it goes back to sleep quickly after the KDE sound notification plays however. It’s just rather odd, I don’t know if that’s normal or intended.
I don’t believe it does. AMD edition uses a separate EC branch and entirely different UEFI firmware.
I know this was mentioned that someone else can reproduce this, but I just got home and tested again, and can confirm that this behavior happens every time.
Just a heads up, an internal ticket has been filed internally. We have more immediate irons in the fire, but, it is on record.
Standard, expected lid behavior with lid close to suspend, lid open to resume is working.
Suspend THEN lid close is where we are seeing a resume taking place which is what I filed the internal ticket for.
Great ! Thanks for following up on this. 
Any chance to get a public list of issues identified and being worked on ? I understand there may be security sensitive issues sometimes but having a public list of functional issues like this one in the firmware or elsewhere in the stack (kernel…) would be useful.
Great question. Internal tickets are just that, internal by design. Some stuff however, ends up on Github when appropriate.
FYI I went back to 11th gen, and if you suspend and then plug in the charger, the system will wake.
Similarly on windows, if you suspend and then close the lid, the system will wake up to process the event and then go back to sleep again.
This is expected behavior because we have to send a SCI event to the APU to notify the OS that the system is now on AC. This needs to wake the OS so the OS sleep policy can change from AC->DC.
For example if you start sleeping on DC, the system will hibernate after some time on windows, but after you plug in AC, the system can stay in modern standby indefinitely.
On windows the OS will wake up to process the event, and then go back to sleep after a few seconds.
Then that could be an issue with Linux distros. Personally, on Arch Linux with KDE, if I close the lid on my laptop, sending it to hybrid sleep, and then plug it in to charge, it will wake up and stay awake, as I discovered last night. It doesn’t seem to process the lid being closed and simply goes awake because it’s been awoken by the firmware. Even worse with the behaviour of cutting AC when fully charged and letting the battery discharge to go back on AC for a moment; This behaviour seems to just keep my laptop awake.
Edit: This behaviour does not happen if my laptop went to hibernation. Since I use hybrid sleep unless the battery is low, it can sometimes wake up and behave in all the ways I’ve described.
Hmm, I wonder how this can be handled similarly in Linux. A kernel module? I was already thinking of writing one to handle this after seeing a framework kernel module on the Discord that was reading from the EC somehow.
Or maybe a service that runs on resume, checks if the lid is closed and re-suspends?
And I mean, what you’re saying makes sense but I’ve not seen this behavior before. Is this behavior some new standard behavior? Still, the ability to disable to disable wakes would be cool.
There are plenty of options for running a script of your choice on power and lid events, so this shouldn’t be hard to accomplish, yeah, no kernel programming needed.
The hard part is not conflicting with everybody else who thinks they should drive the computer: if systemd thinks it owns power events, and GNOME thinks it owns power events, and acpid thinks it owns power events… it’s a mess, especially if e.g. you want things to work both on a kernel console and in a desktop environment—or maybe even in more than one.
At some point my old laptop would occasionally wake up and immediately go back to sleep again, because two services were racing to put it in suspend and one of them winning did not kill the other. Then it stopped doing that. And I had to give up on figuring what part of the GNOME monolith was responsible for that mess. (At this rate, I’m going to have to give up on GNOME itself because of all this opaqueness, but I don’t wanna…) And I could never get it to wake up reliably if I closed the lid and opened it back again too quickly.
Fundamentally, the problem seems to be that lid, power, etc. events are edge- rather than level-triggered, that is, the question is not “the lid is currently closed, what state do we want the system to be in?”, but “the lid just closed, what do we do?” That’s just a bad approach in general, but other systems can get away with it because they have much less software diversity than the Linux ecosystem (which obtains most of its value from that diversity).
Sorry for the rant. TL;DR is you should be able to patch this over with a script, but the most reliable approach is likely to be figuring out what responds to lid and power events on your system, then tracking down its developers and slapping them with this bug (gently) until they fix it. Or at this point you might as well fix it yourself.
ACPI is a very messy affair. This wakeup is coming from the EC and I haven’t been able to disable it through /proc/acpi/wakeup. Based on my light research, it needs to be read from the EC through the so I’m not going to bet on any universal solution being picked up for quirks like this.cros module
Scratch that, I’m making some process on disabling wakeups using udev