Alright, status update. It’s an EC bug. I thought I read once that the Framework EC firmware was/would-be open-source? I think the EC should be more configurable.
This fixes the problem but then you can’t wake the PC up again 
echo "Y" | sudo tee /sys/module/acpi/parameters/ec_no_wakeup
Disabling everything in /proc/acpi/wakeup doesn’t prevent wakeups, only ec_no_wakeup but that disables everything including the power button 
We’re getting ready to pull this out of beta, so I need to make sure I have everything straight.
Thanks
Any news about the multiple people who reported that the steamdeck charger stopped working with the framework after the update?
I don’t think that’s related to the new version, as I already have this problem with the old BIOS.
Sorry, allow me to be clear.
We expect default behavior for the default config. The default config and the config we test is lid close suspend, lid open resume.
You indicated you changed the default behavior. You changed the behavior to lid close null and are experiencing the new behavior if lid close resume when you have suspended this laptop using the non-default method. Is this not correct?
While I understand this isn’t ideal behavior and certainly not what is intended. The default action and purpose of the lid is to suspend it at this time unless it has been changed. In this case, it has.
Ideally, this would not be the case and it’s certainly valuable feedback on having the ability to disable the lid behavior entirely.
But, at this time, we are focused on default expected out of the box behavior at this time. Not custom tweaks made to HandleLidSwitch=.
Moving on, feedback received and appreciated.
Does anyone have feedback on other issues that they are experiencing?
Overall, for out of the box behavior, this appears to be a significant improvement over 3.02 and we will be releasing this out of beta tomorrow.
Is the issue with the graphical artifacting on resume resolved in the release version of the firmware?
In the event this was not yet tracked, I was able to capture a dmesg log today, and can share it if it can be of any assistance.
2 posts were merged into an existing topic: [RESPONDED] Graphical corruption in Fedora 39 (AMD 3.03 BIOS)
Only issue I’ve encountered is suspend seeming to break entirely with the kernel param “nvme.noacpi=1” set. Fedora 39 beta, 64GB DDR5-5600,WD SN850x, kernel version 6.5.8. This isn’t particularly surprising given this kernel option disables a workaround for suspend related to nvme drives, but as far as im aware it worked fine on the intel boards.
Updating via EFI, it’s been stuck like this for a while now, does that mean it’s done ?
Sorry for the dumb question and thanks for any answer
@Matt_Hartley @Kieran_Levin Any feedback on the charging issues with BIOS 3.03? Not only about the Steam Deck Chargers not working at all, but also about showing a battery full LED when the battery isn’t completely charged.
I had the same issue earlier in the thread, as long as you have the 4 green checkmarks in the bottom right, you can press the power button to turn off. You will want to re-run the BIOS update to properly downgrade the PD firmwares, which didn’t work for me until I used the official Framework charger during the BIOS update.
For some reason, when using my apple charger, the BIOS update would hang at that exact spot.
Strange though, because I did use the framework charger. Everything seems to be working fine so far anyway. Thanks for the reply
While it should charge with compatible chargers, my focus is does it work as expected with Framework chargers with this particular release. It does with Framework chargers.
If there issues with other compatible chargers, feel free to open or add to a thread and we can get this to the engineering team.
Per our guide and per AMD, no, this is not to be used. This is for Intel only.
If it’s set on AMD it’s going to cause major problems for suspend.
With the overwhelming benefits seen in upgrading 3.02 to 3.03, I am pleased to announce we are releasing 3.03 as a release and is no longer beta.
Feedback given on this release has been cataloged and passed on.
Does this mean the current 3.03 is now considered stable or will there be a different release of 3.03 as stable? This is a little ambiguous to me.
As with previous BIOS updates that have gone from beta to release, there is no change to the BIOS update file, it will just be linked as release on the BIOS/Drivers page on the support site. If you have already updated to 3.03 you don’t have to do anything else, and you can even recommend others come to this thread to get the installer file (otherwise they can go here: Framework Laptop BIOS and Driver Releases (AMD Ryzen™ 7040 Series) though it seems this page has yet to be updated with the new release as of the writing of this response).
It’s updated.
Correct. Today was the last day of beta. 3.03 is the stable release - we want folks off of 3.02.
Can confirm. I thought I was hallucinating that it ever worked, but I’m glad I’m not the only one. Thankfully, my primary charger (a 60 W Aukey dual port GaN charger) still works.
