Hi Jani, Thanks for your input. So, your suggestion is go back to return -EIO for block > 1, and stop trying to modify the EDID. In this way, we can handle EDID whose blocks is less than 2.
BR, Jammy > > Hi Thomas, > > > > Good catch - returning 0 without writing to buf wasn't safe. But I > > also found that returning -EIO isn't right either: _drm_do_get_edid() > > treats EDID_BLOCK_READ_FAIL as fatal for any block index, not just > > block 0, so that would have discarded the whole EDID for any monitor > > reporting more than one extension. > > > > In v3, for block > 1 I now zero the buffer explicitly and return 0. > > That makes drm_edid's block checker classify it as EDID_BLOCK_ZERO > > instead, which is non-fatal - it gets trimmed via > > edid_filter_invalid_blocks() (extensions count reduced, checksum > > recomputed), and blocks 0 and 1 still come through fine. This also > > directly addresses your point about the buffer not being guaranteed > > zeroed, since we zero it ourselves now. > > There's a long-term goal to *not* modify the EDID in kernel, but rather return > even the broken EDID extensions to userspace, if that's what the display has. > > There are probably a bunch of hurdles in making that happen, but intentionally > returning zeroed out EDID blocks is just adding another unnecessary hurdle. > > > BR, > Jani. > > > -- > Jani Nikula, Intel
