https://bugs.kde.org/show_bug.cgi?id=484037
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED |--- --- Comment #36 from [email protected] --- (In reply to Nate Graham from comment #35) > This is a fairly old bug report and the code has changed a lot since it was > reported. There's a very good chance the issue you're experiencing is caused > by something else, even if the outward symptoms look and feel the same. Can > you please submit a new bug report? Thank you! It *is* a fairly old bug, but to my knowledge it was never actually fixed. I am still experiencing it on current versions, on both X11 and Wayland. When the issue occurs, the monitor’s EDID is present at the DRM level but contains only a minimal, non-descriptive base block. Specifically, /sys/class/drm/card1-DP-1/edid contains a valid EDID header and checksum, but no meaningful payload: no detailed timing descriptors, no monitor identification, and no extension blocks. As a result, KMS exposes only the fallback [email protected] mode. This is reflected in kscreen-doctor, which reports the output as connected and enabled, but with only a single 640×480 mode available. In this state, turning the monitor off and on again sometimes results in a full, correct EDID being exposed, though a reboot is often faster and more reliable. As an experiment, I cached the monitor’s EDID and configured the kernel to always use the cached version instead of re-querying the monitor on power events. Since doing this (for a few days now), I have not encountered the issue again. However, in the past—especially on Wayland—it could take more than a few days to manifest, so this workaround is not yet a confirmed fix. -- You are receiving this mail because: You are watching all bug changes.
