Created attachment 165026 [details] Demonstration. In the video, there is precisely one HID interaction: hitting return on the command present in step 1 Evening! SUMMARY Since switching to an AMD GPU (IIRC - been a while :/), when KDE turns my screens off, they stay off very briefly, then fires back up after a brief time, even when idle. I've created a video of the effect, it's attached. STEPS TO REPRODUCE 0. Get the (currently, to me, unknown) combination of software and hardware to cause this 1. sleep 1; dbus-send --session --print-reply --dest=org.kde.kglobalaccel /component/org_kde_powerdevil org.kde.kglobalaccel.Component.invokeShortcut string:'Turn Off Screen' 2. Wait a few seconds OBSERVED RESULT Screens power back on. EXPECTED RESULT Screens stay shut off. SOFTWARE/OS VERSIONS Operating System: Gentoo GNU/Linux 2.14 KDE Plasma Version: 5.27.10 KDE Frameworks Version: 5.114.0 Qt Version: 5.15.12 Kernel Version: 6.6.10-gentoo-dist-hardened (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 3800X 8-Core Processor Memory: 62.7 GiB of RAM Graphics Processor: AMD Radeon RX 6700 XT Manufacturer: Gigabyte Technology Co., Ltd. Product Name: B550M DS3H ADDITIONAL INFORMATION I've not been able to reproduce this in Sway via: swaymsg "output * dpms off" I can not reproduce this on a laptop with an Intel GPU with the same Plasma binary packages installed (i.e. the executables are the same between the two). I am not sure where to look for the wakeup cause. I have tried searching through the user journal, but to no avail.
I've also updated to Plasma 5.92.0 to test (and will continue testing :-) ), and I can still reproduce the issue via the same process. Operating System: Gentoo GNU/Linux 2.14 KDE Plasma Version: 5.92.0 KDE Frameworks Version: 5.248.0 Qt Version: 6.6.1 Kernel Version: 6.6.12-gentoo-dist-hardened (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 3800X 8-Core Processor Memory: 62.7 GiB of RAM Graphics Processor: AMD Radeon RX 6700 XT Manufacturer: Gigabyte Technology Co., Ltd. Product Name: B550M DS3H
Seems similar to bug 480093, which btw (just an observation, not necessarily meaningful) is also using a discrete AMD GPU.
Created attachment 165198 [details] KWin Support Information The bug you mentioned inspired me to try unplugging one of the monitors and running Turn Off Screen again. That worked. I unpluggged the HDMI-A-1 cable. So, here's the screens section of the Window Manager section of the Info Center: Screens ======= Active screen follows mouse: yes Number of Screens: 2 Screen 0: --------- Name: DP-3 Enabled: 1 Geometry: 1920,0,1920x1080 Scale: 1 Refresh Rate: 60000 Adaptive Sync: incapable Screen 1: --------- Name: HDMI-A-1 Enabled: 1 Geometry: 0,0,1920x1080 Scale: 1 Refresh Rate: 74973 Adaptive Sync: automatic I'll attach the full thing too.
Here's another observation, with the Display Configuration settings pane open, when the screen turns off, the settings pane notifies me that 'An output has been removed. Settings have been reloaded.' So, my new pet theory is that the screen turning off gets reported as unplugged, which registers as activity, maybe.
ah, here's info about the actual outputs, I just noticed the above lacks it, my bad interface: 'kde_output_device_v2', version: 6, name: 73 interface: 'wl_output', version: 4, name: 74 name: DP-3 description: HP Inc. HP P223a/0 x: 1920, y: 0, scale: 1, physical_width: 480 mm, physical_height: 270 mm, make: 'HP Inc.', model: 'HP P223a/0', subpixel_orientation: unknown, output_transform: normal, mode: width: 1920 px, height: 1080 px, refresh: 60.000 Hz, flags: current interface: 'kde_output_device_v2', version: 6, name: 81 interface: 'wl_output', version: 4, name: 82 name: HDMI-A-1 description: Iiyama North America PL2288H/16843009 x: 0, y: 0, scale: 1, physical_width: 480 mm, physical_height: 270 mm, make: 'Iiyama North America', model: 'PL2288H/16843009', subpixel_orientation: unknown, output_transform: normal, mode: width: 1920 px, height: 1080 px, refresh: 74.973 Hz, flags: current (apologies for the spam - hopefully this is all for now)
I cannot seem to reproduce this on the aforementioned laptop either.
I was having this exact same issue for a while now. I finally found the cause (in my setup, at least) My dell monitor has an "Input Auto Select" feature, and when it's enabled, it causes a feedback loop that constantly re-wakes the displays. I figured this out from a post on stackexchange: https://unix.stackexchange.com/a/754364 > I dealt with this problem and it turned out that my monitor was set to "auto" for source. and each time the monitor was powered off via dpms, when it cycled for a new source it turned the monitor back on. I set the source from auto to the dedicated source (HDMI) and the problem was solved.
Created attachment 165756 [details] Bug Demo Here's a video demo with my dell monitor, showing that enabling "auto detect" causes the bug
The monitor I'm using is a Dell S2721NX
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/5679
Git commit 38c4980b0d92f3836805becac13365d871afe62d by Arsen Arsenović. Committed on 30/04/2024 at 17:01. Pushed by zamundaaa into branch 'master'. backends/drm: Prevent "recently disconnected" screen wakeup more aggressively It seems that, on some systems (such as on mine), 1s is not long enough for a spurious disconnect and reconnect to happen. 2s seems enough, however, while still likely not being long enough to cause user confusion. M +1 -1 src/backends/drm/drm_backend.cpp https://invent.kde.org/plasma/kwin/-/commit/38c4980b0d92f3836805becac13365d871afe62d
Git commit 5980945ee42bf5fbcb677f5588d891e20a21ca41 by Arsen Arsenović. Committed on 30/04/2024 at 17:01. Pushed by zamundaaa into branch 'master'. dpmsinputeventfilter: Don't wake screens up on warp events As pointer warps are not user interactions, they should not wake screens up. M +5 -1 src/dpmsinputeventfilter.cpp https://invent.kde.org/plasma/kwin/-/commit/5980945ee42bf5fbcb677f5588d891e20a21ca41
Git commit f852077bec03bfd3bfbe18cbd5a2996befe4009a by Xaver Hugl, on behalf of Arsen Arsenović. Committed on 30/04/2024 at 19:07. Pushed by zamundaaa into branch 'Plasma/6.0'. dpmsinputeventfilter: Don't wake screens up on warp events As pointer warps are not user interactions, they should not wake screens up. M +5 -1 src/dpmsinputeventfilter.cpp https://invent.kde.org/plasma/kwin/-/commit/f852077bec03bfd3bfbe18cbd5a2996befe4009a
Git commit faa148572e806a1a9a6363c5e4b3a7fb1345e49a by Xaver Hugl, on behalf of Arsen Arsenović. Committed on 30/04/2024 at 19:07. Pushed by zamundaaa into branch 'Plasma/6.0'. backends/drm: Prevent "recently disconnected" screen wakeup more aggressively It seems that, on some systems (such as on mine), 1s is not long enough for a spurious disconnect and reconnect to happen. 2s seems enough, however, while still likely not being long enough to cause user confusion. M +1 -1 src/backends/drm/drm_backend.cpp https://invent.kde.org/plasma/kwin/-/commit/faa148572e806a1a9a6363c5e4b3a7fb1345e49a
*** Bug 379474 has been marked as a duplicate of this bug. ***
*** Bug 483099 has been marked as a duplicate of this bug. ***
*** Bug 423035 has been marked as a duplicate of this bug. ***
A possibly relevant merge request was started @ https://invent.kde.org/plasma/powerdevil/-/merge_requests/391
*** Bug 462619 has been marked as a duplicate of this bug. ***
*** Bug 445566 has been marked as a duplicate of this bug. ***
I'm on Kubuntu 20.04 with KDE Plasma / kwin version 5 (specifically 5.24.7) and I'm observing what I believe to be the same issue. Would that issue already have been present in v5 and, if so, could we backport the fix to the v5 series?
At this point it's not certain that another Plasma 5.27 release will be made. If it does get another release, maybe
For Wayland, it's fixed, but this behavior is still present in the X11 session. Should it be fixed somewhere else for X11?
I don't know where that would be, and I don't want to spend any time figuring it out, sorry. If anyone else wants to do that though, feel free to try to fix it for X11 too
As mentioned above a Dell monitor's auto-input select requires a longer trigger to stop the system from waking (e.g. my monitor seems to take ~17 seconds from the power off message: 10 to start the scan and another 7 to test the inputs). Is it reasonable to increase the timeout here further? I'm not sure users would find it too surprising if they unplug a monitor and plug it in again within even 30 seconds of it going to sleep that it doesn't trigger the screens to reset, but I do see how that kind of delay starts risking confusion. Also, the fix to not notify on the warp event seems to keep the screen lock timer going and prevents other monitors from waking, but the system never sleeps, so it seems the event isn't completely filtered. Is that managed elsewhere? The auto input select fixed my issue in the end, but it did take a ton of investigation to get to the cause so if it's reasonable/uncontroversial enough to change I could with some pointers (or would be happy if someone else wanted to).