Bug 449906 - A monitor keeps power-cycling and disconnecting upon login
Summary: A monitor keeps power-cycling and disconnecting upon login
Status: RESOLVED FIXED
Alias: None
Product: KScreen
Classification: Unclassified
Component: common (show other bugs)
Version: 5.24.0
Platform: Manjaro Linux
: VHI normal
Target Milestone: ---
Assignee: kscreen-bugs-null@kde.org
URL:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2022-02-10 02:29 UTC by 0x10c961
Modified: 2022-04-28 14:15 UTC (History)
8 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.24.5


Attachments
dmesg-drm log (124.00 KB, text/x-log)
2022-03-11 03:54 UTC, brady.phillips99
Details
kwin-drm log (3.55 KB, text/x-log)
2022-03-11 03:55 UTC, brady.phillips99
Details
verbose kwin log part 1 (3.15 MB, text/x-log)
2022-03-20 03:27 UTC, brady.phillips99
Details
verbose kwin log part 2 (3.19 MB, text/x-log)
2022-03-20 03:28 UTC, brady.phillips99
Details
verbose kwin log part 3 (3.26 MB, text/x-log)
2022-03-20 03:28 UTC, brady.phillips99
Details
verbose kwin log part 4 (3.14 MB, text/x-log)
2022-03-20 03:28 UTC, brady.phillips99
Details
patch bpc=8 (642 bytes, patch)
2022-04-27 08:49 UTC, Zamundaaa
Details

Note You need to log in before you can comment on or make changes to this bug.
Description 0x10c961 2022-02-10 02:29:38 UTC
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.
Comment 1 ckjoris 2022-02-10 09:39:05 UTC
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.
Comment 2 brady.phillips99 2022-02-10 23:25:07 UTC
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
Comment 3 0x10c961 2022-02-11 10:51:32 UTC
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.
Comment 4 brady.phillips99 2022-02-11 13:30:49 UTC
I tried with only the BenQ GW2765 plugged in and the cycling still happens.
Comment 5 Vlad Zahorodnii 2022-02-11 19:52:54 UTC
Can you try disabling kscreen in Background Services settings and rebooting wayland session? Does the screen still keep power cycling?
Comment 6 ckjoris 2022-02-11 21:01:47 UTC
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'
Comment 7 brady.phillips99 2022-02-11 21:21:41 UTC
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!
Comment 8 qlum 2022-02-18 14:28:35 UTC
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.
Comment 9 0x10c961 2022-02-27 09:38:07 UTC
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.
Comment 10 Zamundaaa 2022-03-11 01:10:39 UTC
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
Comment 11 brady.phillips99 2022-03-11 03:54:48 UTC
Created attachment 147435 [details]
dmesg-drm log
Comment 12 brady.phillips99 2022-03-11 03:55:25 UTC
Created attachment 147436 [details]
kwin-drm log
Comment 13 brady.phillips99 2022-03-11 03:55:58 UTC
(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.
Comment 14 Zamundaaa 2022-03-11 18:07:30 UTC
(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
Comment 15 brady.phillips99 2022-03-12 05:18:28 UTC
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.
Comment 16 Zamundaaa 2022-03-15 20:35:52 UTC
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
Comment 17 brady.phillips99 2022-03-20 03:27:39 UTC
Created attachment 147607 [details]
verbose kwin log part 1
Comment 18 brady.phillips99 2022-03-20 03:28:02 UTC
Created attachment 147608 [details]
verbose kwin log part 2
Comment 19 brady.phillips99 2022-03-20 03:28:23 UTC
Created attachment 147609 [details]
verbose kwin log part 3
Comment 20 brady.phillips99 2022-03-20 03:28:40 UTC
Created attachment 147610 [details]
verbose kwin log part 4
Comment 21 brady.phillips99 2022-03-20 03:33:30 UTC
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.
Comment 22 Zamundaaa 2022-03-31 02:01:19 UTC
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
Comment 23 brady.phillips99 2022-04-03 01:11:53 UTC
(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.
Comment 24 Zamundaaa 2022-04-27 08:49:54 UTC
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?
Comment 25 brady.phillips99 2022-04-27 21:57:03 UTC
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.
Comment 26 Zamundaaa 2022-04-28 13:44:24 UTC
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
Comment 27 Zamundaaa 2022-04-28 14:15:29 UTC
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