Login screen monitor layout not applied correctly possible EDID read timing issue?

Help
, ,
1

Hi all,

I’m hitting a bug where my login screen doesn’t apply the correct multi-monitor layout, and I wanted to check here before filing anything in case there’s a workaround I’m missing.

Setup: Arch Linux, Plasma 6.7, Qt 6.11.1, Wayland, AMD RX 9070 XT (Mesa/RADV). Four monitors: two 2560×1440 Samsung displays at 180Hz (left/right), one 2560×1440 MSI display at 165Hz (center), and a small 800×480 display below center.

The bug: the login screen’s monitor positioning doesn’t match my actual desktop layout, even after clicking “Apply Plasma Settings” in System Settings → Login Screen. I’ve confirmed /var/lib/plasmalogin/.config/kwinoutputconfig.json is byte-for-byte the same as my own ~/.config/kwinoutputconfig.json after applying, so the file is being copied correctly the problem seems to be on the read/apply side at login, not a stale copy.

I also know manually editing the file isn’t a viable fix since KWin rewrites it from internal state on logout regardless (this matches the behavior in bug 516329).

Why I suspect EDID timing: my center monitor (MSI) is known to be slow to wake from sleep this seems to be a fairly common complaint with MSI displays across platforms, not Linux-specific. Looking through my kwinoutputconfig.json, I found that one of my other monitors (a Samsung, not even the slow one) has three separate output entries: one with the correct EDID and refresh rate, one with the same EDID but a different (lower) refresh rate, and one with no EDID hash at all, falling back to a generic 640×480@60Hz mode. That last one really stood out it looks like on at least one boot, KWin couldn’t read that monitor’s EDID in time and just wrote a fallback entry instead of recognizing it as the same display.

So my theory is: on some boots, one or more displays don’t report their EDID fast enough, KWin treats them as unrecognized/new outputs, and writes degraded or duplicate entries instead of matching them to the existing config and this is likely happening again at the login screen, which only gets one shot at applying things before the greeter renders, with no time for a slow-waking display to catch up.

Two questions:

  1. Has anyone else run into the login screen mis-positioning monitors, and is there a known fix or setting I’m missing?
  2. Is there a safe way to prune kwinoutputconfig.json of stale/duplicate entries without them just reappearing on the next reboot or display wake?

Happy to share the full config or system info if useful. Thanks!

2

Wanted to add a couple of things I left out originally, since they make the EDID-timing theory more concrete.

This is still an active, ongoing issue for me, not something that happened once a while back I’m seeing the same symptoms as of today.

I went back through journalctl and found KWin explicitly logging an EDID read failure for my MSI display (DP-3) on wake:

kwin_wayland[1471]: Could not find edid for connector DrmConnector(id=117, gpu="/dev/dri/card1", name="DP-3", connection="Connected", countMode=43)

So this isn’t just inference from the config file KWin is outright failing to read that monitor’s EDID on at least some wake/boot cycles, which lines up with the duplicate/no-EDID entries I described above for my other displays.

Is there any actual user-facing way to extend whatever timeout governs EDID/output detection during wake or boot? I haven’t been able to find one documented anywhere, but it seems like the kind of thing that would help here if it exists.

One more relevant detail: this isn’t only a login-screen/cosmetic issue. Separately, I’ve seen actual functional failures where, after putting my monitors to sleep, one or two of them simply won’t wake back up on their own and it’s not consistently the same monitor each time. I’ve had to manually intervene to bring them back. Given the EDID-not-found log line above, I suspect this is the same underlying cause: whichever monitor happens to be slow on a given wake cycle gets skipped by KWin’s detection before it’s ready, and depending on timing that can be the MSI display or one of the others.