<p dir="ltr">Hi</p>
<p dir="ltr">On Apr 23, 2013 6:38 AM, "Graeme Gill" <<a href="mailto:graeme2@argyllcms.com">graeme2@argyllcms.com</a>> wrote:<br>
><br>
> David Herrmann wrote:<br>
><br>
> > If you want to keep the EDID blob, could you describe a specific<br>
> > use-case?<br>
><br>
> Taking a hash of it to identify a particular display.<br>
><br>
> Implementing specific workarounds for displays where<br>
> the built in parser gives up.<br>
><br>
> Dealing with extensions to the EDID standard.</p>
<p dir="ltr">We can do all this without keeping the blob, but see below...</p>
<p dir="ltr">> > Patch 3/3 parses the blob and keeps the parsed values. Why<br>
> > should we keep the binary blob, too? If we need more EDID values, we<br>
> > simply extend the parser?<br>
><br>
> This would seem to imply that every time a client/application needs some<br>
> piece of information from the EDID that hasn't been allowed for,<br>
> an update to the display server is needed.</p>
<p dir="ltr">Please read the patch. This is a display server internal feature, clients aren't involved. It's about the display server parsing the EDID blob for its own use!</p>
<p dir="ltr">If you want clients to be involved, it's a separate feature and you can keep the blob if you need it. But this doesn't belong in this patch.</p>
<p dir="ltr">Regards<br>
David</p>