Just received my FW16 this week and am having some trouble with suspend on Arch Linux (EndeavorOS) + KDE. After suspending and putting the laptop in my backpack or just jostling it around with the lid closed, it wakes itself up and keeps the screen on, heating up in my bag and wasting battery.
When the laptop is on a flat surface and not moving, its able to stay asleep. I’m guessing keyboard / touchpad input isn’t being ignored when closed and triggers waking while in the bag? I’m dual booting and not able to reproduce on windows, so it doesn’t seem to be a hardware issue. Is there some configuration I’m missing for the keyboard or suspend?
I suggest reproducing it with scripts/amd_s2idle.py · master · drm / amd · GitLab orchestrating the suspend event to understand it.
Run the script and set the time for longer than you plan to be suspended. Then close the lid and use it as normal and look at what it tells you the wake source is.
You can modify the power/wakeup attribute for whatever it was to disable it if applicable.
Edit: Also of note, when opening the lid after it turns on by itself in my bag, the password field is filled with random keystrokes. Keys are definitely being pressed while the lid is closed, where I’d think it should be disabled.
Running this, I was able to stop the keyboard from waking up the machine (usb device found by running lsusb.py):
sudo tee /sys/bus/usb/devices/1-4.3/power/wakeup <<<"disabled"
But the touchpad clicking still wakes the laptop while the lid is closed. It seems the touchpad is an i2c device, and I’m unsure how to disable wakeup with it. Any ideas?
Also, I haven’t seen any other posts about this problem, so am I missing some sort of udev rule or package that’s supposed to stop this from happening?
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?
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.
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.