Alright, I’ll move on. I changed it back to suspend on lid close. But my desktop environment gives me a button to suspend, and I still have the same behavior without my customization (which I did with KDEs settings menu).
It should be documented that users shouldn’t use the ‘Suspend’ buttons in Linux desktop environments because Framework only supports suspend on lid close. Otherwise they’ll close their laptop thinking it’s suspended and it will wakeup on close and overheat in their bags/backpacks.
I have an AMD machine incoming soon and this is one of the issues I’m keeping an eye on. For @Enzious and/or anyone else that can reproduce this I’d be grateful if you have the time to look at these possible narrow-down questions:
Is this a regression from 3.02 to 3.03, or a pre-existing issue that 3.03 did not address?
What happens with alternatives for the enter-suspend method other than the KDE desktop button:
Power button
Other desktop (just for testing), e.g. GNOME quick menu
@dimitris This is not a regression. It’s currently expected behavior as the support lead discussed above. It is completely outside the realm of user configuration unfortunately. Any source that suspends (button, DE power menus, logind/elogined, acpid, etc) outside of suspend on lid close, will behave the same and will need to be avoided/disabled as a suspend source.
EDIT: lol, I thought of a solution. Remove the magnet LOL. It seriously drives me that crazy haha
EDIT2: I ended up just de-soldering the hall effect sensor
Following this lid close suspend issue, so the expected behavior if someone generally does not like to close the lid to suspend (to save wear and tear on hinges if the computer is going to remain on a desk) and has suspended via software, if they need to pack up and take the laptop somewhere is to wake the computer back up, then close the laptop and hope it goes to sleep and put it in their bag?
Hopefully my Framework will do this better than my Dell laptops have. I have pulled scalding hot laptops with a nearly dead battery out of my bag because the laptop didn’t go to sleep correctly and stayed on when I closed the lid. So I had changed my usual practice to always sleep/suspend with the power button and make sure that the system completely suspended (screen off, fans off, lighted power button off) before closing the lid and packing it in a bag.
Just one more vote for an updated option to not wake up when closing the lid of an already sleeping laptop…
It doesn’t matter how the system suspended: power button, menu item, idle time, command line. Closing the lid shouldn’t cause the system to wake up. Simple as that.
I understand that you’re seeing lag in the bootloader, and that is an issue that you should contact support about.
I’m not asking you to install fedora to your drive, just to check if a fresh distro on a live USB resolves any issues (this is a usual first step that support would ask you to test).
That said, since you are seeing issues in both Linux and Windows, it seems like the best option for you is to contact support and ask for more in-depth help. Its possible that you are experiencing hardware issue that just happened to show up when you updated, or a bad firmware update causing you extra trouble.
I remember bunch of coworkers walking to/from meetings, holding an open laptop, because closing/reopening messes everything up. That was like a decade ago. I guess the more things change, the more they stay the same.
Jokes aside, I’d appreciate just a simple BIOS option to disable the sensor, so the software (OS) doesn’t even realize it has one. We don’t want people needing to take extreme actions like desoldering parts, right?
I much prefer full control over the thing, even if it takes an extra manual step. Suspend, close, walk… Open, press power button to wake it back up. NO BIG DEAL!
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.
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.
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.
