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:
Do you acknowledge that this is a defect?
Do you have a plan to remedy it?
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.
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
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.
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.
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?
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?
I was also experiencing this problem on the Framework 16 which I purchased in the early part of 2025. I took to putting my laptop to sleep with a looping bash script that returned the laptop to sleep after ten seconds unless a charger was connected. I configured this script to count the number of wakeups and discovered that my laptop would typically wake from sleep four or five times on my commute to work. This would occur whether I was commuting by car or by train. On one occasion, I had over twenty wakeups on one trip even after applying some of the fixes I found here.
I eventually tracked my FW16 problems down to the fact that the numpad is a distinct input device with its own wake behavior. I’ve been using the following script for the past few days:
#!/bin/bash
# Disable the display lid switch.
echo "Disabling lid switch"
echo disabled >/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:4b/PNP0C09:00/PNP0C0D:00/power/wakeup
# Disable the touchpad's ability to wake the laptop
echo "Disabling wakeup for touchpad"
echo disabled > /sys/devices/platform/AMDI0010:03/i2c-1/i2c-PIXA3854:00/power/wakeup
# Disable the various USB devices' abilities to wake the laptop
ls -1d /sys/bus/usb/devices/* | while read line; do
if [ -e "$line/product" ]; then
product="$(cat "$line/product")"
if echo "$product" | egrep 'Laptop 16 Keyboard Module|Laptop 16 Numpad Module' >&/dev/null; then
if [ -e "$line/power/wakeup" ]; then
echo "Disabling wakeup for USB $(basename "$line"): $(cat $line/manufacturer) $(cat $line/product)"
echo "disabled" > "$line/power/wakeup"
fi
fi
fi
done
# Sleep
xfce4-session-logout -s # If you're not using XFCE4, put your own sleep command here.
The loop here is probably over the top, but I wanted to make sure I found the two keyboards (the primary keyboard and the numpad) even if they somehow wound up on a different port on the bus. I’ll note that I used to just disable wake for these devices on boot, but I saw the keyboard wake behavior set back to enabled on a few occasions. I’m not sure what software caused this — I’m on Debian 12.10 in case that helps — but setting the wake properties of the devices just before suspending has been sufficient for me.
I generally agree with some of the comments here: it seems a bit bizarre to me that the machine is allowed to wake from sleep when the lid is closed, especially because the devices that are waking it are physically inaccessible with a closed lid. At the very least, it’d be nice to have the option to disable this wake behavior from the UEFI so that I didn’t have to play these exciting games with my OS. Nonetheless, I’ve found the problem to be avoidable so long as all of the input devices’ wake behaviors are disabled.