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. _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
