[PATCH 1/3] Extract the EDID blob when adding a DRM output

[Graeme Gill]

David Herrmann wrote:

> If you want to keep the EDID blob, could you describe a specific
> use-case?

Taking a hash of it to identify a particular display.

Implementing specific workarounds for displays where
the built in parser gives up.

Dealing with extensions to the EDID standard.

> Patch 3/3 parses the blob and keeps the parsed values. Why
> should we keep the binary blob, too? If we need more EDID values, we
> simply extend the parser?

This would seem to imply that every time a client/application needs some
piece of information from the EDID that hasn't been allowed for,
an update to the display server is needed.

> If we keep the blob, all code that accesses it needs to work around
> these horribly formatted entries which patch 3/3 tries to overcome.

I think the idea would be to have both (a minimal set of parsed
information, + the blob), or relegate the parsing to a client
library would be another approach, although supplying that
client library by default would be a good thing, rather
than leaving everyone to re-invent EDID parsing badly.

> If
> we instead parse the blob once and then drop the binary blob, we can
> safely access all entries from anywhere.

That assumes all entries have been parsed.

Graeme Gill.