On Mon, 27 Jul 2026, Fangzhi Zuo <[email protected]> wrote:
> Hi Timo,
>
> Thanks for the patch. Heads-up that this overlaps with a fix already in
> amd-staging-drm-next:
>
> 21590e1adc9e ("drm/amd/display: Fix 8K Mode Not Parsed by EDID")
More precisely commit 11a90eaf5c80 ("drm/amd/display: Fix 8K Mode Not
Parsed by EDID") upstream.
> That commit addresses the same underlying problem your patch targets --
> edid->extensions (byte 0x7e) not accounting for HF-EEODB blocks, so only
> 2 of 4 blocks of an HDMI 2.1 EDID get copied into sink->dc_edid and the
> 8K modes in the DisplayID extension blocks are lost. It takes a slightly
> different approach: instead of drm_edid_block_count(), it populates
> edid_blob_ptr with a full, HF-EEODB-aware blob and copies
> edid_blob_ptr->length. So on current amd-staging the
> dm_helpers_read_local_edid() hunk here no longer applies cleanly.
That's an awful, ugly hack. Please work to remove it. Drivers are not
supposed to look at or use connector->edid_blob_ptr at all. See the
documentation.
I really did put in a *lot* of effort into abstracting HF-EEODB properly
and neatly for everyone, across the subsystem. The opaque struct
drm_edid is the abstraction. Please embrace it, and you'll get HF-EEODB
for free, with no hacks.
If you face issues, please talk to me instead of hacking stuff and
intentionally working around the the abstractions.
> Could you rebase on the latest amd-staging-drm-next and see what, if
> anything, is still needed on top? There may still be value in the
> helper conversion for readability, but we should avoid re-fixing the
> same HF-EEODB issue two different ways.
The one and only fix for HF-EEODB is to use struct drm_edid everywhere.
BR,
Jani.
--
Jani Nikula, Intel
