edid-decode doesn't understand first block of secondary display

edid-decode doesn't understand first block of secondary display

[Daniel Silva]

Hello,

I was troubleshooting an issue along with one of the devs at OSMC and
while using my laptop with edid-decode they mentioned something they
noticed what seemed like a bug in edid-decode:

"edid-decode is reading the EDIDs for both the Mac internal display
and the HDMI attached display, then it says it doesn’t understand the
first block of the HDMI EDID"

You can see the whole forum thread here for context:
https://discourse.osmc.tv/t/nothing-will-play-on-vero-v/112768/22

I just figured the devs of edid-decode might be interested and wanted
to report it.

Cheers!

Daniel

Re: edid-decode doesn't understand first block of secondary display

[Hans Verkuil]

Hi Daniel,

On 28/08/2026 20:42, Daniel Silva wrote:
> Hello,
> 
> I was troubleshooting an issue along with one of the devs at OSMC and
> while using my laptop with edid-decode they mentioned something they
> noticed what seemed like a bug in edid-decode:
> 
> "edid-decode is reading the EDIDs for both the Mac internal display
> and the HDMI attached display, then it says it doesn’t understand the
> first block of the HDMI EDID"
> 
> You can see the whole forum thread here for context:
> https://discourse.osmc.tv/t/nothing-will-play-on-vero-v/112768/22
> 
> I just figured the devs of edid-decode might be interested and wanted
> to report it.

Apologies for the late reply, I only just found this email.

The main question is how the EDID was read.

Looking here: https://paste.osmc.tv/melucavigu.vhdl I see basically two
EDID interleaved. So there must be something wrong in how the EDID itself
was read. edid-decode just parses the EDID, it doesn't read it (unless you
use the -a and --i2c-edid options).

edid-decode could be a bit smarter, i.e. if it encounters an extension
block starting with '00 ff ff ff ff ff ff 00' it should just say that the
EDID data is corrupt.

Regards,

	Hans