| Summary: | Monitor's input change is treated as temporary disconnect | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Mariusz Mazur <mariusz.g.mazur> |
| Component: | multi-screen | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED UPSTREAM | ||
| Severity: | normal | CC: | xaver.hugl |
| Priority: | NOR | ||
| Version First Reported In: | 6.4.80 | ||
| Target Milestone: | --- | ||
| Platform: | KDE Linux | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Mariusz Mazur
2025-09-06 20:37:22 UTC
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. |