Strange, I am now unable to reproduce the problem anymore.
I will try more test and come back here to report if I find something.
Udev workaround is set to a one liner in the docs; looks for the file, if there, stops. If not, creates and appends the needed bits. Ubuntu team has been notified as well.
1 Like
Uhm, is there a tutorial to curb all this aggressive wake up behavior? I hoped for 3.05 to fix these annoyances but unfortunately there was no improvement in this department.
The framework constantly wakes up when interacting with it. Closing the lid of a sleeping FW wakes it, plugging in a charger wakes it (even when the lid is closed)… Worst is when you want to use the laptop a few days later only to discover that the battery is empty.
I expected some teething issue for early adopters of the AMD framework and BIOS fixes in due time but its been half a year now with next to no progress. 
Yes, you can fix this by adding a udev rule. You just need to copy the rule in this post to /etc/udev/rules.d/20-suspend-fixes.rules and reboot.
3 Likes
@Ceremony, from @Mario_Limonciello’s post, it seems this issue should be fixed in Kernel 6.7+. I had the Suspend with lid while attached to power workaround in place until Kernel 6.7 (or later, I can’t remember exactly). But, currently I’m on Kernel 6.8.6-200.fc39.x86_64 (Fedora 39) and have not experienced this issue without the workaround for many weeks now.
If you’re still running into the lid wakeup issue, you could upgrade to the latest kernel. Or, if that’s not an option, apply the workaround until you can upgrade to Kernel 6.7+.
1 Like
That “fix” was just a work-around, that they didn’t want to be stuck with forever, so they made it apply only for firmware 3.03, assuming the next firmware would fix the real bug (in the firmware). But it didn’t, so in a later kernel patch release they’ll have to update it to also apply to 3.05
2 Likes
Ah, I see. Thanks for the clarification. I guess I’ve been getting lucky for the past few days as I updated my firmware to 3.05 as soon as it became available via the stable channel:
~ % sudo dmidecode -t bios
Place your finger on the fingerprint reader
# dmidecode 3.5
Getting SMBIOS data from sysfs.
SMBIOS 3.6.0 present.
# SMBIOS implementations newer than version 3.5.0 are not
# fully supported by this version of dmidecode.
Handle 0x0000, DMI type 0, 26 bytes
BIOS Information
Vendor: INSYDE Corp.
Version: 03.05
Release Date: 03/29/2024
Address: 0xE0000
Runtime Size: 128 kB
ROM Size: 32 MB
Characteristics:
PCI is supported
BIOS is upgradeable
BIOS shadowing is allowed
Boot from CD is supported
Selectable boot is supported
8042 keyboard services are supported (int 9h)
CGA/mono video services are supported (int 10h)
ACPI is supported
USB legacy is supported
BIOS boot specification is supported
Targeted content distribution is supported
UEFI is supported
BIOS Revision: 3.5
...snip...
I should probably put the workaround back in 
.
Yeah guys just sent this out a few days ago to extend it as that BIOS ended up going stable.
Hopefully it’s fixed properly in the next BIOS.
8 Likes
Thanks for commit, Mario!
I tried the udev rule and can confirm it to fix the lid-closing, and (un)plugging a power cable no longer wakes the laptop.
Looking forward to the next BIOS that fixes this annoyance for everyone on every kernel 
1 Like
Thank you Mario,
just looked into the linux kernel source code and saw your update in 6.8.8 with a link to this thread 
Track-pad also causes Framework 16 to wake up.
I think this happens a lot in my backpack. But you can reproduce it yourself by slightly opening the lid ans squeezing your finger to touch the track-pad.
Hm it seems to fail to sleep consistently when I put it in my backpack. :c
But I managed to reproduce how the trackpad is pushed down by grabbing the laptop when closed.
I am highly irritated right now:
GPP0, SWUS, SWDS, GPP2, GPP5, GPP6, GPP7, GPP8, GP11, SWUS, GP12, SWUS, XHC0, XHC1, XHC2, NHI0, XHC3, NHI1, XHC4
These are the ACPI names selected by Framework.
Many manufacturers use intuitive names like TPAD for their Trackpad.
To my knowledge, there is no way to look up what these device names means other than asking the manufacturer.
1 Like
FYI the s2idle script does some stuff that will help you decode them.
On FW16 it should be these:
2024-06-28 11:48:52,936 DEBUG: I2C HID devices
2024-06-28 11:48:52,936 DEBUG: | "PIXA3854:00 093A:0274 Mouse" [PIXA3854] : \_SB_.I2CD.TPAD
2024-06-28 11:48:52,936 DEBUG: └─"PIXA3854:00 093A:0274 Touchpad" [PIXA3854] : \_SB_.I2CD.TPAD
1 Like
I suppose one solution is to add a script that during wakeup, if the lid is closed, make it go back to sleep again immediately.
Suspend is a difficult animal to deal with, because there are so many different use cases. One solution will not suit everyone. So, some people would want to use this script, and some would not.
My use case is simple. I would be happy if the only thing that woke up the laptop was me pressing the power button.
There is also the use case where I have plugged in external keyboard, mouse, screen and wish the laptop to stay powered on with the lid closed. But, one cannot get at the laptop power button with the lid closed so that use case is a problem to start with.
Name one use case where I would want to wake my laptop from sleep using the internal track pad while the lid is closed.
related: XKCD 1172
Edit: no, I do not think squeeze to wake counts.
4 Likes
Well, one could probably write a script to disable the keyboard and touchpad when going into suspend, leaving only the power button left to wake up, and then have a script on wakeup to enable the keyboard and touchpad.
For Linux, there is a feature called “unbind” and “bind” that can be used to obtain the above functionality.
E.g. the following stops the keyboard working for 5 seconds (tested on a FW16):
echo 1-4 >/sys/bus/usb/drivers/usb/unbind; sleep 5; echo 1-4 >/sys/bus/usb/drivers/usb/bind
The following stops the mouse working for 5 seconds (tested on a FW16)
echo AMDI0010:03 >/sys/bus/platform/drivers/i2c_designware/unbind; sleep 5; echo AMDI0010:03 >/sys/bus/platform/drivers/i2c_designware/bind
The following script disables the keyboard and trackpad during suspend on a FW16.
You can wake up the laptop by pressing the power key.
I tested by clicking on: “Power icon” → suspend.
Here is a script to do it:
Create the file: /usr/lib/systemd/system-sleep/keyboard-mouse-disable-sleep
#!/bin/sh
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
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
Note: The script is not perfect. It leaves the lights on on the keyboard during suspend, so uses 5W during suspend instead of the normal 2W. I will add the turning the lights off, when I find out how.
You can turn off the USB wakeup files for keyboard and I2C wakeup files for trackpad and it can block them from waking the system.
But I personally feel this is something the EC should be doing when the lid is closed to not let any events go through.
1 Like
How can you make the laptop, when suspended NOT to wake up when a key is pressed regardless of whether the lid is closed or not