SUMMARY After logging in, one of my monitors keeps shutting off and turning back on and displaying "No signal." STEPS TO REPRODUCE 1. After updating system, turn on computer 2. Enter login credentials and hit enter to log in 3. Observe monitor power-cycling OBSERVED RESULT After entering login credentials and hitting enter to log in, all of the monitor screens go black, then three out of four of them turn back on fully and display the expected desktop. The fourth monitor keeps turning on, showing "no signal," then turning off, and repeating this cycle endlessly. EXPECTED RESULT All monitors should be on and displaying the desktop. SOFTWARE/OS VERSIONS Linux/KDE Plasma: 5.16.8-1-MANJARO KDE Plasma Version: 5.24.0 KDE Frameworks Version: 5.90.0 Qt Version: 5.15.2 ADDITIONAL INFORMATION This happens in both Wayland and X11. Using the latest Mesa drivers with an AMD Radeon RX 5700XT. The non-working monitor is a BenQ GW2765. Upon powering on from a complete shutdown, all four monitors are on, at the correct resolutions, and displaying the login page. The fourth monitor does not start power-cycling until after I log in. If I then log out, the fourth monitor does not turn back on. The 3 working monitors are plugged in with DisplayPort 1.4 cables, the non-working monitor is plugged in with an HDMI 2.1 cable. All 4 monitors support both DP and HDMI, I have tried using a different HDMI cable and this has not fixed the issue. I have also tried plugging in the non-working monitor with the same DisplayPort cable of one of the working monitors, and then plugged that working monitor in with the HDMI cable used by the BenQ, and it is still the same BenQ monitor that is power-cycling, and the working monitor that I plugged in with the HDMI cable used by the BenQ monitor powers up just fine. Using Timeshift, I reverted back to a backup with the previous KDE Plasma 5.23 version, and the monitor then starts working again and everything seems to be fine.
I have similar issue (i think maybe same issue). I just updated to kde 5.24, i'm using openSuse tumbleweed. I have two monitors. a dell and a benq. Dell connected over displayport & benq over hdmi. 1. turn pc on. log in to wayland. 2. dell monitor turns on and my main desktop is moved to it. benq shows "no signal" message. 3. Then seems plasma is trying to find some working combination for the displays, so both are turned black, and then again only the dell is turned on and shows desktop, while benq showing "no signal". Then this repeats indefinitely. Later I killed plasma and tried login to Xorg but it did not work. Then I rebooted and logged in to Xorg - it works fine. Software/OS versions: Kernel 5.16.5 Kde plasma: 5.24.0 KDe frameworks: 5.90.0 QT: 5.15.2 AMD RX 570 GPU.
Same thing happening to me after upgrading to 5.24. I have 2 monitors, the one which keeps cycling is also a BenQ GW2765. Operating System: Arch Linux KDE Plasma Version: 5.24.0 KDE Frameworks Version: 5.90.0 Qt Version: 5.15.2 Kernel Version: 5.16.8-arch1-1 (64-bit) Graphics Platform: Wayland Processors: 12 × AMD Ryzen 5 5600G with Radeon Graphics Memory: 15.0 GiB of RAM Graphics Processor: AMD RENOIR
Of the four monitors, one of them is a BenQ EX2710Q, one is a BenQ GW2765, the other two are both Asus PG329. The Two Asus monitors are set to 175hz refresh rate, the EX2710Q is set to 165hz refresh rate, and the GW2765 is set to 60hz. I have tried setting them all to 60hz to check if it's related to the refresh rate, and the results are still the same-- the GW2765 continuously power cycles displaying "No Signal" when it turns on, before turning back off. The "Auto Switch HDMI" and "Auto Switch DP" settings within the GW2765's own settings UI are set to disabled. Kscreen still thinks the monitor is turned on and enabled during its power-cycling. If I set the "Auto Switch" settings to "on," K screen sees the monitor become disabled when it powers off (it stops showing up in the Display Config UI), then re-enabled when it powers back on during its endless power cycling. I've yet to test it with just the one non-working monitor plugged in and no others, to see if it will power cycle endlessly. I'm not able to do that at this time because I've re-installed the OS for an unrelated reason and I'm no longer on the unstable channel for Manjaro, where plasma is 5.24. If anyone here who has this issue can do this test to determine if it's related to multi-monitor, or just specific monitors that are having issues, then that could be ruled out.
I tried with only the BenQ GW2765 plugged in and the cycling still happens.
Can you try disabling kscreen in Background Services settings and rebooting wayland session? Does the screen still keep power cycling?
I disabled 'kscreen 2' in background services, then rebooted, and the Benq GW2765 is still power cycling. However - while it was power cycling, on my other monitor I opened up display configuration settings KCM, changed resolution of the benq from 2560x1440 to 1920x1080, and it stopped power cycling. It works now. Also, most other resolutions, that are lower than 1920x1080 seem to work. But changing resolution to 1920x1080 the first time is not so easy, since monitor constantly power cycling, display settings constantly refreshing, and saying 'new monitor detected'. But it worked after like 10 tries. Side note: later I was rebooting but the kickoff menu froze, and in system logs (journalctl -b) this message appeared: 'plasmashell[16956]: requesting unexisting screen 5'
I can confirm what ckjoris said, disabling kscreen 2 made no difference and switching the BenQ to 1080p in display configuration fixed the issue (can't believe I didn't try this). Thanks so much for the temporary workaround ckjoris!
Might be related to a bug I reported before: https://bugs.kde.org/show_bug.cgi?id=429992 Whenever a display disconnects or connect, kscreen2 updates the layout of your displays. Which in some cases may cause a loop of sorts. Especially if a display that goes into standby disconnects itself. Even if the disconnect is very brief.
The Manjaro stable release channel just updated recently, and I can confirm the bug still exists. Linux/KDE Plasma: 5.16.11-2-MANJARO KDE Plasma Version: 5.24.2 KDE Frameworks Version: 5.91.0 Qt Version: 5.15.2 The temporary workaround with setting the resolution to a lower 16:9 ratio works for now. I also tried setting the resolution to 1920x1200 and this resulted in the power cycling described above. I also tried setting the refresh rate to 50hz at 1920x1200 and for 2560x1440 and this also resulted in the power cycling. If anyone has any suggestions for troubleshooting this bug, I'm willing and able to test things out.
In order to maybe get more information on the process that happens, can someone here execute the script on the bottom of the page https://invent.kde.org/plasma/kwin/-/wikis/Debugging-DRM-issues and upload the files it generates? If the power cycling takes longer than 3 seconds, maybe also increase the sleep time a bit, to catch at least one cycle
Created attachment 147435 [details] dmesg-drm log
Created attachment 147436 [details] kwin-drm log
(In reply to Zamundaaa from comment #10) > In order to maybe get more information on the process that happens, can > someone here execute the script on the bottom of the page > https://invent.kde.org/plasma/kwin/-/wikis/Debugging-DRM-issues and upload > the files it generates? > If the power cycling takes longer than 3 seconds, maybe also increase the > sleep time a bit, to catch at least one cycle I ran the script with 2 monitors connected with the sleep set to 20 to capture a full cycle. Note the broken monitor is the BenQ GW2765 which is connected through HDMI. The other monitor works fine. I had a quick look through the logs and did notice that at line 151 in the dmesg-drm log, it says that the supported refresh rate is 0 Hz - 0 Hz which doesn't seem right.
(In reply to brady.phillips99 from comment #13) > I had a quick look through the logs and did notice that at line 151 in the dmesg-drm log, it says that the supported refresh rate is 0 Hz - 0 Hz which doesn't seem right. AFAIK that just means that FreeSync is not supported. Weirdly enough, according to the logs, the monitor gets detected and nothing else happens. Are you sure the monitor disabled itself in time? I uploaded a patch for very verbose logging for this sort of stuff at https://bugs.kde.org/show_bug.cgi?id=448220#c37, could you try the same patch for this? It should at least tell us very clearly what KWin and KScreen are doing So, apply the patch, put QT_LOGGING_RULES="kwin_*.debug=true" into /etc/environment, reboot, let a few cycles happen and then upload the output of "journalctl --boot 0 | grep kwin_wayland_drm" here. Afterwards you'll want to revert to original KWin, to not fill your storage up with all the logging
When I tried to apply the patch, I didn't see any output in the journal that looked related to kwin and "journalctl --boot 0 | grep kwin_wayland_drm" returned nothing. I built the patched kwin first by adding the patch command to the pkgbuild and using pacman -U and when that showed nothing in the logs I tried building using the instructions in https://bugs.kde.org/show_bug.cgi?id=448220#c39 but I still got nothing in the logs. I did set the QT_LOGGING_RULES variable in /etc/environment so I'm not sure what I'm doing wrong.
Oh right, systemd boot is still disabled by default in 5.24. You can either check if legacy logging works (which goes into the file ~/.local/share/sddm/wayland-session.log) or you can enable systemd boot with kwriteconfig5 --file startkderc --group General --key systemdBoot true and reboot, then journalctl should show kwin logs
Created attachment 147607 [details] verbose kwin log part 1
Created attachment 147608 [details] verbose kwin log part 2
Created attachment 147609 [details] verbose kwin log part 3
Created attachment 147610 [details] verbose kwin log part 4
I have uploaded the requested logs split into 4 different files due to the upload size limit. I first let it cycle around 3 times and then changed the resolution of the broken monitor to 1080p which made it work normally. This change can be seen in part 3 of the logs on line 21718. I then changed it back to 1440p which made it start cycling again. This change can be seen in part 4 of the logs on line 32397.
I had a good look at the logs and it doesn't seem like KWin ever updates outputs after startup, it never sets the CRTC ID of anything to 0, link-status is always good and both outputs get presentation events pretty much without interruption. In other words, according to those logs both outputs stay enabled the whole time and everything is working fine. Parts of the log are missing all information for some reason though, maybe all the problems are hiding in there... As this only appeared with 5.24 and this sounds vaguely like it could be related to bandwidth issues of some sort, could you try running KWin with the environment variable "KWIN_DRM_PREFER_COLOR_DEPTH=24" set? Trying "KWIN_DRM_USE_MODIFIERS=1" could also be worth a shot
(In reply to Zamundaaa from comment #22) > As this only appeared with 5.24 and this sounds vaguely like it could be > related to bandwidth issues of some sort, could you try running KWin with > the environment variable "KWIN_DRM_PREFER_COLOR_DEPTH=24" set? Trying > "KWIN_DRM_USE_MODIFIERS=1" could also be worth a shot Just gave this a try but unfortunately neither of those environment variables seemed to help.
Created attachment 148405 [details] patch bpc=8 I still suspect that the bpc is the problem; I read today on dri-devel that the "max bpc" property currently works a bit differently than assumed. The attached patch for KWin (5.24 branch) should ensure that the "max bpc" property is always 8 or lower, like it was before 5.24. Can you test it? Additionally, if it helps and you change the "8lu" to "10lu", does it still work? To get some more clarity about that, how does it work on other display servers? So, if you reboot your computer and log into Xorg or Weston without first logging into the Plasma Wayland session, does that make a difference?
I'm pleased to report that the new patch fixed it! 1440p now works fine on the BenQ. Thanks for helping even with such a niche issue. Interestingly, I changed the patch to be 10lu and that also fixed the issue. Booting into a tty or xorg works fine. I also tried riverwm, a wlroots based compositor, and that worked fine as well.
Git commit 05877a83211aee64a47e227dde433ef19fec0b2e by Xaver Hugl. Committed on 28/04/2022 at 00:32. Pushed by zamundaaa into branch 'master'. backends/drm: reduce "max bpc" to what is actually used This prevents triggering a bug in the BenQ GW2765 monitor, and should in theory have no downsides. FIXED-IN: 5.24.5 M +5 -1 src/backends/drm/drm_pipeline.cpp https://invent.kde.org/plasma/kwin/commit/05877a83211aee64a47e227dde433ef19fec0b2e
Git commit ba43e3d662e32a1e3cfced759a13b7ca1e1f7650 by Xaver Hugl. Committed on 28/04/2022 at 14:14. Pushed by zamundaaa into branch 'Plasma/5.24'. backends/drm: reduce "max bpc" to what is actually used This prevents triggering a bug in the BenQ GW2765 monitor, and should in theory have no downsides. FIXED-IN: 5.24.5 M +5 -1 src/backends/drm/drm_pipeline.cpp https://invent.kde.org/plasma/kwin/commit/ba43e3d662e32a1e3cfced759a13b7ca1e1f7650