STEPS TO REPRODUCE 1. Boot computer 2. Arrive at SDDM login screens with both monitors working 3. Login to KDE OBSERVED RESULT Erratically one or both monitors loses signal and immediately powers down on login to Wayland KDE from SDDM. It is normally one screen but occasionally both. This is remedied with a reboot though it sometimes takes a few reboots before both both screens appear during login to KDE Plasma. While going down before reboot both monitors are restored. EXPECTED RESULT Monitors should not power down during login to Wayland KDE SOFTWARE/OS VERSIONS Linux Kernel: 5.15.12-200.fc35.x86_64 KDE Plasma Version: 5.23.4 KDE Frameworks Version: 5.89.0 Qt Version: 5.15.2 Graphics Platform: Wayland ADDITIONAL INFORMATION This problem occurs on two computers with the same configuration. One computer uses Asus monitors and the other Samsung monitors. (So this problem is not monitor specific.) Graphics Card AMD/ATI Tonga Pro Radeon R9 38 series Kernel module amdgpu OpenGL Version 4.6 Mesa 21.3.3 Processors 8 x Intel Core i7-3770 CPU @ 3.40FHz Memory 16GB
I see this issue from time to time with Xorg in SDDM and I saw this issue in 5.23. After reworking how kwin_wayland searches for working output configuration, the issue seems to be gone. Please reopen this bug report if you can reproduce this bug with 5.24 beta or just 5.14.
@Vlad Zahorodnii Thanks - good to know that it is resolved in the next release. I will wait until February for the finished release. Cannot run beta or downgrade on these production machines.
(In reply to Vlad Zahorodnii from comment #1) > I see this issue from time to time with Xorg in SDDM and I saw this issue in > 5.23. After reworking how kwin_wayland searches for working output > configuration, the issue seems to be gone. Please reopen this bug report if > you can reproduce this bug with 5.24 beta or just 5.14. I have installed kde plasma packages 5.24.1-1.fc35 on both computers with dual displays but the same problem outlined in my earlier bug report persist. So this has not been resolved. Please let me know of any information I can provide to assist.
*** Bug 448173 has been marked as a duplicate of this bug. ***
Please enable debug logging and upload a log from when you log in and KWin fails to enable the outputs correctly. Then we can see if it's KWins fault, if KScreen is acting up or if something else is wrong. You can enable logging by putting QT_LOGGING_RULES="kwin_*.debug=true" into /etc/environment and rebooting. You can get the resulting log with "grep kwin_wayland_drm ~/.local/share/sddm/wayland-session.log", or if you're using the systemd session with "journalctl --boot 0 | grep kwin_wayland_drm"
Created attachment 147010 [details] Output from journalctl --boot 0 | grep kwin_wayland_drm This is the output of Output from journalctl --boot 0 | grep kwin_wayland_drm requested by Zamundaaa
(In reply to Zamundaaa from comment #5) > Please enable debug logging and upload a log from when you log in and KWin > fails to enable the outputs correctly. Then we can see if it's KWins fault, > if KScreen is acting up or if something else is wrong. > > You can enable logging by putting > QT_LOGGING_RULES="kwin_*.debug=true" > into /etc/environment and rebooting. > > You can get the resulting log with "grep kwin_wayland_drm > ~/.local/share/sddm/wayland-session.log", or if you're using the systemd > session with "journalctl --boot 0 | grep kwin_wayland_drm" Thanks, I have added an attachment with the output from "journalctl --boot 0 | grep kwin_wayland_drm" as requested. SDDM is started from systemd and there is no wayland-session.log
(In reply to SP from comment #7) > (In reply to Zamundaaa from comment #5) > > Please enable debug logging and upload a log from when you log in and KWin > > fails to enable the outputs correctly. Then we can see if it's KWins fault, > > if KScreen is acting up or if something else is wrong. > > > > You can enable logging by putting > > QT_LOGGING_RULES="kwin_*.debug=true" > > into /etc/environment and rebooting. > > > > You can get the resulting log with "grep kwin_wayland_drm > > ~/.local/share/sddm/wayland-session.log", or if you're using the systemd > > session with "journalctl --boot 0 | grep kwin_wayland_drm" > > Thanks, I have added an attachment with the output from "journalctl --boot > 0 | grep kwin_wayland_drm" as requested. SDDM is started from systemd and > there is no wayland-session.log In this session only one monitor was powered on after logging into Wayand KDE session from SDDM. (Both monitors were active before logging in.)
There also appears to be no difference with the output of kwin_wayland_drm taken after logging in to Wayland KDE with only one monitor powered on and second (after reboot) with both monitors powered on after logging in from SDDM into a Wayland KDE session.
Created attachment 147051 [details] Additional output from login to wayland session The output from logging into a wayland session today has more information than the previous posted output from journalctl --boot 0 | grep kwin_wayland_drm
Okay, so KWin fails to find a configuration that works with both monitors... I don't see much more useful information in that log though, we'll need drm kernel logging to find out more. I created https://invent.kde.org/plasma/kwin/-/wikis/Debugging-DRM-issues for that. You can just use the script on the bottom and run it from a tty, hopefully the kernel gives us a clear error message
Just to be clear - should I run the script from a tty before logging in with SDDM or after? (In reply to Zamundaaa from comment #11) > Okay, so KWin fails to find a configuration that works with both monitors... > I don't see much more useful information in that log though, we'll need drm > kernel logging to find out more. > I created https://invent.kde.org/plasma/kwin/-/wikis/Debugging-DRM-issues > for that. You can just use the script on the bottom and run it from a tty, > hopefully the kernel gives us a clear error message
Doesn't matter. It'll do its thing on the tty, no running sessions are affected
Created attachment 147076 [details] dmesg-drm-debug.log Attached is the dmesg-drm-debug.log requested by @Zamundaaa
(In reply to Zamundaaa from comment #13) > Doesn't matter. It'll do its thing on the tty, no running sessions are > affected ran your script - thanks. Could it be this? dce110_link_encoder_construct: Failed to get encoder_cap_info from VBIOS with error code 4!
Does anyone have further suggestions on this bug? It is very erratic. After some updates it appears to vanish - with both monitors powered on after logging into a desktop session from SDDM. Then after a few days it reappears. Currently, I have both monitors fired up on one computer consistently after login to a KDE desktop session for a few days - while on the other computer only one monitor is left powered on after logging in. It can take a few reboots before both monitors are left powered on after logging in. Generally, a full shutdown and restart fixes it - but not always. As I mentioned in my initial report - both computers have the same hardware and OS configuration and the same current updates. So this leads me to wonder if there is some cacheing of a configuration - or some error retained in memory that causes this? I guess the percentage of users with dual monitors is relatively small - but to some of us they are indispensable. Would very much like to have this bug fixed.
I suspect this has something to do with the way the files in ./local/share/kscreen are addressed. I experimented: 1. Moving all files and the output directory in kscreen to a backup directory and rebooting. Result - only one monitor powers on after logging in to KDE. The most recent configuration files in kscreen and its backup are identical. 2. Leaving the single recent file in kscreen and restoring all the old files in the output directory. Reboot. Result - only one monitor powers on after logging in to KDE. 3. Restore all the older configuration files in kscreen and reboot. Result - both monitors are powered on after logging in to KDE with the correct desktops. I am missing something here - but cannot figure it out. The older files in kscreen were written when I was running X11. Why would they make a difference in a Wayland session?
Following an update of mesa libraries yesterday it is taking numerous reboots to be able to login to a KDE Plasma Wayland session with both monitors powered on. Incredibly frustrating. Is it possible to configure the behaviour of the displays in KDE outside of the user space - so that the settings are global? I think this was possible with X11?
As they make a difference, could you upload the configuration files? Your dmesg output doesn't tell that anything is wrong at all :/ Can you try getting that output with kernel 5.16 again? On my PC there is a pretty verbose print of the attempted modeset, that's missing in yours; it's possible that lots of logging only got added recently > Is it possible to configure the behaviour of the displays in KDE outside of the user space - so that the settings are global? I think this was possible with X11? No. One thing you could try as a workaround is forcing the legacy driver mode, by putting KWIN_DRM_NO_AMS=1 into /etc/environment and rebooting
Created attachment 147370 [details] drm-dmesg log with only one monitor powered on after login to KDE output of journalctl --boot 0 | grep kwin_wayland_drm with only one monitor powered on after login to KDE
Created attachment 147371 [details] drm-dmesg log with both monitors powered on after login to KDE Output of journalctl --boot 0 | grep kwin_wayland_drm with both monitors successfully powered on after login to KDE
@ZamundaaaI have attached to outputs of "journalctl --boot 0 | grep kwin_wayland_drm" - one with only one monitor display powered on after login from SDDM to KDE and the other with both monitors remaining powered on after login to KDE. They appear to be identical.
(In reply to Zamundaaa from comment #19) > As they make a difference, could you upload the configuration files? > > Your dmesg output doesn't tell that anything is wrong at all :/ > Can you try getting that output with kernel 5.16 again? On my PC there is a > pretty verbose print of the attempted modeset, that's missing in yours; it's > possible that lots of logging only got added recently > > > Is it possible to configure the behaviour of the displays in KDE outside of the user space - so that the settings are global? I think this was possible with X11? > No. > One thing you could try as a workaround is forcing the legacy driver mode, > by putting KWIN_DRM_NO_AMS=1 into /etc/environment and rebooting I have attached to outputs of "journalctl --boot 0 | grep kwin_wayland_drm" - one with only one monitor display powered on after login from SDDM to KDE and the other with both monitors remaining powered on after login to KDE. They appear to be identical. As for the automatically cached configuration files in .home/user/.local/share/kscreen - I will make an attachment of the compressed directory and upload that shortly. The problem has reoccured many time since my experiment in removing and replacing the files in that directory.
Created attachment 147372 [details] tar director of .local/share/kscreen Attached is the compressed directory ".local/share/kscreen". In a previous experiment I had removed the older files in this directory (leaving the current ones) to a backup. On reboot only one monitor display remained on after login to KDE. When I restored the older files both monitor displays remained on after login to KDE. However, the problem of only one or even no monitors remaining on after login to the desktop persists.
Created attachment 147374 [details] Output of script drm-debug The output of script drm-debug
(In reply to Zamundaaa from comment #19) > As they make a difference, could you upload the configuration files? > > Your dmesg output doesn't tell that anything is wrong at all :/ > Can you try getting that output with kernel 5.16 again? On my PC there is a > pretty verbose print of the attempted modeset, that's missing in yours; it's > possible that lots of logging only got added recently > > > Is it possible to configure the behaviour of the displays in KDE outside of the user space - so that the settings are global? I think this was possible with X11? > No. > One thing you could try as a workaround is forcing the legacy driver mode, > by putting KWIN_DRM_NO_AMS=1 into /etc/environment and rebooting I have also attached the most recent output of your script drm-debug with only one monitor display remaining powered on after login to KDE from SDDM
> > One thing you could try as a workaround is forcing the legacy driver mode, > > by putting KWIN_DRM_NO_AMS=1 into /etc/environment and rebooting Did so but it makes no difference
The output of the script directly is not useful, only the files that it generates are. > Did so but it makes no difference ok, that should more or less exclude KWin not being able to set up the displays. Something that's immediately suspicious are the kscreen config files e6b74bd077242dfda7cef1db56996254 and fb01357b9ab464cd70c83e296a94c8be, they're referering to the same monitors but with different ids, the primary state switched and with different refresh rate units - one 60, the other 60000. I think we might have a serious KScreen bug, at least in addition to a KWin bug. What files does KScreen generate if you remove the kscreen folder and reboot?
Created attachment 147380 [details] Files in ./local/share/kscreen Files generated in ./local/share/kscreen after directory was removed and computer rebooted
(In reply to Zamundaaa from comment #28) > The output of the script directly is not useful, only the files that it > generates are. > > > Did so but it makes no difference > ok, that should more or less exclude KWin not being able to set up the > displays. > > Something that's immediately suspicious are the kscreen config files > e6b74bd077242dfda7cef1db56996254 and fb01357b9ab464cd70c83e296a94c8be, > they're referering to the same monitors but with different ids, the primary > state switched and with different refresh rate units - one 60, the other > 60000. I think we might have a serious KScreen bug, at least in addition to > a KWin bug. > What files does KScreen generate if you remove the kscreen folder and reboot? I have attached a new tar file of the generated directory after removing it and rebooting. After rebooting only one display is powered on after login. The files you refer to - e6b74bd077242dfda7cef1db56996254 - is today's with Wayland and the other - fb01357b9ab464cd70c83e296a94c8be - is from April 2021 running X11.
(In reply to SP from comment #30) > (In reply to Zamundaaa from comment #28) > > The output of the script directly is not useful, only the files that it > > generates are. > > > > > Did so but it makes no difference > > ok, that should more or less exclude KWin not being able to set up the > > displays. > > > > Something that's immediately suspicious are the kscreen config files > > e6b74bd077242dfda7cef1db56996254 and fb01357b9ab464cd70c83e296a94c8be, > > they're referering to the same monitors but with different ids, the primary > > state switched and with different refresh rate units - one 60, the other > > 60000. I think we might have a serious KScreen bug, at least in addition to > > a KWin bug. > > What files does KScreen generate if you remove the kscreen folder and reboot? > > I have attached a new tar file of the generated directory after removing it > and rebooting. After rebooting only one display is powered on after login. > The files you refer to - e6b74bd077242dfda7cef1db56996254 - is today's with > Wayland and the other - fb01357b9ab464cd70c83e296a94c8be - is from April > 2021 running X11. Correction - One file - e6b74bd077242dfda7cef1db56996254 is from 9/12/2018 and the other is 04/2/2021 Not certain when I switched over to Wayland in 2021 - but definitely the 2018 file is with X11
It took more than several reboots this morning before both monitor displays were powered on after login from SDDM. Sometimes it was just the left monitor or the right monitor. I think this has to do with the timing of the reading of the files generated in .local/share/kscreen or some cache problem. What else could explain the erratic behaviour? There is nothing consistent about it - other than it takes many reboots before both displays remain powered on after login. Then it seems one can go days with this not reoccurring. I upgraded to 5.24.3 last night - it has not made a difference.
On my other computer with almost identical hardware, OS and updates both monitors remained powered on after login to KDE after first boot. This is not always the case.
(In reply to SP from comment #29) > Created attachment 147380 [details] > Files in ./local/share/kscreen > > Files generated in ./local/share/kscreen after directory was removed and > computer rebooted That archive seems to be empty?
(In reply to Zamundaaa from comment #34) > (In reply to SP from comment #29) > > Created attachment 147380 [details] > > Files in ./local/share/kscreen > > > > Files generated in ./local/share/kscreen after directory was removed and > > computer rebooted > > That archive seems to be empty? No it is not empty. I (In reply to Zamundaaa from comment #34) > (In reply to SP from comment #29) > > Created attachment 147380 [details] > > Files in ./local/share/kscreen > > > > Files generated in ./local/share/kscreen after directory was removed and > > computer rebooted > > That archive seems to be empty? It is not empty. The archived folder structure is local/share/kscreen which contains one generated display definiton file and a directory name "output" with two display definition files for each monitor.
Possibly related bug 450871 KDE Plasma Multi-Monitor BUG - No Video Output on one Monitor (No Output Signal) & Display Issue on other monitor after update to 5.24.2 https://bugs.kde.org/show_bug.cgi?id=450871
Created attachment 147448 [details] very verbose logging Sigh, Dolphin hid the ".local" folder in the archive... Looking at the configs, they're exactly the same :/ Assuming that KScreen or the configs aren't doing nothing wrong or differently then, *something* must be going wrong in KWin. I attached a patch for 5.24 that adds logging in a lot of places that could hint to what's happening; could you apply it, restart, reproduce the bug and upload the output of "journalctl --boot 0 | grep kwin_wayland_drm" again? Afterwards you should install unpatched KWin again, it logs enough to fill gigabytes in an hour
(In reply to Zamundaaa from comment #37) > Created attachment 147448 [details] > very verbose logging > > Sigh, Dolphin hid the ".local" folder in the archive... > Looking at the configs, they're exactly the same :/ > > Assuming that KScreen or the configs aren't doing nothing wrong or > differently then, *something* must be going wrong in KWin. I attached a > patch for 5.24 that adds logging in a lot of places that could hint to > what's happening; could you apply it, restart, reproduce the bug and upload > the output of "journalctl --boot 0 | grep kwin_wayland_drm" again? > Afterwards you should install unpatched KWin again, it logs enough to fill > gigabytes in an hour Ok I am a bit stumped here. I am guessing this patch needs to be applied to the source file? I have binary packages installed - not from source. (In reply to Zamundaaa from comment #37) > Created attachment 147448 [details] > very verbose logging > > Sigh, Dolphin hid the ".local" folder in the archive... > Looking at the configs, they're exactly the same :/ > > Assuming that KScreen or the configs aren't doing nothing wrong or > differently then, *something* must be going wrong in KWin. I attached a > patch for 5.24 that adds logging in a lot of places that could hint to > what's happening; could you apply it, restart, reproduce the bug and upload > the output of "journalctl --boot 0 | grep kwin_wayland_drm" again? > Afterwards you should install unpatched KWin again, it logs enough to fill > gigabytes in an hour Okay - I am a bit stumped here. I presume this patch has to be applied to a source file? I have only binary packages installed - not from source. So where can I get kwin-5.24.3-1.fc35.src.rpm ? If I run the patch alone with: sudo patch --dry-run < '5.24 verbose logging.patch' I get: can't find file to patch at input line 5 Perhaps you should have used the -p or --strip option? The text leading up to this was: -------------------------- |diff --git a/src/backends/drm/drm_gpu.cpp b/src/backends/drm/drm_gpu.cpp |index 8f7b92b53..9d86869dc 100644 |--- a/src/backends/drm/drm_gpu.cpp |+++ b/src/backends/drm/drm_gpu.cpp -------------------------- File to patch: ---------------------------- Sorry to be so naive.
Tbh I don't know a thing about how to build patched packages for rpm based distros either. For building and installing directly though, git clone https://invent.kde.org/plasma/kwin.git --branch Plasma/5.24 cd kwin git apply "path of the patch file" mkdir build && cd build cmake .. make sudo make install would do the job. You can then "sudo make uninstall" in that folder to remove the installed files again, and then re-install your KWin system package to revert to standard KWin again.
(In reply to Zamundaaa from comment #39) > Tbh I don't know a thing about how to build patched packages for rpm based > distros either. > For building and installing directly though, > git clone https://invent.kde.org/plasma/kwin.git --branch Plasma/5.24 > cd kwin > git apply "path of the patch file" > mkdir build && cd build > cmake .. > make > sudo make install > > would do the job. You can then "sudo make uninstall" in that folder to > remove the installed files again, and then re-install your KWin system > package to revert to standard KWin again. Thanks - will do soon.
Created attachment 147473 [details] log of journalctl --boot 0 | grep kwin_wayland_drm Here is the result of journalctl --boot 0 | grep kwin_wayland_drm > kwin_wayland_drm-dmesg_log_2.txt after the installation of the (Zamundaaa) patched version of kwin.
(In reply to Zamundaaa from comment #39) > Tbh I don't know a thing about how to build patched packages for rpm based > distros either. > For building and installing directly though, > git clone https://invent.kde.org/plasma/kwin.git --branch Plasma/5.24 > cd kwin > git apply "path of the patch file" > mkdir build && cd build > cmake .. > make > sudo make install > > would do the job. You can then "sudo make uninstall" in that folder to > remove the installed files again, and then re-install your KWin system > package to revert to standard KWin again. I have attached a new log file following the installation of your patched version of kwin. I have since unistalled that and reinstalled the packaged version of kwin for Fedora.
Created attachment 147482 [details] compressed journalctl log I downloaded kwin from git a second time and reapplied the patchfile ran cmake etc - rebooted with only one monitor display left powered on after login from SDDM and then logged the output of journalctl. The result is more verbose than the first. I have compressed the file as it was too large to upload. However, this time after deinstalling the patched git file and reinstalling the packaged version of kwin - somehow kwin was deleted as well a various library files. I have just managed to get back in :(
The only suspicious thing I can see here is that in some areas of the log there's commits without any pipelines printed: > kwin_wayland_drm: committing pipelines > kwin_wayland_drm: (list done) but the rest of the log suggests that's not a behavior bug of KWin but probably some weirdness with logging instead. Both monitors still get presented and KWin gets responses from the kernel that the presentations do in fact happen. So from the PoV of KWin everything is completely fine - this would suggest that it's a kernel bug. There's two more data points we can gather: 1. the output of drm_info when you're in SDDM (you can get it by logging in via ssh and executing drm_info with sudo) and when you're in the broken session 2. if you uninstall xf86-video-amdgpu, reboot and let the default Xorg driver take over, which uses the same driver interface as kwin_wayland, do sddm and the Plasma X11 session start exhibiting broken behavior as well, or does it continue working fine?
Created attachment 147632 [details] Tar containing three text files results of drm_info @Zamundaaa I have attached drm_info_reports,tgz which contains three text files: sddm_drm_info.txt (the result of drm-info in SDDM before logging into the KDE); drm_info_broken_session.txt (after logging in with only one monitor display activated); drm_info_working_session.txt (logged into KDE with both monitor displays successfully activated). At a glance sddm_drm_info.txt and drm_info_working_session.txt appear identical with CRTC 0 (line 205) and CRTC 1 both with the resolution stated - whereas in the broken session those specification are on CRTC 2 and CRTC 3. I have not uninstalled xf86-video-amdgpu yet but will post the results of that soon.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/2165
I did find another difference, which is that the maximum bit depth the driver is allowed to use was set to 8 in the broken session, instead of 16. I doubt that it's the cause of your problems as it's what's used on Xorg as well, but it should be fixed anyways. Are the outputs consistently on CRTC 2 and 3 in the broken session? In your older logs there wasn't a failed test commit but here definitely at least one happened, which causes KWin to try other crtcs, which in turn may cause a driver bug or something...
Git commit 7384405add47be4f81faef66f364bffc9c710349 by Xaver Hugl. Committed on 21/03/2022 at 13:33. Pushed by zamundaaa into branch 'master'. backends/drm: set max bpc in DrmPipeline If it's only set in DrmConnector it may be reverted if a test commit fails M +0 -5 src/backends/drm/drm_object_connector.cpp M +3 -0 src/backends/drm/drm_pipeline.cpp https://invent.kde.org/plasma/kwin/commit/7384405add47be4f81faef66f364bffc9c710349
Created attachment 147650 [details] drm-info of both monitors active but mirroring the display of only one @Zamudaaa I ran drm_info again on broken sessions and they are the same as before with CRTC resolutions on CRTC 2 and CRTC 3. Occasionally both monitors will be active after login mirroring the display of only one monitor. I attach drm_info_mirror_session.txt. It has the resolutions on CRTC 0 and CRTC 1 as in the working session and I cannot detect a difference in the files.
> 2. if you uninstall xf86-video-amdgpu, reboot and let the default Xorg > driver take over, which uses the same driver interface as kwin_wayland, do > sddm and the Plasma X11 session start exhibiting broken behavior as well, or > does it continue working fine? I uninstalled xorg-x11-drv-amdgpu (as it is named on Fedora) and rebooted numerous times but so far have not encountered a broken session. As it is random I will wait a few days to confirm this. drm_info still reports the driver as amdgpu (AMD GPU) version 3.44.0 (20150101) as before.
(In reply to SP from comment #50) > > 2. if you uninstall xf86-video-amdgpu, reboot and let the default Xorg > > driver take over, which uses the same driver interface as kwin_wayland, do > > sddm and the Plasma X11 session start exhibiting broken behavior as well, or > > does it continue working fine? > > I uninstalled xorg-x11-drv-amdgpu (as it is named on Fedora) and rebooted > numerous times but so far have not encountered a broken session. As it is > random I will wait a few days to confirm this. drm_info still reports the > driver as amdgpu (AMD GPU) version 3.44.0 (20150101) as before. Of course - the amdgpu is built into the kernel.
Git commit 6e41d7288a7032a2479d72287dfd8794d761eb87 by Xaver Hugl. Committed on 21/03/2022 at 21:10. Pushed by zamundaaa into branch 'Plasma/5.24'. backends/drm: set max bpc in DrmPipeline If it's only set in DrmConnector it may be reverted if a test commit fails (cherry picked from commit 7384405add47be4f81faef66f364bffc9c710349) M +0 -5 src/backends/drm/drm_object_connector.cpp M +3 -0 src/backends/drm/drm_pipeline.cpp https://invent.kde.org/plasma/kwin/commit/6e41d7288a7032a2479d72287dfd8794d761eb87
(In reply to Zamundaaa from comment #44) > The only suspicious thing I can see here is that in some areas of the log > there's commits without any pipelines printed: > > kwin_wayland_drm: committing pipelines > > kwin_wayland_drm: (list done) > but the rest of the log suggests that's not a behavior bug of KWin but > probably some weirdness with logging instead. > Both monitors still get presented and KWin gets responses from the kernel > that the presentations do in fact happen. So from the PoV of KWin everything > is completely fine - this would suggest that it's a kernel bug. > > There's two more data points we can gather: > 1. the output of drm_info when you're in SDDM (you can get it by logging in > via ssh and executing drm_info with sudo) and when you're in the broken > session > 2. if you uninstall xf86-video-amdgpu, reboot and let the default Xorg > driver take over, which uses the same driver interface as kwin_wayland, do > sddm and the Plasma X11 session start exhibiting broken behavior as well, or > does it continue working fine? The removal of xorg-x11-drv-amdgpu definitely resolved the problem. There must exist some conflict between this and the built-in kernel amdgpu driver . As I am using Wayland I would have thought this irrelevant - but since deinstalling the xorg-x11-drv-amdgp driver I have not had a recurrence of this problem on either of our computers with dual monitors. Thank you @Zamundaaa for the tip. I will mark this as resolved.