[TRACKING] Framework AMD Ryzen 7040 Series lid wakeup behavior feedback

I configure my machines to not suspend on lid close, I only suspend on power button press. Nothing is plugged in except expansions. The issue is that after I suspend my machine and close the lid, it wakes up due to the lid close event.

And besides that bug, personally I don’t want my suspend/resume to be controlled by the lid. For instance, I carry two laptops in my backpack, I don’t want the speaker magnet in one triggering the lid-open/close event on the other.

This is happening at a BIOS/EC level it seems, outside of any distro/OS settings.

Several things are triggering wake-ups that I think are incorrect:

  • Lid close
  • USBC power plugged in
    • Especially if laptop is closed
  • FW AC USBC unplugged
    • Especially if laptop is closed


  • Suspend any OS on an AMD board or Intel 12th+ gen FW
  • Close the lid or Plug a charging cable or Unplug a FW charging cable
  • The laptop wakes from suspend, even while closed
    • Potentially closed and/or stored without airflow
1 Like

This falls outside of expected default behavior, so not sure what to suggest here. While using HandleLidSwitch=ignore can help in preventing lid suspend, lid resume when suspended with the lid open is going to be a thing.

Well, resume on lid close seems wrong.

I just tested this, on a default config, lid close provides expected behavior of suspending the laptop.

Once we start changing default behavior, that is into completely different territory. I appreciate your feedback, but the default, tested behavior is working as expected.

I’m sorry, but just to be clear… you expect that after suspending the laptop while it is open… and then closing the laptop… you expect that the laptop wake itself back up?


I can reproduce this on 03.03, and agree that this behavior isn’t something that traditionally has happened on other machine I have used.

That said, in the event I needed such an option, I would be satisfied with disabling the lid sensor. If even as just a fallback until it can be sorted out in the firmware, provided the firmware is the root cause of this behavior.


Alright, I’ll move on. I changed it back to suspend on lid close. But my desktop environment gives me a button to suspend, and I still have the same behavior without my customization (which I did with KDEs settings menu).

It should be documented that users shouldn’t use the ‘Suspend’ buttons in Linux desktop environments because Framework only supports suspend on lid close. Otherwise they’ll close their laptop thinking it’s suspended and it will wakeup on close and overheat in their bags/backpacks.


I have an AMD machine incoming soon and this is one of the issues I’m keeping an eye on. For @Enzious and/or anyone else that can reproduce this I’d be grateful if you have the time to look at these possible narrow-down questions:

  • Is this a regression from 3.02 to 3.03, or a pre-existing issue that 3.03 did not address?

  • What happens with alternatives for the enter-suspend method other than the KDE desktop button:

    • Power button
    • Other desktop (just for testing), e.g. GNOME quick menu
    • systemctl suspend
    • any others I’ve missed
1 Like

@dimitris This is not a regression. It’s currently expected behavior as the support lead discussed above. It is completely outside the realm of user configuration unfortunately. Any source that suspends (button, DE power menus, logind/elogined, acpid, etc) outside of suspend on lid close, will behave the same and will need to be avoided/disabled as a suspend source.

EDIT: lol, I thought of a solution. Remove the magnet LOL. It seriously drives me that crazy haha
EDIT2: I ended up just de-soldering the hall effect sensor :man_shrugging:

1 Like

Following this lid close suspend issue, so the expected behavior if someone generally does not like to close the lid to suspend (to save wear and tear on hinges if the computer is going to remain on a desk) and has suspended via software, if they need to pack up and take the laptop somewhere is to wake the computer back up, then close the laptop and hope it goes to sleep and put it in their bag?

Hopefully my Framework will do this better than my Dell laptops have. I have pulled scalding hot laptops with a nearly dead battery out of my bag because the laptop didn’t go to sleep correctly and stayed on when I closed the lid. So I had changed my usual practice to always sleep/suspend with the power button and make sure that the system completely suspended (screen off, fans off, lighted power button off) before closing the lid and packing it in a bag.

Just one more vote for an updated option to not wake up when closing the lid of an already sleeping laptop…


It doesn’t matter how the system suspended: power button, menu item, idle time, command line. Closing the lid shouldn’t cause the system to wake up. Simple as that.


I understand that you’re seeing lag in the bootloader, and that is an issue that you should contact support about.

I’m not asking you to install fedora to your drive, just to check if a fresh distro on a live USB resolves any issues (this is a usual first step that support would ask you to test).

That said, since you are seeing issues in both Linux and Windows, it seems like the best option for you is to contact support and ask for more in-depth help. Its possible that you are experiencing hardware issue that just happened to show up when you updated, or a bad firmware update causing you extra trouble.

I’m going on the assumption that it is"expected" in the sense of a known issue to be fixed with a BIOS/EC update.

Curious also whether this happens with Windows. If it’s strictly BIOS/EC it should happen there too.

1 Like

I remember bunch of coworkers walking to/from meetings, holding an open laptop, because closing/reopening messes everything up. That was like a decade ago. I guess the more things change, the more they stay the same.

Jokes aside, I’d appreciate just a simple BIOS option to disable the sensor, so the software (OS) doesn’t even realize it has one. We don’t want people needing to take extreme actions like desoldering parts, right?

I much prefer full control over the thing, even if it takes an extra manual step. Suspend, close, walk… Open, press power button to wake it back up. NO BIG DEAL!


I would very much prefer this over the default behaviour and I would use it as standard conf rather that as a workaround.

1 Like

I could’ve sworn I saw this happen once in Windows as well without any changes made to lid close behavior. Haven’t had time to test more in depth though.

But I put my Framework into sleep by pressing the power button, closed the lid, and saw my monitor at my desk light up a few seconds later.

Haven’t been at my desk much since then though to know if it was a one-off.

@DHowett has also reproduced it on Windows.

Unless you accidentally woke the laptop up by hitting a key on an external keyboard, or perhaps nudging the external mouse (both of which I have done in the past), that sounds like you reproduced this issue. Also I see above in the thread that it’s been reproduced in Windows by at least one other person.

@Matt_Hartley can we please get a clarification whether a laptop suspended while the lid is open then resuming on lid close is acknowledged as a bug? Obviously not to be addressed in the 3.03 cycle, seems to have missed that window, just that it’s in the backlog.

For what it’s worth, my current 11 gen FW laptop does not have this bug, and neither had any of previous work laptops (ThinkPads), running various Linux distros, for years/decades before.

I also observe this on Linux.

If I put the notebook into Standby (via the start menu) and then close the lid, it turns back on.
That’s definitely an issue if one would then, unknowingly, put the notebook in a bag, where it could potentially overheat.

Yeah, and again, it also happens when you unplug power after it went to sleep … so it’s not just the lid. So when you put it to sleep with closing the lid, and leave it on the table, and then unplug it to put it in the bag later, it will also turn on by the unplug-event again and also overheat.

1 Like