So it’s waking up because something causes a keyboard/trackpad touch/tap/click? That’s really weird with the lid closed…
Sounds like something pushes up against the lid, and it flexes enough to push the screen into a key or something causing it to activate. It shouldn’t be doing that, flexing that much, should it?
The lid on the 16 flexes a lot - enough to be able to click the trackpad / keyboard when in a stuffed backpack evidently. I can click it through the lid by hand as well.
If the keyboard/tracpad aren’t going to sleep while… sleeping, then that may also drastically affect the power savings. Keyboard’s + Tracpad draw about 0.8W in my testing
From what I’ve heard, S0ix power draw is still going to be the worst offender while suspended. RIP S3…
This probably needs comments from FW on feasibility, but I think it would be best if the EC cut the power to keyboard and trackpad while the lid is closed.
There shouldn’t be any reason for them to be powered and as @RandomRanger points out that’s a pointless sizable power draw.
Odd that the keyboard was still awake. The upper input modules have a sleep pin which is connected to the EC. I thought it was supposed to put to modules sleep whenever the laptop is closed. And as such, you shouldn’t even need any configuration in the OS. I don’t know about the touchpad, I would have it thought it has a similar sleep function.
Oh; right this might be caught up with Selective Suspend. Windows can use this feature from a descriptor advertised by the keyboard, but AFAICT this actually was removed in the QMK firmware due to other problems.
The QMK firmware does use the sleep signal, but it’s only for turning off the backlight and reducing scan rate it seems to me.
So the issue shouldn’t be the EC cutting power - it already gives a sleep signal. But does the EC send a lid open/closed signal? If not; I think that’s what is missing so that it can behave differently when lid is closed.
We were just discussing the keyboard behavior last week! and if we should change this to avoid key-presses in bags during suspend.
Hardware wise we have a sleep hardware indicator to the keyboards, and this is controlled by the OS transitioning between S0 and sleep.
We were discussing if we should change this control signal from a sleep indicator to a lid closed indicator. And block key events from the keyboard in sleep.
Cutting power to the input modules on lid closed is possible in hardware, but I think we run into OS issues where usb will detect a disconnect, and the OS will wake up again. Which causes problems with properly entering sleep. @Mario_Limonciello is there a way we can disconnect devices from usb in a safe way during suspend entry, and exit to prevent the os from waking again?
We have spent some time debugging selective suspend issues in QMK, as we see when it is enabled, you can lose hid packets to the host, which results on stuck keys on resume if you wake up by key press, this has a low failure rate, but still enough to be buggy.
We also found using the MSOS2 descriptor was not always applying selective suspend settings correctly in windows.
Selective suspend support for HID is not enabled in windows/linux by default due to poor device support.
Potentially higher power consumption with lid opened sleep
Backlight might stay on for lid opened sleep
However it would definitely help this issue while still allowing wake from keyboard when lid is opened.
In terms of disconnecting devices I don’t think this would block sleep but yeah it would be a weird experience that they disconnected at suspend and came back.
So in summary I think that using the sleep signal as a lid signal instead sounds like the best plan to me.
I also confirm that the Framework 16 is, so far, unreliable when it comes to suspend:
s2idle feels like a technological regression compared to S3. I understand Framework is not to blame for this first point though.
I have seen it failing to suspend, with at least one stacktrace related to the amdgpu driver.
I have seen it suspending then waking too early while transported in a backpack.
I have just seen it not waking at all (possibly freezing?) after suspend (I had to long-press the power button to shut it down).
That being said, I cannot complain too much for I do not use an officially supported kernel (I use Debian Sid and its 6.7.9 packaged kernel instead of Ubuntu 22.04).
The elements above were harvested as part of my normal, regular use of the laptop, but I will try to experiment in a more rational way with better logging and tooling, as suggested by Mario.
I have experienced a 2nd instance of freezing on resuming.
Details:
the laptop was suspended through “systemctl suspend” while its lid was closed, its main screen disabled and various other devices connected through a dock, including 2 DisplayPort monitors.
I pressed a key and noticed no reaction
I opened the lid: the screen was still disabled and I noticed the keyboard was not responding to the hotkeys (e.g. Fn+space to increase backlight); same for the numpad.
At this stage, I consider the laptop is frozen and can only long-press the power button to shut it down.
Like the 1st time it happened, regular system logs do not help. The last log entry before the next boot is simply “kernel: PM: suspend entry (s2idle)”.
More than a week has passed since my previous post and… I did not get any suspend-related troubles in the meantime. Presumably, I have been subconsciously avoiding a situation that used to trigger those issues, but I cannot pinpoint what exactly.
Note : I have not switched to the 3.3 BIOS yet.
The lid on the 16 flexes a lot - enough to be able to click the trackpad / keyboard
I also noticed a series of ‘k’ characters appeared in a text editor after I dusted the laptop with the lid closed, but I cannot reproduce it at will.
I’m on Ubuntu 24.04 beta with kernel 6.8.0-22-generic #22-Ubuntu and suspend works perfectly for me. I had problems with suspend until I updated the kernel from 6.8.0-11 to 6.8.0-20.
I was having issues on 22.04 LTS (with OEM kernel) that would result in it going to sleep properly, but I opened the laptop again within like 30 seconds the screen would completely glitch out and either just look broken (graphical), or wouldn’t turn on the screen at all. And I had the same issue with 23.10 with the latest mainline kernels.
Since switching to 24.04 Beta with the latest kernel that comes with it, everything has worked absolutely perfectly 100% of the time when it comes to the display and sleep so far.
Glad to hear it’s doing better on Ubuntu, but I just had the issue happen tonight again - put my laptop in the bag and it woke up & drained the battery again. This is on a newly updated archlinux, kernel 6.8.7
Yeah this needs to get fixed. The thing work up in my bag. When I pulled it out the thing was almost too hot to touch. Now I have to wonder if that may have damaged the system. I had this issue with a MBP I had back in 2006. Sensor was screwed up overheated in the bag and then I spent 8 months back and forth with Apple as the system would crash randomly after that until they finally replaced the motherboard.
FW 16 with GPU on Fedora 39. Used the guide to set it up.