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