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

David Herrmann dh.herrmann at gmail.com
Sat Apr 20 08:34:35 PDT 2013


Hi

On Sat, Apr 20, 2013 at 3:31 PM, Kai-Uwe Behrmann <ku.b at gmx.de> wrote:
> Am 20.04.2013 13:12, schrieb David Herrmann:
>
>> On Fri, Apr 19, 2013 at 9:19 PM, Kai-Uwe Behrmann <ku.b at gmx.de> wrote:
>>>
>>> Am 19.04.2013 21:12, schrieb David Herrmann:
>>>
>>>> Why do you keep the blob around all the time? Just free it in
>>>> create_output_for_connector() after you parsed it. If we somehow need
>>>> it later, we can always change it again. But your patches don't depend
>>>> on it being around all the time so lets just free it right away.
>>>
>>>
>>>
>>> The EDID blob is exposed under X11, which is a good thing in many cases.
>>> Do
>>> you have a special reason to suggest otherwise on Wayland/Weston?
>>
>>
>> This patchset doesn't expose the blob.
>
>
> Then the patch set is of limited use.
>
>
>> Why do you want to keep it around then?
>
>
> EDID is a pretty essential pice of information. It is more helpful to expose
> the EDID data blob completly, than only a few values selectively.

If you want to keep the EDID blob, could you describe a specific
use-case? 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?

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. If
we instead parse the blob once and then drop the binary blob, we can
safely access all entries from anywhere.

I think it's of little use to keep EDID values around because we might
some day want to use them. Why not extend the parser every time we add
code that needs more values?

Cheers
David


More information about the wayland-devel mailing list