Expose more EDID fields to userspace

[Simon Ser]

On Monday, December 24, 2018 11:23 AM, Daniel Vetter <daniel at ffwll.ch> wrote:
> On Sun, Dec 23, 2018 at 09:16:13AM +0000, Simon Ser wrote:
>
> > Hi all,
> > Right now, the kernel parses EDIDs and exposes some of the data to
> > userspace. For instance, drmModeConnector has mm{Width,Height} and
> > subpixel.
> > Generally, userspace also has another EDID parser. For instance,
> > wlroots uses it just to get the make/model/serial. I've talked about
> > this at XDC 2018, and someone mentioned it could be a good idea to
> > de-duplicate the work.
>
> Could have been me ...
>
> > Would it be reasonable to expose those as DRM connector properties?
>
> Yes, very much. Aside from the kernel-side implementation all we need is
> the userspace per
>
> https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements
>
> Important: Don't merge the userspace side into your main branch before
> it's all reviewed.
>
> And ideally some igts (we have infrastructure to inject edids and hence
> can check that the right stuff comes back):
>
> https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#testing-and-validation

Thanks! I've began to implement this, but I'm wondering what's the best
way to expose this piece of information to userspace.

I can think of two solutions:

1. A single IDENTIFICATION blob containing one struct with
   make/serial/model.
2. Three properties: MAKE, MODEL, SERIAL.

I also wonder if it's worth it to expose both the uint32_t for serial
and the serial string, or just the serial string. Some monitors don't
have a serial string, but we can generate one from the uint32_t (e.g.
hex). Same applies to model.

Thoughts?