[TRACKING] Framework AMD Ryzen 7040 Series lid wakeup behavior feedback

Yes! We are in the process of releasing a bios update for AMD 13in Ryzen 7040 where this is going to be fixed! We found there was some BIOS code that was running on wake up causing this issue and it was finally root caused a few weeks ago, and we have a fix!

14 Likes

Will there be a BIOS fix for the FW16 too?

7 Likes

Hi, @Kieran_Levin. Any status update on this release? Thanks.

2 Likes

Has that BIOS been released, please? What is it (/ what will be) its version number? I fear that it has not yet been released. These things can take time but it would be good to hear about progress.

3 Likes

Will this also fix waking up from sleep when using the laptop closed connected to external monitor/keyboard/mouse? Currently having to open it open the lid and scoured the forums for a fix. Was pointed to this one from discord admin.

What about the FW16 ? Is a new bios is also in the process to be released for this big boy ?

1 Like

I just opened my backpack to once again find that my Framework 13 AMD (running firmware 3.0.5) is hot to the touch, with 30% of the battery depleted because it woke from sleep in my bag.

I’ve participated in other threads about this, and have only spotted a single months-old mention by a Framework employee acknowledging a firmware problem. Since then? Nothing.

I even switched from Arch to Fedora 41 with a complete stock installation to see if a blessed distro might solve the problem. It didn’t.

So, what I’d like to hear from someone at Framework is:

  1. Do you acknowledge that this is a defect?
  2. Do you have a plan to remedy it?
  3. By when?

I think it’s altogether reasonable to expect that my $1400 device should meet the bare minimum of functionality as a laptop, not a desk-bound device, which is to travel in a way that assures battery life is not degraded.

2 Likes

Try these udev rules, disables everything from waking except the power button:

/etc/udev/rules.d/69-suspend.rules:

ACTION=="add", SUBSYSTEM=="acpi", DRIVERS=="button", ATTRS{hid}=="PNP0C0D", ATTR{power/wakeup}="disabled"
ACTION=="add", SUBSYSTEM=="serio", DRIVERS=="atkbd", ATTR{power/wakeup}="disabled"
ACTION=="add", SUBSYSTEM=="i2c", DRIVERS=="i2c_hid_acpi", ATTRS{name}=="PIXA3854:00", ATTR{power/wakeup}="disabled"

Reboot to apply.

4 Likes

It would be nice to know if there is any workaround for us poor Windows users too!

1 Like

What is achieved by the suspend rules is just that is disables the “wakeup” functions.
Windows has a way to disable wakeups.
A quick google finds:

Don’t wanna sound like I am saying the obvious, but I had a very similar issue + wake up black screen + restarts, and the way to fix it was simply to set up my own config in

/etc/systemd/logind.conf

with

[Login]
SleepOperation=suspend
HandleLidSwitch=suspend
HandleLidSwitchExternalPower=suspend
HandleLidSwitchDocked=ignore

In my case, it seemed like Fedora 41 was defaulting to suspend-then-hibernate which was breaking my laptop, as I did not set up hibernation at all

2 Likes

While these are helpful, they shouldn’t be necessary. It seems clear that Framework is avoiding taking responsibility for a defect and clearly communicating if and how they intend to remediate it. Very disappointing.

1 Like

I now understand that second rule isn’t for the keyboard and I used the udev rule from betalars for the keyboard. The keyboard backlight stays on as a couple other people have mentioned, I would be interested in a rule or script that turns it off.

You will need to install “qmk_hid” somewhere to control the backlight of the keyboard so it switches off before suspend.

This is the script I use:

#!/bin/sh
# This file should be placed in: /usr/lib/systemd/system-sleep

PATH=/sbin:/usr/sbin:/bin:/usr/bin

case "$1" in
        pre)    #echo AMDI0010:03 >/sys/bus/platform/drivers/i2c_designware/unbind
                #echo 1-4 >/sys/bus/usb/drivers/usb/unbind
                /home/qmk_hid/target/debug/qmk_hid via --backlight 0
                echo disabled > /sys/devices/pci0000:00/0000:00:08.1/0000:c1:00.3/usb1/1-4/1-4.3/power/wakeup
                echo disabled > /sys/devices/platform/AMDI0010:03/i2c-1/i2c-PIXA3854:00/power/wakeup
                echo disabled >/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:4b/PNP0C09:00/PNP0C0D:00/power/wakeup
                exit 0
                ;;
        post)   #echo AMDI0010:03 >/sys/bus/platform/drivers/i2c_designware/bind
                #echo 1-4 >/sys/bus/usb/drivers/usb/bind
                exit 0
                ;;
        *)      exit 1
                ;;
esac
1 Like

I thought I was crazy or I misconfigured my Arch system causing random wakeups in my backpack. Seeing that this has been known for a year and the lackluster response from Framework is a little disappointing.

In addition to waking up, it would sometimes cause my screenlocker to receive multiple failed login attempts, and when I pull out my laptop I sometimes find myself locked out of my account for 10 minutes. Extremely frustrating.

At least we have a fix coming, but it’s been a couple months since this message. Where’s the communication? Is this just to prevent unintended wakeups? Or does it also address the keyboard backlight not turning off upon suspend?

There is already a new bios update available that should fix it.

Fix what? I mentioned two issues. Do you know which version?

Atleast the wakeup should be fixed.

Thanks. I might prefer to wait until it’s not a Beta release.

EDIT: The fix isn’t released for FW16 yet

1 Like

To be clear, on the FW13 this shouldn’t normally be an issue, as Framework had earlier submitted a kernel-side workaround that essentially disables keyboard wakeup on then-current firmware 3.04, and a further update to the version check when 3.05 did not fix the issue:

So if you’re running Arch on the FW13, haven’t deliberately switched to a non-default (e.g. stable) kernel, and haven’t deliberately passed the kernel parameter that disables the workaround, you should not be seeing wakeups.

Cannot say anything about the FW16. Note this thread is about the 13 only, so perhaps consider speaking out in the one about the 16?