https://bugs.kde.org/show_bug.cgi?id=515697
--- Comment #2 from [email protected] --- (In reply to Zamundaaa from comment #1) > KScreen should not have workarounds to this extent, and it cannot do so > reliably. Connector names are not generally stable, what happens to work on > your system will cause additional problems on others. > > This does affect way too many users, but it really needs to be fixed in the > driver, not worked around. > The best we could possibly do is recommend the user to disconnect and > re-connect their screen as a temporary workaround, but as there are > (unfortunately) also many legitimate cases where the EDID is missing, even > that is challenging as well. I agree that this fundamentally should be fixed in the driver, and that KScreen should not apply silent or automatic workarounds. I am not proposing that KScreen override EDIDs automatically or attempt to mask broken hardware behavior. What I am proposing instead is a user-driven recovery assistant that KScreen could offer when it detects a clear degradation: an output that previously had a valid EDID suddenly reporting a broken or missing EDID, most commonly after suspend/resume. Regarding the connector matching concern, I acknowledge that after examining real-world EDID failures, fully reliable automatic matching is not possible. When EDID acquisition fails, even partial EDID data is often corrupted (for example, incorrect manufacturer IDs), and KScreen’s UUIDs can change between the working and broken states. In practice, this leaves connector names as the only usable identifiers, and you are absolutely right that these are not guaranteed to be stable in the general case. That said, I believe there is still value in a deliberately simple and explicitly user-mediated approach. During normal operation, when KScreen successfully receives a valid EDID, it could store that EDID indexed by the connector name at that time (for example: “DP-1 -> EDID blob with manufacturer, model, and preferred mode metadata”). If the same connector name later reports a degraded or missing EDID, KScreen would not apply anything automatically, but instead present a troubleshooting dialog explaining the situation and offering the user an explicit choice. For example, the dialog could say that the display on DP-1 has lost its configuration and is running at 640×480, note that a working EDID was previously observed on that connector (e.g. “Dell U2415, 2560×1440”), and offer options such as trying that EDID, choosing a different previously seen EDID if more than one exists, or canceling. If multiple EDIDs are available, they can be shown with recognizable details so users can make an informed decision or opt out entirely. This approach remains useful despite connector instability because connector names are typically stable within a boot session and across suspend/resume cycles on unchanged hardware, which is exactly where most of these failures occur. The failure mode is also safe: if connector naming changed due to hardware reconfiguration, users are presented with recognizable monitor details and can simply reject incorrect matches. In practice, users understand their own hardware setups better than any heuristic, and this assists the common “worked before suspend, broken after” case without pretending to solve the general case. This would not help users who frequently swap monitors between ports, whose systems genuinely renumber connectors unpredictably, or whose displays permanently lack EDID (such as some KVMs or very old hardware). It does not attempt to address those scenarios. However, for users with stable hardware who experience intermittent EDID loss - a large portion of the reported cases - this provides a straightforward, transparent recovery path without requiring forum searches, wiki digging, or kernel command-line overrides. In short, this is not about KScreen working around driver bugs automatically, but about offering a clearly scoped, user-initiated recovery tool when the KScreen daemon detects a regression from a previously healthy state. -- You are receiving this mail because: You are watching all bug changes.
