[Announcement] Linux on your Framework Laptop 13 (AMD Ryzen 7040 Series)

The GPU drivers (or firmware) are definitely not ready for prime time yet. A lot of what I do is GPU accelerated, and even in vanilla Gnome I’ve been getting regular (compositor?) crashes and a lot of mesa errors in my logs. Maybe that 3.03 firmware update will help, or maybe we need to wait for mesa updates. I dunno, it’s too bad, but to be honest I knew I was getting myself into early adopter territory. Hope you can find a workaround for your issues. Seems like the hardware will be fantastic with the software catches up.

1 Like

Oh how weird, when I used the KDE spin I believe I was getting monitor outputs but the crashes would occur and would affect all displays including the internal monitor while your issue sounds like it doesn’t affect the internal display. Do you get DE crashes or freezing when using the laptop stand-alone?

Wholeheartedly agree, for the moment I’ve installed my previous generation board which I kept close in case this happened and will revisit this once the BIOS is out and sentiment changes on its stability.

1 Like

No, the internal display is unaffected, and I get no crashing, but I’m not using the KDE spin. I installed the standard gnome workstation version then installed KDE packages on top of that.

When you said you were losing display to external monitors connected through a dock I thought you might be hitting my issue, but if it affects your internal display you’re hitting something different.

The AMD BIOS 3.03 is available now!


As @junaruga has been awesome enough to point out, a beta release of 3.03 BIOS is out - you will absolutely want to upgrade to it.


FYI for anyone who is compiling their own kernel: with the AMD mainboard, for your touchpad to work, you will need to have CONFIG_PINCTRL_AMD enabled (along with CONFIG_I2C_HID_ACPI as mentioned on the Gentoo wiki page). I had to do a bit of guesswork to see what might be missing from my kernel config.


Fedora Official spin with the firmware update has resolved the issues I was having from previous posts, yet to try KDE. Dock worked straight away with my multi-monitor setup on boot and didn’t die when I unplugged it while logged in.

This is with gnome, right? I’d be very interested in whether you get display output through the dock with KDE + Wayland session.

Works great with sway. I have an external monitor directly connected via usb-c and a second connected through a usb-c hub connected to hdmi. All three monitors work well, no errors, stuttering or other oddities we have been seeing with the earlier firmware.

I think what I have is specific to KDE/sddm, Wayland, docks, and late gen AMD igpus.

Anything outside of that specific combination seems to work fine.

Good advice. Winblows is even known to change linux partition guids because reasons…

Yet another reason I kept the dual boot separate, using an expansion card for Ubuntu Linux.

Still waiting for my Ryzen laptop (batch 4). Question: How long does it take after power on until you get a login screen using Ubuntu 22.04 ?

I see currently that the APU has been given 512MB of dedicated VRAM. Is there any option in the BIOS to increase that amount? I think that would fix the display flickering issues (or at least delay it for a long while).

You can set the UMA buffer to UMA_GAME_OPTIMIZED which gives a larger memory block to the GPU. I doubt this would fix or delay display flickering but worth a try if you wish to.


New guidance (added to Fedora 39, step 6 (Fedora39-amd-fw13.md) for Fedora 39 users experiencing weird artifacts on the screen (blotchy, etc)

(Note, this workaround may be unneeded as it is difficult to reproduce, however, if you find you’re experiencing the issue described here, you can implement this boot parameter)

Open a terminal window from Activities, paste in the following:

sudo grubby --update-kernel=ALL --args="amdgpu.sg_display=0"



Thanks, with this, I see that 4GB has been allocated to the GPU. So far, in steady state, I’ve been using around 1.1GB-1.4GB of the allocated GPU memory. I’ll be better able to test how soon the display flickering happens tomorrow.

Appreciate this update. Okay, let’s sit on this parameter for a day or so, then report back. If all is well, please let me know so I cam make a note of it.

So far, here’s all the display changes that I’ve done (display issues for me would occur after one of these display changes):

  1. Start with internal display only
  2. Switch to two external displays, with internal display off (2560x1440, 165Hz)
  3. Switch back to internal display only
  4. Sleep
  5. Resume from sleep, internal display only
  6. Switch to two external displays, with internal display off (2560x1440, 60Hz)
  7. Switch back to internal display only
  8. Sleep
  9. Resume from sleep, internal display only
  10. Switch to two external displays, with internal display off (2560x1440, 165Hz)
  11. Switch back to internal display only

After all of that, there is an increase in the allocated GPU memory usage, around 1.7GB-2.0GB, depending on how many things I have open. So there is a gradual increase, but I don’t know if that’s because KDE (or Edge, or Firefox, or Alacritty, etc.) is somehow leaking GPU memory, or the amdgpu driver is leaking GPU memory. However, with the old UMA config, where only 512MB was given to the GPU, I would previously have display issues at around step 6 or 7, so it is a definite improvement.

It’s likely that assuming I don’t log out and log back in (my previous workaround for these display issues would be to either log out or kill sddm/my user session), I would eventually run into the same display issues. However, that timescale is longer than what it was previously.

My setup:

  • Self-compiled 6.5.8 kernel (so this, by itself, deviates from the recommended kernel version, but I’m fine with doing a bit of debugging if something goes wrong)
  • Ubuntu 22.04.3, with KDE Plasma 5.24.7 and sddm 0.19.0, both from the jammy-updates pocket of the standard repos

Generally speaking, I tend to lean towards leaking happening at the applications listed first, unless identified elsewhere clearly. Browsers can be big offenders.