Re: [Intel-gfx] [v8 3/5] drm/edid: read HF-EEODB ext block

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

On Wed, Mar 23, 2022 at 12:11:50PM +0200, Jani Nikula wrote:
> On Thu, 17 Mar 2022, Lee Shawn C <shawn.c.lee@intel.com> wrote:
> > According to HDMI 2.1 spec.
> >
> > "The HDMI Forum EDID Extension Override Data Block (HF-EEODB)
> > is utilized by Sink Devices to provide an alternate method to
> > indicate an EDID Extension Block count larger than 1, while
> > avoiding the need to present a VESA Block Map in the first
> > E-EDID Extension Block."
> >
> > It is a mandatory for HDMI 2.1 protocol compliance as well.
> > This patch help to know how many HF_EEODB blocks report by sink
> > and read allo HF_EEODB blocks back.
> 
> It still just boggles my mind that they've implemented something like
> this. They cite avoiding the EDID Block Map as the rationale... but it's
> been optional since E-EDID structure v1.4, published in 2006. 15+ years
> ago.
> 
> Can anyone tell me a sane reason for this? What does it provide that
> E-EDID 1.4 does not? Do they want to use E-EDID v1.3 with this? Why?

Looks to be pretty much the same approach as the DPCD extended
receiver cap mess we already have to deal with.

So I presume this is a hack to avoid breaking some garbage source
devices that explode when they see too many extension blocks,
or something along those lines.

-- 
Ville Syrjälä
Intel