Compositor freezes when Plugging in a particular screen

Aeto · November 4, 2025, 2:46pm

Hello,

I use Fedora KDE Plasma Edition on my Thinkpad T590 which is plugged into a dock and I had two external screens connected. One 4K60 Screen and one 1080p60 Screen. Both connected via DisplayPort.

I recently updated my system which included the Plasma 6.5 update and ever since, when my 4K screen is plugged in the entire computer freezes. In this update there was also a Kernel update from 6.17.5 to 6.17.6 but I since tried an older Kernel version and the issue remains, which makes me think this is an issue related to the 6.5 update of KDE Plasma.

At first I thought my entire install was broken, when I started my computer this morning I got nothing but a black screen. When I unplugged my laptop from the dock and tried booting again it worked fine. Plugging it back into the dock made it freeze again.
The computer runs well as long as the 4K screen is not plugged in.

I have checked the journalctl -f output, and I do get a few errors.

I wasn’t sure if I should report this as a bug, or leave here in the forums.
Last night my two screens both worked fine. This is pretty annoying, but I don’t have much time to find a solution now, because I have work to get done and I guess I have to live with my center screen not working for now.

Aeto

journalctl -f
Nov 04 14:19:08 fedora audit\[1\]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg=‘unit=sssd-kcm comm=“systemd” exe=“/usr/lib/systemd/systemd” hostname=? addr=? terminal=? res=success’
Nov 04 14:19:10 fedora PackageKit\[2891\]: refresh-cache transaction /2159_deaabdec from uid 1000 finished with success after 3020ms
Nov 04 14:19:11 fedora PackageKit\[2891\]: get-updates transaction /2160_bebcdaab from uid 1000 finished with success after 880ms
Nov 04 14:19:19 fedora chronyd\[1360\]: Selected source 85.220.190.246 (2.fedora.pool.ntp.org)
Nov 04 14:19:53 fedora systemd\[1933\]: Starting systemd-tmpfiles-clean.service - Cleanup of User’s Temporary Files and Directories…
Nov 04 14:19:53 fedora systemd\[1933\]: Finished systemd-tmpfiles-clean.service - Cleanup of User’s Temporary Files and Directories.
Nov 04 14:21:18 fedora kwin_wayland\[2265\]: :1:14095: Could not resolve property: #linearGradient10962
Nov 04 14:21:18 fedora systemd\[1933\]: Started app-Alacritty@7bb81f83dc474e6d9616c36d469c2f0c.service - Alacritty - Terminal.
Nov 04 14:21:18 fedora plasmashell\[2452\]: :1:14095: Could not resolve property: #linearGradient10962
Nov 04 14:21:18 fedora kwin_wayland\[2265\]: :1:14095: Could not resolve property: #linearGradient10962
Nov 04 14:21:40 fedora kwin_wayland\[2265\]: Atomic modeset test failed! Invalid argument
Nov 04 14:21:40 fedora kwin_wayland\[2265\]: Atomic modeset test failed! Invalid argument
Nov 04 14:21:40 fedora kwin_wayland\[2265\]: Atomic modeset test failed! Invalid argument
Nov 04 14:21:40 fedora kwin_wayland\[2265\]: Atomic modeset test failed! Invalid argument
Nov 04 14:21:40 fedora kwin_wayland\[2265\]: Atomic modeset test failed! Invalid argument
Nov 04 14:21:40 fedora kwin_wayland\[2265\]: Atomic modeset test failed! Invalid argument
Nov 04 14:21:40 fedora kwin_wayland\[2265\]: Atomic modeset test failed! Invalid argument
Nov 04 14:21:40 fedora kwin_wayland\[2265\]: Atomic modeset test failed! Invalid argument
Nov 04 14:21:40 fedora kwin_wayland\[2265\]: Atomic modeset test failed! Invalid argument
Nov 04 14:21:40 fedora kwin_wayland\[2265\]: Atomic modeset test failed! Invalid argument
Nov 04 14:21:40 fedora kwin_wayland\[2265\]: Atomic modeset test failed! Invalid argument
Nov 04 14:21:40 fedora kwin_wayland\[2265\]: Atomic modeset test failed! Invalid argument
Nov 04 14:21:40 fedora kwin_wayland\[2265\]: Applying output configuration failed!
Nov 04 14:21:40 fedora kwin_wayland\[2265\]: Atomic modeset test failed! Invalid argument
Nov 04 14:21:40 fedora kwin_wayland\[2265\]: Atomic modeset test failed! Invalid argument
Nov 04 14:21:40 fedora kwin_wayland\[2265\]: Atomic modeset test failed! Invalid argument
Nov 04 14:21:40 fedora kwin_wayland\[2265\]: Atomic modeset test failed! Invalid argument
Nov 04 14:21:40 fedora kwin_wayland\[2265\]: Atomic modeset test failed! Invalid argument
Nov 04 14:21:40 fedora kwin_wayland\[2265\]: Atomic modeset test failed! Invalid argument
Nov 04 14:21:40 fedora kwin_wayland\[2265\]: Atomic modeset test failed! Invalid argument
Nov 04 14:21:40 fedora kwin_wayland\[2265\]: Atomic modeset test failed! Invalid argument
Nov 04 14:21:40 fedora kwin_wayland\[2265\]: Atomic modeset test failed! Invalid argument
Nov 04 14:21:40 fedora kwin_wayland\[2265\]: Atomic modeset test failed! Invalid argument
Nov 04 14:21:40 fedora kwin_wayland\[2265\]: Atomic modeset test failed! Invalid argument
Nov 04 14:21:40 fedora kwin_wayland\[2265\]: Atomic modeset test failed! Invalid argument
Nov 04 14:21:40 fedora kwin_wayland\[2265\]: Applying output configuration failed!
Nov 04 14:21:40 fedora kded6\[2414\]: Failed to notify “Created too many similar notifications in quick succession”
Nov 04 14:22:01 fedora kded6\[2414\]: Failed to notify “Created too many similar notifications in quick succession”

