Bug 379474

Summary: KWin wakes up the monitor right after going to sleep
Product: [Plasma] kwin Reporter: David Rosca <nowrep>
Component: generalAssignee: Sebastian Kügler <sebas>
Status: RESOLVED DUPLICATE    
Severity: normal CC: aagaande, charles, daffy, email, james, jching, kde, mail, mcpain, nate, norbert, notmart, postix, reuben_p, rnet723, tarasov.igor, vkrevs, vlad.zahorodnii, xaver.hugl
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: Ubuntu   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:
Attachments: kscreen log when external monitor goes to sleep
kscreen2 log after triggering dpms suspend
journalctl -t kwin_wayland -t org_kde_powerdevil -t ksmserver after kscreen-doctor -d off

Description David Rosca 2017-05-03 10:36:55 UTC
Created attachment 105324 [details]
kscreen log when external monitor goes to sleep

My laptop is in docking station with external monitor connected (HDMI-2 in the log). Laptop screen is turned off, external monitor is the only output. When external monitor goes to sleep (either automatically after inactivity or with xset dpms force off) it turns off and enables back again right after.

The issue is that KScreen kded turns it back on. Unloading kscreen kded module fixes the issue.
Comment 1 David Rosca 2017-05-03 13:24:20 UTC
The issue is when monitor is turned off, KScreen emits output disconnected and KScreenDaemon::outputConnectedChanged reapplies config which turns the monitor back on.
I'm not sure what would be correct fix, my workaround is to query DPMS state in KScreenDaemon::outputConnectedChanged and if DPMS state is off, skip the reconfiguration.
Comment 2 Sebastian Kügler 2017-05-04 08:03:52 UTC
Can confirm, just never connected the cause to the effect. Thanks for the report.
Comment 3 Oleg Solovyov 2017-12-20 09:22:52 UTC
Same problem with my two-screen configuration.

When both are switching off, after 10-15 seconds, they are switching back on, and do not even try to switch off again.

I think there should be a setting "Do not disconnect external monitor after switching it off"
Comment 4 Oleg Solovyov 2017-12-20 09:23:57 UTC
KScreen 5.11.4
Comment 5 Oleg Solovyov 2017-12-26 13:40:59 UTC
Differential revision:

https://phabricator.kde.org/D9506
Comment 6 Oleg Solovyov 2018-01-17 14:47:30 UTC
First monitor if BenQ GW2406-T

Bug reproduces if secondary monitor is iiyama X2481FS-B1

After changing to AOC 238LM00008 I cannot reproduce this.
Comment 7 Reuben 2020-08-31 01:53:01 UTC
Apparently this is a bug in DRM:
https://gitlab.freedesktop.org/drm/amd/-/issues/662
Comment 8 Anders Aagaard 2020-11-13 18:44:54 UTC
I'm having the same issue on nvidia hardware.

apt-get remove kscreen && killall kscreen_backend_launcher solves the problem.
Comment 9 Charles 2020-11-17 13:17:15 UTC
Also with amdgpu and 2x DisplayPort monitors (Dell & AOC)
Killing kded5 fixes the problem
Comment 10 jching 2021-02-01 04:46:20 UTC
Created attachment 135343 [details]
kscreen2 log after triggering dpms suspend
Comment 11 jching 2021-02-01 04:47:20 UTC
(In reply to Reuben from comment #7)
> Apparently this is a bug in DRM:
> https://gitlab.freedesktop.org/drm/amd/-/issues/662

this issue disappears if i disable kscreen2 service. i can also confirm that that my monitors go to sleep normally if i leave the login screen (SDDM) idling. 

seems like the issue only happens after login when kscreen2 starts

are we sure it's an AMD driver issue?

sorry i'm new to all this. please let me know if there are logs i should post. i had a look at journalctl after i triggered a manual "xset dpms force suspend" 

attached log here: https://bugsfiles.kde.org/attachment.cgi?id=135343

let me know if that helps
Comment 12 Sebita 2021-05-23 23:25:12 UTC
Can confirm disabling Kscreen 2 solves the issue, both on Fedora and Kubuntu. Monitor stays asleep until I move the mouse or touch a key.
Comment 13 Igor Tarasov 2022-02-18 05:23:42 UTC
Confirming with latest KDE Neon (5.24.1). For me this issue appears only when I connect my HDMI monitor via USB-C hub (which is used for all comms + power delivery). When I connect the monitor directly everything works okay, and it does go to powersave mode. Disabling and stopping KScreen 2 in background jobs solves the issue.

Also, this is kind of known issue:

https://www.reddit.com/r/kde/comments/ewbqst/display_doesnt_sleep_in_power_save_mode/
https://www.reddit.com/r/kde/comments/cnef1v/kde_doesnt_sleep_or_turn_off_monitor_when_inactive/
Comment 14 Bug Janitor Service 2022-09-13 15:10:59 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/2940
Comment 15 email@thelinuxcast.org 2023-02-13 00:53:06 UTC
Same issue. Fixed by disabling Kscreen 2 background service. May not be the best solution, but it works.
Comment 16 Zamundaaa 2023-09-26 22:14:43 UTC
Git commit 482a1f0fb5bddb6d376a6b8d39a04bc16786cc97 by Xaver Hugl.
Committed on 27/09/2023 at 00:02.
Pushed by zamundaaa into branch 'master'.

backends/drm: don't wake displays up when outputs get temporarily removed

When some displays go to sleep, that can be wrongly detected as a temporary
hotunplug by the driver. In order to not wrongly wake up the system with
such a display, detect that scenario and set the 'new' output to dpms off
again.
Related: bug 452553

M  +22   -0    src/backends/drm/drm_backend.cpp
M  +1    -1    src/backends/drm/drm_backend.h
M  +3    -0    src/workspace.cpp

https://invent.kde.org/plasma/kwin/-/commit/482a1f0fb5bddb6d376a6b8d39a04bc16786cc97
Comment 17 Nate Graham 2023-10-20 17:24:02 UTC
*** Bug 475662 has been marked as a duplicate of this bug. ***
Comment 18 Nate Graham 2023-10-20 17:24:07 UTC
*** Bug 475829 has been marked as a duplicate of this bug. ***
Comment 19 rnet723 2023-10-20 17:33:39 UTC
Is there a chance that the fix would be backported to Plasma LTS 5.27.*?
Comment 20 Dinolek 2024-03-10 18:53:12 UTC
Created attachment 166903 [details]
journalctl -t kwin_wayland -t org_kde_powerdevil -t ksmserver after kscreen-doctor -d off

Still happens with plasma 6.0.1
Comment 21 Zamundaaa 2024-05-09 14:55:31 UTC

*** This bug has been marked as a duplicate of bug 480026 ***