It happened to me recently when I closed the laptop’s lid and put it in my backpack. Unfortunately it hadn’t suspended successfully and this caused overheating, draining the battery and risking potential hardware damage.
I always check if I can hear the fans after closing the lid, but the laptop was silent.
In this case some kind of kernel issue probably occured and the system got completely stuck before actually going to sleep. If I could tell, I would have force-shutdown the machine.
Does the laptop not have any LEDs on the side to provide feedback?
I just ordered my first FW (the 16.25 batch 7) and this sounds extremely frustrating. I’ve had it happen to me with Lenovo laptops, which is why I always check the LED on the power button at the side to make sure the Lenovo has suspended properly…
I can think of at least one instance where your OS is definitely responsible. Please include the necessary information. OS and also what bios version you are on.
On older FW13 an FW16, there have been reports of the laptop waking while in a backpack.
There are work arounds. For example on my FW16, i have disabled all wakeup except with power button.
In that way, even opening the lid does not wake it. I open lid, see it still asleep, and press the power button to wake it.
FW will fix all the wake problems eventually, but the work around is acceptable to me.
BIOS version is 03.04. I’ll edit the description and add it. (EDIT: can’t edit the description…)
As I wrote, the kernel most likely crashed while suspending. Why does it matter if it’s Linux (it is) or Windows? This thread is not about fixing the OS from crashing (has happened only once so far), but for figuring out the state of the machine without opening the lid.
Will try peeking from the side to see if the light around the fingerprint reader is visible, as @2disbetter mentioned.
Little known fact if you are on Linux (which I am as well) and you are on one of the two most likely suspects Fedora or Ubuntu (since they receive full support)…you are 1. very likely on a systemd based distro and 2. also likely on Gnome…in which case you will experience the following: systemd defaults to allowing the desktop environment to handle power events such as suspend and since gnome removed certain values from dconf specifically related to lid closing it is now difficult→impossible to hand that back off to systemd without breaking a ton of stuff that is handled correctly by the desktop environment and making it something you need to manage. So while I ran into this wonderful gnome dev decision, and began working through the process of having systemd handle it … I lost motivation since the easy work around is to manually suspend, then close the lid, and move on.
So that is why the OS matters in conjunction with the desktop environment being used.
This is neat. I just tried it and it worked for me! Much appreciated. It is worth noting that this overrides the charging lights, so if you are plugged in while the laptop is asleep, your lights will be blue (not orange/white).
This would make a great feature request for Framework.
Isolating the LED’s from each side is likely buried in the EC code on GitHub much like the power LED brightness. Even if it was active on both sides but only during sleep that would still be a win.
There is code already in place for the PowerLED on the fingerprint reader to fade in and out, I wonder if an additional call could be made to these side LED’s and just reuse the same code for the powerbutton and the side LED’s at the same time and have it clear states when it resumes again just like pressing the power button or opening the lid.
Curious if some logic could be put in place to ignore the Sleep LED state on that side if something is plugged into the USBC slot that way the Charging LED could still remain on that side and the sleep state could still be visible on the opposite side.
All of this is exceeding easier to type in than actually implement in the EC code.
One last thought I had was to wire an LED in parallel to the fingerprint reader and have it sitting right next to the LED inside the case so that it would shine close to the little hole the one on that side of the board does. This way it doesn’t require drilling an extra tiny hole on one side and cosmetically looks like a factory case.
You are correct if the lid is closed it does turn it off. I am remembering that if I have walked away for an extended period of time with it open that when it goes into standby and the screen is off that the slow flash on the power button/fingerprint reader is happening. I just presumed that was driven by the EC. That part of it might even be in the original Chromium code it was adapted from.