On Mon, 15 Sep 2025, Dave Airlie <airl...@gmail.com> wrote: >> Questions for Community >> ======================= >> >> This issue raises several questions about DisplayID validation approach: >> >> 1. Is this strict validation intentional for all hardware? What are the >> security or stability reasons for treating checksum errors as fatal? >> >> 2. Are minor checksum variations expected in real-world panels? Is this >> type of manufacturing variation common? >> >> 3. How should the kernel handle hardware with minor EDID/DisplayID issues? >> Are there existing mechanisms for such compatibility cases? >> >> 4. What would be the preferred approach for handling this type of >> compatibility issue? Are there existing precedents or guidelines? >> >> 5. Are other users experiencing similar DisplayID validation failures? >> Is this an isolated case or part of a broader pattern? > > There is code already to ignore EDID checksum for CEA extension > blocks, look for EDID_BLOCK_CHECKSUM, it probably could be extended to > cover displayid blocks,
IIRC we ignore CEA extension checksum errors because hubs that incorrectly modified the display's EDID on the fly were so common. Anyway, this is not just about EDID extension block checksums, it's also about DisplayID structure checksum. I'm not sure if the attached EDID is complete, but it's looking like just about all the checksums in it are garbage. > Otherwise I do wonder how common this is, and whether it should be > quirk per panel or just always do it. I think Jon Postel was wrong, and we should never have been liberal in accepting garbage and pretending it was valid data. But with EDIDs, that ship has sailed, and here we are. Considering that a valid checksum isn't exactly a guarantee of valid EDID data inside, I'm starting to lean towards just debug logging EDID and DisplayID checksum errors, and using whatever data we can find inside. BR, Jani. -- Jani Nikula, Intel
