I don’t think it’s an overkill since if you can press a key or touchpad, you can press the power button. Disabling the keyboard and touchpad on suspend regardless of whether the lid is closed allows further power saving.
1 Like
But fully disabling vs disabling wakeup is my point. Just turn off wakeup and it can be done with a udev rule.
1 Like
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
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
But at least disabling keyboard wake seems to be good enough to not have it wake in my backpack.
2 Likes
Is there a timeline for this being resolved for good in firmware?
Because this proposed workaround is causing other issues.
1 Like
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.
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?
6 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:
- 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.
1 Like
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.
3 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.
(post deleted by author)