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
Ah, I mightâve misunderstood which solution you wanted. My first idea was to make the system suspend back again if itâs woken up with the lid closed, because from @Kieran_Levinâs description it sounded like the firmware waking the OS when the laptopâs plugged or unplugged is just the new normal in this S3-less world weâre now in, and is not actually Framework-specific. So deal with the spurious wakeup rather than trying to make it not happen. But now Iâm not sure.
Spurious wakeup is rather problematic. Given that the system can cycle the AC-DC state when youâre fully charged, your system never sleeps if left on the charge. That means you should just shutdown or hibernate if youâll leave it to charge. Almost makes me not want to use sleep at all and just make my system hibernate the moment the lid is closed just to have a predictable behaviour.
I just was discussing this with our friends at AMD. One thought they had is that when the system wakes up from a lid open or ac adapter event, these will be happened by the kernel s2idle loop.
As part of the wakeup process, they thought there may be a second interrupt that is triggered. For example a GPIO event that also transitions as part of the S0i3->S0 which may cause linux to stay awake.
This may be a good exploration direction.
I donât have a laptop in hand yet to try this with, but I bet you could use this indicator with a systemd timer that runs say, every 30s. If the lid is closed for two consecutive events, you put the system to sleep.
Hacky, but workable 
Alright, hereâs the deal. I disabled the Lid Switch /sys/*/power/wakeup, but that didnât do it. Me and a friend did some more testing and found out that when you close the lid, it sends two wake-ups, one from the Lid Switch and another is a wake-up from the keyboard! When you plug in the AC, it also sends a keyboard wake-up! Iâll post some udev rules soon to disable this soon!