Hey,
Recently purchased a Framework 13 with AMD AI 300 series, installed Fedora 42 on it and I can’t get it to suspend on lid closed.
When I press the power button suspend seems to work,
When I close the lid it does not go to sleep (is hard to tell i just hear a very faded fan sound and when I open the screen is instant no flicker nothing is like it was already powered on)
I did leave it over the night with the lid closed and when I opened it the next day the screen was still on but this time the trackpad was not working, or the keyboad on the login screen, I had to switch to a terminal and reboot.
Anyone having suspend issue?
After some investigation I stumbled upon the fact that it does suspend fine via the power button, but somehow the lid close event wakes it up.
To work around this issue I’ve disabled lid close events by editing / adding /etc/systemd/logind.conf the following:
[Login]
HandleLidSwitch=ignore
HandleLidSwitchExternalPower=ignore
HandleLidSwitchDocked=ignore
Now I can suspend via the power button and close the lid and when I open the lid it simply resumes.
Can you please install this and use it to reproduce?
Just program a cycle for 20s or so and then close the lid. Share the report it generates and hopefully we’ll have a hint at what’s going on.
1 Like
Thanks for the reply, I’ve installed amd-debug-tools via pipx, supposely you wanted me to run amd-s2idle --test. I’ve run it the system entered sleep, I’ve closed the lid the system woke up once the lid was fully closed.
Can’t attach .md files so I’ve pasted it here # s2idle report created on 2025-05-25 22:56:11.217741 using amd-s2idle 0.2.1.pos - Pastebin.com
You’re not getting to the deepest state. That should be the focal area for debug.
Please do the following:
- Remove all USB devices (including cards and dongles).
- Turn off kernel lockdown (it’s turned on by secure boot with some distro kernels so turn off secure boot)
- Repeat the test. If it still happens the script will gather more information when lockdown is off. If it doesn’t, try to narrow it down to which USB device is causing it.
OK, done but no apparent change
- I’ve removed all expansion cards
- I’ve disabled secure boot from bios
The new output # s2idle report created on 2025-05-26 09:34:54.682583 using amd-s2idle 0.2.1.pos - Pastebin.com
Thank you for your support with this issue.
The good news; this actually looks like it’s getting to deepest state now compared to the other one. I suspect something USB was acting up.
The bad news; I see that the reason you’re waking up is that both the lid and GPIO controller are active:
PM: Triggering wakeup from IRQ 7
Dispatching Notify on [LID0] (Device) Value 0x80 (Status Change)
It seems to me that the active interrupt is GPIO 8 which should be the touchpad. Is it possible your lid is physically pushing on the touchpad?
OK, making progress, here is what I’ve tried now:
I’ve disabled the touchpad via gnome setting, when I sleep the device even a slight touch on the touchpad will wake it up.
I’ve tried the paper test covering the touchpad, when I close the lid normally it still wakes up.
If I close the lid really really slow it does not wake up
In my mind it looks like a hardware issue where on a hard close the touchpad will somehow touch and will trigger a wake. What do you think?
It does feel like how the touchpad is installed there being a physical press.
If you never “care” to wakeup from touchpad I would say use sysfs to disable touchpad wakeup using a udev rule.
I don’t care how about touchpad waking up, how will I go about disabeling touchpad wakeup using a udev rule?
Try modifying /sys/bus/i2c/drivers/i2c_hid_acpi/i2c-PIXA3854:00/power/wakeup from enabled to disabled manually. If that works you can use an LLM to help guide you to making a udev rule.
Got it, it works!
I think I should report this back to framework support, sound like a serious hardware issue?
Thank you very much for the support!