I wonder if you’re hitting the same behavior I just filed a KDE bug for: losing display signal to external monitors connected through a dock. There’s a detailed description in my bug report but if you’re hitting the same thing, you should get display if you switch your session from Wayland to x11.
Since f38, I think the spin defaults to Wayland for sddm as well which causes immediate display loss as the login screen loads but if you use gdm it will bypass that.
If it is the same thing, it doesn’t seem to be specific to framework but rather is a more general AMD problem since I could reproduce on a non framework laptop.
Edit: editing for clarity, if it is the same problem, just logging out of Wayland and into x11 is not enough; once display output dies this way it doesn’t come back without a reboot so you have to get to x11 plasma session without touching Wayland and plasma/sddm together.
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.
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.
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.
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.
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 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:
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):
Start with internal display only
Switch to two external displays, with internal display off (2560x1440, 165Hz)
Switch back to internal display only
Sleep
Resume from sleep, internal display only
Switch to two external displays, with internal display off (2560x1440, 60Hz)
Switch back to internal display only
Sleep
Resume from sleep, internal display only
Switch to two external displays, with internal display off (2560x1440, 165Hz)
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