On Mon, Dec 31, 2018 at 12:57:24PM +0000, Simon Ser wrote:
> 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?
Best to pull in some other compositor people and get them to agree. From a
kernel pov I'm fine with whatever userspace preferes.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
