This is now in 6.7-rc7 and I can confirm it works for me, thanks!
1 Like
I have a brand new 7640U with the 3.03 BIOS, Fedora 39.
When I set the max charge to 80% in the BIOS, have the laptop plugged, close the lid, it is going to sleep without issue. But when it reaches 80% it is waking up.
If I set the max charge to 90 or 100%, I don´t have the issue and it keeps sleeping when it reaches the max charge.
It will also wake up when it is sleeping without being connected to the mains and if I connect the charger to an USB-C port.
If you reproduce the behavior with the s2idle script you can confirm what the wake source is when this happens. Just program the script for longer than it takes to charge up and suspend with script instead of lid.
My guess is this is either an EC bug or it’s a manifestation of the keyboard wakeup bug.
You can manually turn off keyboard wakeup in sysfs or update to 6.7-rc7 or later to pick up the kernel workaround for the keyboard wakeup issue.
1 Like
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