SUMMARY When using a monitor connected to multiple computers, switching inputs of said monitor (using monitor's "input source" setting) should not cause any visible disruption to other screens. It correctly doesn't on windows and gnome, but does on kde (screens go blank and generally spaz out for a few seconds before settling). STEPS TO REPRODUCE 1. Get a laptop with kde, connect it to at least one external monitor with multiple possible inputs (e.g. hdmi1, hdmi2, dp), extend the display across laptop and external monitor and set the external monitor as primary (though this last part is likely optional). 2. Assuming my kde is hdmi1 and something else is hdmi2 -- switch monitor to hdmi2. 3. Everything's fine, now I see the other computer's desktop on my monitor. 4. Switch monitor back to hdmi1. OBSERVED RESULT Laptop's display (and any other ones if I had more than one connected) goes blank for a few seconds as kde takes the time processing a disconnect and then connect event (I was in kde linux's display settings and it said something about having to refresh due to disconnect). After a few seconds everything looks as it should (save some windows that got misplaced due to the temporarily missing monitor). EXPECTED RESULT Same thing that happens on windows and gnome -- monitor switches back the input, which has zero impact on any other displays and is near immediate (as fast as the monitor can do it). SOFTWARE/OS VERSIONS Guess the most relevant would be that this fails on latest kde linux 202509031309: KDE Plasma Version: 6.4.80 KDE Frameworks Version: 6.18.0 Qt Version: 6.9.2 Kernel: 6.16.4-arch1-1 Wayland ADDITIONAL INFORMATION Hardware/software combos tested were: - Thinkpad t14 gen 4: - FAILS fedora 42 with kde (plasma 6.4.4, frameworks 6.17.0, qt 6.9.1, kernel 6.15.9-201, wayland) - Another recent Thinkpad - WORKS windows 11 pro - HP Probook 440 G9 - WORKS fedora 42-1.1 with gnome (gnome 48, wayland, kernel 6.14.0-63) - FAILS kde linux 2025-09-03 (plasma 6.4.80, frameworks 6.18.0, qt 6.92, kernel 6.16.4-arch1-1, wayland) - Monitors - Dell S3220DGF - Dell P2425
KWin doesn't have any influence over hotplug events, or whether or not a modeset is required to apply the needed changes when it does happen. You can report it to your graphics card vendor to tweak the hotplug detection sensitivity, though in my experience this kind of issue is both low priority and difficult to figure out: - https://gitlab.freedesktop.org/drm/i915/kernel/-/issues for Intel - https://gitlab.freedesktop.org/drm/amd/-/issues for AMD
On gnome this works just fine using the same drivers, same hardware. I get wanting to close a potentially complicated bug with a WONTFIX, but I'd appreciate a valid reason, not blaming kernel-level problems, which are *demonstrably* not an insurmountable obstacle. Maybe gnome's doing something super complicated to work around this. Or maybe it's a relatively simple fix, should someone familiar with the space look into it.
I'll bump KWIN_DPMS_WORKAROUND_TIMEOUT to something much larger and see if that's sufficient as a workaround. I am confused by how mutter does it, since I can't (with a very quick look) find a similar timeout setting... is it possible they can distinguish somehow between "disconnect" event types. I'll try to dig in a bit more as time allows.
Gnome 48 doesn't have any workarounds for temporary disconnects. They added a workaround in 49, after talking to me about the dpms workaround we have in KWin. > KWIN_DPMS_WORKAROUND_TIMEOUT Won't do anything here, it's for dpms, not for hotplugs. Hotplugs are always processed immediately. If you're okay with patching KWin, you could try delaying processing of udev events (in drm_backend.cpp). Delaying by 500ms or something could maybe be an acceptable workaround, even if I don't really want to go down that route. > I get wanting to close a potentially complicated bug with a WONTFIX, but I'd appreciate a valid reason, not blaming kernel-level problems, which are *demonstrably* not an insurmountable obstacle That is a thing a lot of people report bugs to us claim, and I get where you're coming from, but that line of reasoning is not correct. Just because something Gnome does or doesn't do happens to not trigger a kernel bug, doesn't mean that it's not still very much a kernel bug. Gnome ootb uses 8 bits per color, and uses KMS differently from what we do. It not happening on Gnome is a data point, not proof that we can 'fix' the issue in Plasma. Even if Gnome had a workaround, the underlying cause of the issue is still a thing the kernel has to take care of.
Ok, I did some quick head-to-head testing between a fedora 42 gnome and kde (hp and thinkpad laptops) connected to the offending monitor's hdmi ports. I just kept switching between them. 1. The monitor indeed sends (what I assume to be) disconnect and reconnect events. 2. Plasma reacts *immediately* to the extent that usually screens go blank before the konsole window with `udevadm monitor` running could show me the event. After 1.5-2.5 seconds the second ("connect", I assume) event comes in and things go back to normal. 3. Gnome doesn't react to first event at all. Roughly 0.5s later the second one comes in. No visible reaction from gnome at all. I don't know why the plasma laptop gets the events with a much larger time gap (though I do have two theories: either something in the hardware/configs between the laptops or the fact that plasma starts "reconfiguring" immediately somehow causes the delay in the second event arriving). I also don't know why gnome ignores the initial disconnect event, though I have a theory that they ignore certain events for roughly 3 seconds before reacting. I'll dig some more when I'll have the time.
Hehe, yup, it's 3 seconds exactly: https://gitlab.gnome.org/GNOME/mutter/-/commit/b7607fdcbab993ba96291d16e5c5b4dcf027f689 The code for this is fairly new and seems it was added precisely to handle monitors that do weird things "and then temporarily appearing disconnected": https://gitlab.gnome.org/GNOME/mutter/-/commit/313860e2fab15249337f70d0c298dd02b903c7b9 Seems monitor are what they are and workarounds are the only way to handle them gracefully. (I suspect Windows does something similar.) In light of the above, can I get a reassessment of the issue? I'm sure I'm not the only one for whom gnome's handling of external monitors seems much more stable because of this.