Yes. I want it to sleep too when the lid is closed. But when the lid is open and the system is in suspend, that’s a mode where I want to be able to use the keyboard to wake up the system. I’ll post a script here once I get it to work.
I applaud you, just tested the script and does exactly what I need. Of course not a permanent solution, but it can do the job until a new BIOS patch rolls along.
Interesting. It has now been 24 days (and counting) since my last freeze-on-resume, i.e. we are getting close to a situation where the laptop just works ©.
The two noticeable changes in my habits are:
- suspending less often (but still suspending and resuming at least once per day)
- turning bluetooth off (bluetoothd is running but
bluetoothctl show | grep PowerreturnsPowered: no PowerState: off-blocked)
On Fedora 40, my laptop is also waking from sleep in my backpack. I have confirmed this several times by hearing the beep of a connection being made on my bluetooth headphones within about a minute of shutting the laptop lid and putting it in my backpack. They disconnect automatically upon shutting the lid, so I know that it is suspending at least initially.
4 Likes
The fact that there hasn’t been a UEFI update to fix this is frankly mind-boggling to me.
6 Likes
By the way, this issue also exists with the Framework 13 AMD, at least for the touchpad (at least my machine doesn’t wake from sleep by pressing a keyboard key, but it does from pressing the touchpad), and there too it can be activated by the lid/display when the laptop is closed.
Anyone else finding this topic when searching for the issue with their Framework 13 AMD, see Laptop powered off, battery empty after 3 days - #11 by Daniel_Gibson for a workaround (tell Linux not to wake from touchpad events)
1 Like
It has been quite some time since I last reported my experience in this thread.
Good news: since I applied “the two noticeable changes in my habits” (cf my previous message), my Framework 16 laptop successfully wakes up from s2idle sleep every time.
Of course, it is also possible that something was fixed by a kernel update (the laptop runs Debian Sid).
Bad news: I experienced the lid-hitting-the-keyboard-or-touchpad issue multiple times, both at home when the cat walks on the laptop (cat-proofing is the next step after dog-fooding) and when traveling. Regarding the latter, system logs confirm the laptop typically wakes up when I start walking. Depending on how long I walk and what is running on my laptop, it may or may not be burning hot when I finally take it out of my bagpack.
I intend to investigate whether I can configure the exact kind of events that wake up my system so as to work around that issue, but a firmware update that ignores all Framework input modules when the lid is closed would make sense.
3 Likes
Modifying my cheesy little script to account for lid state and multiple keyboards is left as an exercise for the reader
The script below targets USB and i2c devices so as to disable wakeup only for devices known to sit under the lid – the regex can probably be further adjusted to account for devices I do not own.
#!/usr/bin/env bash
state='disabled'
# Framework keyboard and numpad should not wake the laptop:
grep -l 'Framework' /sys/bus/usb/devices/*/manufacturer |\
sed 's/manufacturer$/product/' |\
xargs grep -lP 'Laptop 16 (Keyboard|Numpad) Module' |\
sed 's/product$//' |\
while read -r framework_keyboard_device;
do
echo "${state}" > "${framework_keyboard_device}/power/wakeup"
done
# The PixArt touchpad should not wake the laptop:
for pixart_device in /sys/bus/i2c/devices/i2c-PIXA*; do
echo "${state}" > "${pixart_device}/power/wakeup"
done
2 Likes
Here’s a systemd unit to run that script on boot for those wanting to quickly add it to their system:
[Unit]
Description=Prevents keyboard and trackpad from waking machine while lid is closed by calling /etc/disable-wakeup.sh
[Service]
Type=oneshot
ExecStart=/etc/disable-wakeup.sh
[Install]
WantedBy=multi-user.target
To add it, copy the above unit file and run:
sudoedit /etc/systemd/system/disable-wakeup.service
Paste the text. Save and exit your editor.
Copy Xavier’s script and run:
sudoedit /etc/disable-wakeup.sh
Paste the text. Save and exit your editor.
Then run these commands to “install” the new service:
sudo chmod a+x /etc/disable-wakeup.sh
sudo systemctl daemon-reload
sudo systemctl enable --now disable-wakeup.service
1 Like
@Peter_J_Stewart: nice – although, on my side, I simply dropped my script in /usr/lib/systemd/system-sleep/20-disable-wakeup.sh, as hinted by @Victor_Lowther. It seems there is no documented /etc counterpart to that /usr directory.
Additionally, since we are discussing scripts and workaround, here is my cat-proof script for Linux+X.org: it runs unprivileged but requires the DISPLAY environment to be set. Otherly put, it must be launched as part of the X session (possibly via XDG autostart). It polls the lid state and enables/disables all input devices underneath accordingly. That way, my cat can walk on the laptop without inputting anything.
#!/usr/bin/env bash
DEVICES=(
'Framework Laptop 16 Keyboard Module - ANSI Keyboard'
'Framework Laptop 16 Numpad Module Keyboard'
'keyboard:Framework Laptop 16 Numpad Module Consumer Control'
'PIXA3854:00 093A:0274 Mouse'
'PIXA3854:00 093A:0274 Touchpad'
)
script_name=$(basename "$0")
device_id_file="/tmp/${script_name}.ids"
if [ ! -f "${device_id_file}" ]; then
for device in "${DEVICES[@]}"; do
xinput list --id-only "${device}"
done > "${device_id_file}"
fi
current_state=''
known_state=''
function get_state {
[[ "$(</proc/acpi/button/lid/LID0/state)" =~ open ]] && current_state='open' || current_state='closed'
}
function state_changed {
[ "${known_state}" == 'open' ] && action='enable' || action='disable'
adjust_devices "${action}"
}
function adjust_devices {
local action="$1"
xargs -n 1 xinput "${action}" < "${device_id_file}"
}
function update_state {
get_state
if [ "${current_state}" != "${known_state}" ]; then
known_state="${current_state}"
state_changed
fi
}
function watch_state {
while sleep 5; do
update_state
done
}
if [ "$1" ]; then
adjust_devices "${1}"
exit
fi
watch_state
Damn. My FW16 failed to wake up from suspend again.
I noticed it was not entirely bricked though:
- the power button was still blinking
- upon removal of the touchpad, the small LED on the right side of the laptop started blinking red-blue-off, red-blue-off – presumably, the firmware was still reacting to that kind of events.
At this stage, I am running Debian Sid’s 6.10.12 kernel.
I recently installed Fedora 41 KDE and I like it so far, but I’ve noticed that since then, sometimes the laptop comes on inside my bag and bakes itself. It only seems to have started after I installed Linux, as it never did this when I was primarily using Windows. The odd part of it is that when I notice this happening and open it up, it doesn’t seem to actually be doing much of anything, i.e. it’s not at the login screen or anything, and I have to hold down the power button to force it to actually shut down from this state.
I’m honestly rather new to Linux in general, so I’m not sure how I would go about fixing this issue or even figuring out why it’s doing this. In the normal system settings there doesn’t seem to be any sort of “wake on keyboard” option, and I generally use the “shut down” option in the launcher anyway so I expect that it should only come back on with the power button, but for some reason it’s doing this behavior.
As far as I know I have the most recent BIOS as well, and I didn’t see any sort of relevant option there either, as far as I could tell.
Thanks in advance!
1 Like
Please search the forums before opening a new thread first. 
This issue has been discussed and solutions presented in this thread.
Thanks! I did try to search but must have missed this.
As many people have posted, this is an issue that is critical to fix— if the lid is closed the keyboard and touchpad should be powered down and absolutely should not wake up the machine. Requiring that the laptop lid be opened and the power button pressed to wake up would be much safer. Those who desire peripherals to wake the laptop should be the ones looking for workarounds here, not those of us who don’t want our laptops to drain their battery and possibly cause damage to the system. This is an issue that needs to be disclosed and addressed.
Wake-up in transit happens repeatedly and as mentioned in this issue and elsewhere can result in the laptop being stuck not-asleep and not-awake, with the only recourse being holding down the power button to turn it off.
That said i’d be thrilled if someone could adapt Victor_Lowther’s script workaround for NixOS; or perhaps as Ryan_McGee mentioned in May, there could be udev rules for both the keyboard and also the trackpad?
2 Likes
Nerd-snipe accepted.
This over-engineered NixOS module (git+https://codeberg.org/amyp/lappy-nix.git?ref=main#nixosModules.framework-lid-workaround if you’re into flakes) adds a hardware.framework.wakeOnInput option to control when input modules are allowed to wake the system.
I tried to get the best of all the solutions I’ve seen: udev is used for detection, so the script should work with multiple keyboard-like input modules (I don’t have anything other than the ANSI keyboard module to test with), no matter which positions they’re installed into; it should handle the keyboards on Laptop 16 and Laptop 13 (I don’t have a 13 to test with); it should handle the touchpads on both as well; and it should be much more specific about which devices are blocked, so e.g. external keyboards can still wake the laptop. I didn’t block the power button–is it really possible to press it with the lid closed?
Something that I haven’t seen in other people’s scripts: wakeOnInput = "lid-open" allows the keyboard/touchpad to wake the system, but only if the lid was open when the system suspended. It’s not as reliable as a proper firmware solution would be (e.g. supending then closing the lid will still allow keyboard/touchpad to wake the system, and that can’t really be fixed), but I wanted to see how well it would work for me.
If this seems like something others are interested in, I’d love to get some feedback and land it in nixos-hardware.
1 Like
We are planning on changing this in our next bios update cycle early next year. but this will have to be coordinated with a keyboard firmware update as well.
The current plan is to change the hardware GPIO sleep pin going to the keyboard to indicate lid closed. Then we can disable all keyboard presses when the lid is closed.
This will have an EC+Keyboard firmware change to support the new behavior.
11 Likes