SUMMARY HDMI-connected external monitor automatically comes back on a few seconds after being disabled. STEPS TO REPRODUCE 1. Connect an external monitor via HDMI (the monitor must have an auto-input select feature that cannot be disabled) 2. Turn the screen off (through idle settings or a command such as kscreen-doctor --dpms off 3. Wait 5 to 10 seconds OBSERVED RESULT A few seconds after the monitor is turned off, some models (including mine) will cycle through all available inputs. When the HDMI connection is tried again, this is treated as some kind of monitor hotplug event by KDE, causing the laptop screen to come on briefly and then causing the external monitor to come back on permanently. (Because of the smaller screen briefly turning on, some applications such as Steam also end up with zoom/placement issues.) EXPECTED RESULT Both screens remain off (until enabled again through some intentional method). SOFTWARE/OS VERSIONS Operating System: CachyOS Linux KDE Plasma Version: 6.6.3 KDE Frameworks Version: 6.24.0 Qt Version: 6.11.0 Kernel Version: 6.19.10-1-cachyos (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 7735U with Radeon Graphics Memory: 32 GiB of RAM (30.7 GiB usable) Graphics Processor: AMD Radeon Graphics ADDITIONAL INFORMATION This was working perfectly with the same hardware & DE setup (on CachyOS with KDE Plasma) for months, up until a software update 1 or 2 months ago that included a number of different application updates. This is a known issue that has been reported elsewhere over the past few years, including this other bug report that seems to have been fixed in Plasma 6.6.2: https://bugs.kde.org/show_bug.cgi?id=516454 https://forum.level1techs.com/t/wayland-monitor-wont-stay-off/204261 I have tried a few possible solutions I've found online, but none have worked. The issue does not occur when connected via USB-C, but for unrelated reasons I need to be connected via HDMI. The issue seems to have some relationship to the Linux kernel version, because it briefly went away again when switching from the most recent CachyOS kernel 6.19 to the LTS 6.18.X ... however, since a further software update, the issue now persists no matter which kernel version I am on. Strangely, I tried the Niri DE with the same kernel & hardware, and the problem does *not* occur (i.e. the monitor is table to turn off after an idle period without turning back on again). This would seem to indicate that kscreen or something else KDE-related could handle the event properly, no matter what kernel is active. My monitor (Lenovo Q27h-10) has not received any firmware updates in many years, and there is no way to disable the auto-input select feature.
Thanks for the bug report, and for all the details you've provided. That's useful. It looks like there are some other conditions the previous fix doesn't work with. Please run the following command when this happens, and paste the output into this report. kscreen-doctor -o Thanks again!
(In reply to TraceyC from comment #1) > kscreen-doctor -o Thanks! Here's the output: Output: 1 eDP-1 d0f0dd55-d2ea-4ff8-ba28-2a19e835c178 disabled connected priority 1 Panel replication source:0 Modes: 1:1920x1200@60.00*! 2:1920x1080@60.00 3:1600x1200@60.00 4:1680x1050@60.00 5:1280x1024@60.00 6:1440x900@60.00 7:1280x800@60.00 8:1280x720@60.00 9:1024x768@60.00 10:800x600@60.00 11:640x480@60.00 12:1600x900@59.95 13:1600x900@59.95 14:1368x768@59.88 15:1368x768@59.88 Custom modes: None Geometry: 0,0 1920x1200 Scale: 1 Rotation: 1 Overscan: 0 Vrr: Automatic RgbRange: unknown HDR: incapable Wide Color Gamut: incapable ICC profile: none Color profile source: sRGB Color power preference: prefer efficiency and performance Brightness control: supported, set to 85% and dimming to 100% Color resolution: automatic (10), range: [8; 16] bits per color Allow EDR: always Sharpness control: unsupported Automatic brightness: unsupported Output: 2 HDMI-A-1 3220bc19-2a0e-41e9-ace5-69d1cf3fa9f1 enabled connected priority 1 HDMI replication source:0 Modes: 16:2560x1440@59.95*! 17:2560x1440@74.97 18:1920x1200@59.95 19:1920x1080@60.00 20:1920x1080@60.00 21:1920x1080@59.94 22:1920x1080@50.00 23:1680x1050@59.88 24:1600x900@60.00 25:1280x1024@60.02 26:1440x900@59.90 27:1366x768@60.00 28:1280x720@60.00 29:1280x720@59.94 30:1280x720@50.00 31:1024x768@60.00 32:800x600@60.32 33:720x576@50.00 34:720x576@50.00 35:720x480@60.00 36:720x480@60.00 37:720x480@59.94 38:720x480@59.94 39:640x480@60.00 40:640x480@59.94 41:640x480@59.94 42:720x400@70.08 43:1600x1200@59.87 44:1600x1200@74.88 45:1280x1024@74.90 46:1024x768@74.67 47:1920x1200@74.93 48:1280x800@59.81 49:1280x800@74.76 50:1920x1080@74.91 51:1600x900@74.89 52:1368x768@59.88 53:1368x768@74.73 54:1280x720@74.78 Custom modes: None Geometry: 0,0 2560x1440 Scale: 1 Rotation: 1 Overscan: 0 Vrr: Never RgbRange: Automatic HDR: incapable Wide Color Gamut: incapable ICC profile: none Color profile source: sRGB Color power preference: prefer efficiency and performance Brightness control: supported, set to 80% and dimming to 100% DDC/CI: allowed Color resolution: automatic (10), range: [8; 16] bits per color Allow EDR: unsupported Sharpness control: unsupported Automatic brightness: unsupported
Thanks. The kwin maintainers will need to take a closer look.
In case it's helpful, I've been experiencing a couple of other monitor-related bugs that seem like they could be related to this issue. - If I turn my monitor on during the boot process, the login screen doesn't appear, and I'm stuck on a blank screen. - I also happened to turn the monitor on while waking up from sleep, and also got a blank screen. The windows key on my keyboard brought up the start menu, but I couldn't do much else without rebooting.
What a horrid-sounding monitor, TBH!
Please run > udevadm monitor -u while the monitor runs off. Most likely, it'll print a change event and then a second one more than 2s later. Also, try putting > KWIN_DPMS_WORKAROUND_TIMEOUT=30000 into /etc/environment, reboot, and see if that helps. > If I turn my monitor on during the boot process, the login screen doesn't appear, and I'm stuck on a blank screen There are some race conditions with login managers vs. GPU drivers that can be impacted by such things. It's likely not specific to your screen and really needs a generic fix. > I also happened to turn the monitor on while waking up from sleep, and also got a blank screen. The windows key on my keyboard brought up the start menu, but I couldn't do much else without rebooting. That sounds like plasmashell didn't load the wallpaper. If it happens again, check if > systemctl --user restart plasma-plasmashell makes it appear again
(In reply to Zamundaaa from comment #6) Thanks! I ran the command "udevadm monitor -u", turned the monitor off (using a keyboard hotkey that executes a script that runs "kscreen-doctor --dpms off"), and waited for it to come back on. Here's the output: > monitor will print the received events for: > UDEV - the event which udev sends out after rule processing > > UDEV [232.117201] change /devices/pci0000:00/0000:00:08.1/0000:04:00.0/drm/card1 (drm) > UDEV [232.738609] change /devices/pci0000:00/0000:00:08.1/0000:04:00.0/drm/card1 (drm) KWIN_DPMS_WORKAROUND_TIMEOUT=30000 didn't seem to make a difference. I also tried KWIN_DPMS_WORKAROUND_TIMEOUT=120000 just for fun (no effect). > That sounds like plasmashell didn't load the wallpaper. If it happens again, check if systemctl --user restart plasma-plasmashell makes it appear again Weirdly, the same thing happened when running udevadm monitor -u just now. I tried that command and it got plasmashell loaded properly again. Thanks!
> UDEV [232.117201] change /devices/pci0000:00/0000:00:08.1/0000:04:00.0/drm/card1 (drm) > UDEV [232.738609] change /devices/pci0000:00/0000:00:08.1/0000:04:00.0/drm/card1 (drm) Hmm, that's only 0.6s apart, the workaround should trigger for that. After such a hotplug, is the monitor's UUID still the same, or does it change? It's the thing behind "Output: 2 HDMI-A-1" in the kscreen-doctor -o output.
(In reply to Zamundaaa from comment #8) > After such a hotplug, is the monitor's UUID still the same, or does it change? Nope, I just triggered the bug twice and ran kscreen-doctor -o after each time, and I still see the same UUID for both monitors.
Okay, then I have no idea how this is happening.
(In reply to Zamundaaa from comment #10) > Okay, then I have no idea how this is happening. Thanks anyway... If you or anyone else has any ideas about more troubleshooting or tests I can do, I'd be happy to try.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/9560
Git commit 7ef75142e8097564c19052082786f217c54caf29 by Xaver Hugl. Committed on 13/07/2026 at 13:05. Pushed by zamundaaa into branch 'master'. pointer_input: fix waking up screens that temporarily disconnect during dpms The "absolute motion event" is for actual user inputs and can wake up screens. Warp should be used instead, for the system moving the cursor on its own. M +5 -2 autotests/integration/outputchanges_test.cpp M +1 -2 src/pointer_input.cpp https://invent.kde.org/plasma/kwin/-/commit/7ef75142e8097564c19052082786f217c54caf29
Git commit 9ede7673a1aff9e7c3283b76ac1fb6e60d8aef51 by Xaver Hugl. Committed on 13/07/2026 at 18:29. Pushed by zamundaaa into branch 'Plasma/6.7'. pointer_input: fix waking up screens that temporarily disconnect during dpms The "absolute motion event" is for actual user inputs and can wake up screens. Warp should be used instead, for the system moving the cursor on its own. (cherry picked from commit 7ef75142e8097564c19052082786f217c54caf29) Co-authored-by: Xaver Hugl <xaver.hugl@kde.org> M +5 -2 autotests/integration/outputchanges_test.cpp M +1 -2 src/pointer_input.cpp https://invent.kde.org/plasma/kwin/-/commit/9ede7673a1aff9e7c3283b76ac1fb6e60d8aef51
@Zamundaaa Thank you for keeping an eye on this bug, but unfortunately the latest update does not seem to fix my particular issue. I'm on Plasma 6.7.3 and the monitor still comes back on a few seconds after turning off, just like before.
Created attachment 194849 [details] Print what exactly wakes up the screen Alright, could you run that patch (on top of the Plasma/6.7 branch) and get kwin's journal output with it? It should make it more clear what's triggering the wakeup for you.
.
(In reply to Zamundaaa from comment #16) > Created attachment 194849 [details] > Print what exactly wakes up the screen > > Alright, could you run that patch (on top of the Plasma/6.7 branch) and get > kwin's journal output with it? > It should make it more clear what's triggering the wakeup for you. Thanks, but unfortunately I'm unfamiliar with KDE development. Might be a dumb question, but would it be possible to apply that patch locally without actually building Plasma from source?
(In reply to Zamundaaa from comment #16) > Alright, could you run that patch (on top of the Plasma/6.7 branch) and get > kwin's journal output with it? > It should make it more clear what's triggering the wakeup for you. Got it working! Here's the journal output: Aug 12 20:26:59 Echion systemd[1355]: Stopping KDE Wayland Compositor... Aug 12 20:26:59 Echion systemd[1355]: Stopped KDE Wayland Compositor. Aug 12 20:26:59 Echion systemd[1355]: plasma-kwin_wayland.service: Consumed 19.433s CPU time over 12min 48.280s wall clock time, 267.9M memory peak. Aug 12 20:27:11 Echion systemd[15610]: Starting KDE Wayland Compositor... Aug 12 20:27:11 Echion systemd[15610]: Started KDE Wayland Compositor. Aug 12 20:27:12 Echion kwin_wayland[15725]: No backend specified, automatically choosing drm Aug 12 20:27:12 Echion kwin_wayland[15725]: Vulkan validation layer is not installed Aug 12 20:27:12 Echion kwin_wayland[15725]: Vulkan validation layer is not installed Aug 12 20:27:12 Echion kwin_wayland[15725]: Inverse action invalid format, ignoring: "_k_friendly_name" QList() Aug 12 20:27:12 Echion kwin_wayland[15725]: could not create a component for "FreeTube.desktop" Aug 12 20:27:12 Echion kwin_wayland[15725]: waking up because of "HDMI-A-1" "3220bc19-2a0e-41e9-ace5-69d1cf3fa9f1" Aug 12 20:27:12 Echion kwin_wayland[15725]: Could not find a supported platform plugin for platform "wayland-org.kde.kwin.qpa" and session names QList("K> Aug 12 20:27:12 Echion kwin_wayland[15725]: Creating a default fallback platform plugin Aug 12 20:27:12 Echion kwin_wayland_wrapper[15838]: The XKEYBOARD keymap compiler (xkbcomp) reports: Aug 12 20:27:12 Echion kwin_wayland_wrapper[15838]: > Warning: Multiple symbols for level 1/group 1 on key <FK23> Aug 12 20:27:12 Echion kwin_wayland_wrapper[15838]: > Using F23, ignoring XF86TouchpadOff Aug 12 20:27:12 Echion kwin_wayland_wrapper[15838]: > Warning: Symbol map for key <FK23> redefined Aug 12 20:27:12 Echion kwin_wayland_wrapper[15838]: > Using last definition for conflicting fields Aug 12 20:27:12 Echion kwin_wayland_wrapper[15838]: > Warning: Symbol map for key <FK24> redefined Aug 12 20:27:12 Echion kwin_wayland_wrapper[15838]: > Using last definition for conflicting fields Aug 12 20:27:12 Echion kwin_wayland_wrapper[15838]: > Warning: Could not resolve keysym XF86ElectronicPrivacyScreenOn Aug 12 20:27:12 Echion kwin_wayland_wrapper[15838]: > Warning: Could not resolve keysym XF86ElectronicPrivacyScreenOff Aug 12 20:27:12 Echion kwin_wayland_wrapper[15838]: > Warning: Could not resolve keysym XF86ActionOnSelection Aug 12 20:27:12 Echion kwin_wayland_wrapper[15838]: > Warning: Could not resolve keysym XF86ContextualInsert Aug 12 20:27:12 Echion kwin_wayland_wrapper[15838]: > Warning: Could not resolve keysym XF86ContextualQuery Aug 12 20:27:12 Echion kwin_wayland_wrapper[15838]: Errors from xkbcomp are not fatal to the X server Aug 12 20:27:12 Echion kwin_wayland_wrapper[15844]: The XKEYBOARD keymap compiler (xkbcomp) reports: Aug 12 20:27:12 Echion kwin_wayland_wrapper[15844]: > Warning: Unsupported maximum keycode 709, clipping. Aug 12 20:27:12 Echion kwin_wayland_wrapper[15844]: > X11 cannot support keycodes above 255. Aug 12 20:27:12 Echion kwin_wayland_wrapper[15844]: > Warning: Virtual modifier Hyper multiply defined Aug 12 20:27:12 Echion kwin_wayland_wrapper[15844]: > Using 0, ignoring 0 Aug 12 20:27:12 Echion kwin_wayland_wrapper[15844]: > Warning: Virtual modifier ScrollLock multiply defined Aug 12 20:27:12 Echion kwin_wayland_wrapper[15844]: > Using 0, ignoring 0 Aug 12 20:27:12 Echion kwin_wayland_wrapper[15844]: Errors from xkbcomp are not fatal to the X server Aug 12 20:27:42 Echion kwin_wayland[15725]: waking up because of "eDP-1" "d0f0dd55-d2ea-4ff8-ba28-2a19e835c178" Aug 12 20:27:43 Echion kwin_wayland_wrapper[15725]: Waking screen! 0# KWin::Workspace::requestDpmsState(KWin::Workspace::DpmsState) at /home/liam/kde> Aug 12 20:27:43 Echion kwin_wayland_wrapper[15725]: 1# KWin::Workspace::updateOutputs() at /home/liam/kde/src/kwin/src/workspace.cpp:1523 [0x7fc31c22> Aug 12 20:27:43 Echion kwin_wayland_wrapper[15725]: 2# KWin::Workspace::applyOutputConfiguration(KWin::OutputConfiguration&) at /home/liam/kde/src/kw> Aug 12 20:27:43 Echion kwin_wayland_wrapper[15725]: 3# KWin::Workspace::updateOutputConfiguration() at /home/liam/kde/src/kwin/src/workspace.cpp:672 > Aug 12 20:27:43 Echion kwin_wayland_wrapper[15725]: 4# KWin::Workspace::slotOutputBackendOutputsQueried() at /home/liam/kde/src/kwin/src/workspace.cp> Aug 12 20:27:43 Echion kwin_wayland_wrapper[15725]: 5# <unknown> [0x7fc31900fffa] Aug 12 20:27:43 Echion kwin_wayland_wrapper[15725]: 6# KWin::DrmBackend::updateOutputs(KWin::DrmGpu*) at /home/liam/kde/src/kwin/src/backends/drm/drm> Aug 12 20:27:43 Echion kwin_wayland_wrapper[15725]: 7# KWin::DrmBackend::handleUdevEvent() at /home/liam/kde/src/kwin/src/backends/drm/drm_backend.cp> Aug 12 20:27:43 Echion kwin_wayland_wrapper[15725]: 8# <unknown> [0x7fc31900fffa] Aug 12 20:27:43 Echion kwin_wayland_wrapper[15725]: 9# QSocketNotifier::event(QEvent*) [0x7fc319028021] Aug 12 20:27:43 Echion kwin_wayland_wrapper[15725]: 10# QApplicationPrivate::notify_helper(QObject*, QEvent*) [0x7fc31a304c1a] Aug 12 20:27:43 Echion kwin_wayland_wrapper[15725]: 11# QCoreApplication::notifyInternal2(QObject*, QEvent*) [0x7fc318f98a47] Aug 12 20:27:43 Echion kwin_wayland_wrapper[15725]: 12# QEventDispatcherUNIXPrivate::activateSocketNotifiers() [0x7fc3191b4d75] Aug 12 20:27:43 Echion kwin_wayland_wrapper[15725]: 13# QEventDispatcherUNIX::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) [0x7fc3191b5908] Aug 12 20:27:43 Echion kwin_wayland_wrapper[15725]: 14# QUnixEventDispatcherQPA::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) [0x7fc319e00671] Aug 12 20:27:43 Echion kwin_wayland_wrapper[15725]: 15# QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) [0x7fc318fa78b3] Aug 12 20:27:43 Echion kwin_wayland_wrapper[15725]: 16# QCoreApplication::exec() [0x7fc318f9c8f3] Aug 12 20:27:43 Echion kwin_wayland_wrapper[15725]: 17# main at /home/liam/kde/src/kwin/src/main_wayland.cpp:703 [0x5562a5c10a80] Aug 12 20:27:43 Echion kwin_wayland_wrapper[15725]: 18# <unknown> [0x7fc318627d0d] Aug 12 20:27:43 Echion kwin_wayland_wrapper[15725]: 19# __libc_start_main [0x7fc318627e4a] Aug 12 20:27:43 Echion kwin_wayland_wrapper[15725]: 20# _start [0x5562a5c152f4] lines 1-83/83 (END)