[RESPONDED] Waking from suspend w/ lid closed

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.

2 Likes

I tried doing this - was able to reproduce the wake up while running the script. Here’s the output:

2024-03-22 11:51:15,251 INFO:	○ Suspend count: 2
2024-03-22 11:51:15,251 INFO:	○ Hardware sleep cycle count: 2
2024-03-22 11:51:15,252 INFO:	○ GPIOs active: ['58']
2024-03-22 11:51:15,252 INFO:	○ Wakeups triggered from IRQs: [9, 7]
2024-03-22 11:51:15,252 DEBUG:	Used Microsoft uPEP GUID in LPS0 _DSM
2024-03-22 11:51:15,252 INFO:	○ Woke up from IRQ 9 (IR-IO-APIC 9-fasteoi acpi)
2024-03-22 11:51:15,253 INFO:	○ gpe0B increased from 359 to 395
2024-03-22 11:51:15,253 INFO:	○ gpe10 increased from 0 to 2
2024-03-22 11:51:15,254 DEBUG:	ACPI Lid (/proc/acpi/button/lid/LID0/state): closed
2024-03-22 11:51:15,254 ERROR:	❌ Userspace suspended for 0:01:22.856203 (< minimum expected 2:30:00)
2024-03-22 11:51:15,254 DEBUG:	Kernel suspended for total of 0:01:08.738000 (82.96%)
2024-03-22 11:51:15,255 ERROR:	❌ In a hardware sleep state for 0:00:03.910461 (4.72%)
2024-03-22 11:51:15,258 DEBUG:	BAT1 charge level is 2749000 µAh
2024-03-22 11:51:15,258 INFO:	🔋 Battery BAT1 (NVT FRANDBA) is operating at 103.19% of design
2024-03-22 11:51:15,258 INFO:	Explanations for your system
2024-03-22 11:51:15,258 WARNING:	🚦 Kernel ringbuffer has wrapped
2024-03-22 11:51:15,259 WARNING:	🚦 Kernel is tainted
2024-03-22 11:51:15,259 WARNING:	🚦 Userspace wasn't asleep at least 2:46:40
2024-03-22 11:51:15,259 WARNING:	🚦 System had low hardware sleep residency

I’m unsure what device is supposed be represented by IRQ9 or IRQ7… Here’s the full log if it helps.

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.

Yeah that above log jives. IRQ7 is for the GPIO controller and GPIO 58 is for pme the XHCI controller.

I would try turning off the wakeup file for the internal keyboard from sysfs.

2 Likes

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.

@Kieran_Levin can you see if that’s possible?

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.

That sounds like a great idea.

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.

2 Likes

Ahhh.

The only real downsides I see with this approach:

  • 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.

As long as when lid is open, still allow keyboard signals.

Also, what will happen if I have the OS (Linux specifically) to not suspend on lid close? Will it suspend regardless with this change?

This is just the action of keyboard during sleep or lid close he’s talking about. It wouldn’t affect setting Linux to not suspend on lid close.

Gotcha. Ok, great.

Would this be a QMK firmware update? I assume there has to be some OS-side software as well to send the lid-closed signal?

Looks like Kieran and Mario are working through some ideas. We’ll know more as this evolves.

1 Like

I also confirm that the Framework 16 is, so far, unreliable when it comes to suspend:

  1. s2idle feels like a technological regression compared to S3. I understand Framework is not to blame for this first point though.
  2. I have seen it failing to suspend, with at least one stacktrace related to the amdgpu driver.
  3. I have seen it suspending then waking too early while transported in a backpack.
  4. 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.

1 Like