dmaggot · November 4, 2025, 4:09pm

Can confirm. I just wanted to point out that if you disconnect the offending monitor(perhaps s?) the system goes back to working. For a while I was able to reproduce this directly from the kscreen KCM (Display Configuration) by enabling the additional monitor and applying the configuration: the screen froze after a few seconds, and would unfreeze after I disconnected the HDMI cable. After a reboot at least the kscreen KCM reports that the configuration was rejected (it reads “Couldn’t apply display configuration: The driver rejected the output configuration”) and no longer freezes, but I still cannot use my external monitor.

Aeto · November 4, 2025, 4:26pm

For me it is only one Monitor.
Has it also for you been happening since the 6.5 update?
I’m glad I’m not the only one.

Zamundaaa · November 6, 2025, 12:11pm

If it started happening with 6.5, 6.5.2 probably fixes it too. We found a regression that caused a workaround to not be applied anymore

Aeto · November 7, 2025, 12:12am

I see.
Then I’ll have to wait for Fedora to update to 6.5.2, and hope I guess.
Or I could switch to an earlier build of Fedora.
I’ll look into that.

Aeto · November 7, 2025, 2:18am

I just updated to 6.5.2, and it is fixed.
Thank you!
I am curious. What I have that the workaround fixed?

Zamundaaa · November 7, 2025, 1:20pm

When driving a screen, the GPU sends all pixels of a buffer to the display every frame. Doing that requires a lot of memory bandwidth, and potentially other hardware specific things, so at some number of screens + resolutions + bit depth you can exceed those limits, and the driver will not allow the compositor to turn all the screens on.

Because of driver API limitations, the “driver not allowing to turn all screens on” just means the compositor gets told “this doesn’t work”, rather than anything useful - the “freeze” is the compositor trying tons of more or less random things to try to turn the screens on anyways, until after sometimes a very long time it will stop and just turn screens off.

The workaround is one of those more or less random things: The compositor allocates the buffers with a different memory layout, in the *hope* that the different memory layout has lower memory bandwidth requirements (or lower requirements for those other hardware specific things) than the normal one. As it turns out, this workaround is shockingly often required!