On Monday, December 24, 2018 11:23 AM, Daniel Vetter <daniel@xxxxxxxx> 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?
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
