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

Framework Laptop 13
92

Here are some of the things that can wakeup from sleep, there are others also.

Keyboard (when pressed):
echo disabled > /sys/devices/pci0000:00/0000:00:08.1/0000:c1:00.3/usb1/1-4/1-4.3/power/wakeup
Touchpad (when pressed):
echo disabled > /sys/devices/platform/AMDI0010:03/i2c-1/i2c-PIXA3854:00/power/wakeup
Power button (when pressed):
echo disabled >/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/power/wakeup
LID (when opening):
echo disabled >/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:4b/PNP0C09:00/PNP0C0D:00/power/wakeup
BATTERY (when low on charge):
echo disabled >/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:4b/PNP0C0A:00/power/wakeup

I guess the purpose of the BATTERY one is if one has suspended and sleeping and the battery gets too low to sustain it, it should really wake up and hibernate.
But if the hibernate is not working, it will just wake up and maybe get hot.

My preference that I would use is disable the Keyboard, Touchpad and LID open, leaving me to use the power button if I wish it to wake up.
At least this way, when I open the lid, and it is already awake, I know something must have gone wrong.

1 Like
93

For anyone interested:
Udev rules to disable keyboard and trackpad messing with stuff:

ACTION=="add", SUBSYSTEM=="usb", DRIVERS=="usb", ATTRS{idVendor}=="32ac", ATTRS{idProduct}=="0012", ATTR{power/wakeup}="disabled", ATTR{driver/1-1.1.1.4/power/wakeup}="disabled"
ACTION=="add", SUBSYSTEM=="usb", DRIVERS=="usb", ATTRS{idVendor}=="32ac", ATTRS{idProduct}=="0014", ATTR{power/wakeup}="disabled", ATTR{driver/1-1.1.1.4/power/wakeup}="disabled"

you can figure out your device ids using lsusb and grep/less

However I still have not figured out a udev rule for the trackpad. This is how far I have gotten so far:

ACTION=="add", SUBSYSTEM=="i2c", DRIVERS=="i2c_hid_acpi", ATTRS{ID_INPUT_TOUCHPAD}=="1", ATTRS{ID_INPUT_TOUCHPAD}=="1", ATTR{power/wakeup}="disabled", ATTR{driver/1-1.1.1.4/power/wakeup}="disabled"

feel free to point out the error in this.

6 Likes
94

But at least disabling keyboard wake seems to be good enough to not have it wake in my backpack.

2 Likes
95

Is there a timeline for this being resolved for good in firmware?

Because this proposed workaround is causing other issues.

2 Likes
96

Wow what a saga with this one since October 2023. A lot of good investigative work! This seems like it might be ideally setup as a future design specification with criteria like when lid is closed the laptop cannot be woken up by onboard input devices. My FW13 AMD is very new to me so I hadn’t yet uncovered any of this behavior myself. It would be nice to see this fixed in the firmware.

97

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
98

Will there be a BIOS fix for the FW16 too?

7 Likes
99

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

2 Likes
100

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
101

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.

102

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

1 Like
103

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
104

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
105

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

1 Like
106

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:

107

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
108

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
110

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.

111

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
112

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?