I configure my machines to not suspend on lid close, I only suspend on power button press. Nothing is plugged in except expansions. The issue is that after I suspend my machine and close the lid, it wakes up due to the lid close event.
And besides that bug, personally I don’t want my suspend/resume to be controlled by the lid. For instance, I carry two laptops in my backpack, I don’t want the speaker magnet in one triggering the lid-open/close event on the other.
This is happening at a BIOS/EC level it seems, outside of any distro/OS settings.
Several things are triggering wake-ups that I think are incorrect:
USBC power plugged in
Especially if laptop is closed
FW AC USBC unplugged
Especially if laptop is closed
Suspend any OS on an AMD board or Intel 12th+ gen FW
Close the lid or Plug a charging cable or Unplug a FW charging cable
This falls outside of expected default behavior, so not sure what to suggest here. While using HandleLidSwitch=ignore can help in preventing lid suspend, lid resume when suspended with the lid open is going to be a thing.
I can reproduce this on 03.03, and agree that this behavior isn’t something that traditionally has happened on other machine I have used.
That said, in the event I needed such an option, I would be satisfied with disabling the lid sensor. If even as just a fallback until it can be sorted out in the firmware, provided the firmware is the root cause of this behavior.
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:
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…
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!
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.