On Mon, 7 Jan 2019 17:07:09 +0000
Brian Starkey <Brian.Starkey@arm.com> wrote:

> On Mon, Jan 07, 2019 at 07:57:54AM -0800, Keith Packard wrote:
> > Daniel Vetter <daniel@ffwll.ch> writes:
> >   
> > > Best to pull in some other compositor people and get them to agree. From a
> > > kernel pov I'm fine with whatever userspace preferes.  
> > 
> > Hrm. It would be good to have everyone using the same interpretation of
> > EDID data; in particular, where the kernel has quirks that change the
> > interpretation, user space should be consistent with that.
> > 
> > Unless we expose all of the EDID data, then user space may still have to
> > parse EDID. If the kernel has EDID quirks, it might be good to to make
> > those affect the "raw" EDID data visible to use space so that values the
> > kernel supplies separately are consistent with values extracted from the
> > "raw" EDID data.  
> 
> If the quirks can be re-encoded back into an EDID representation, then
> this sounds like a fairly good approach to me.
> 
> > 
> > Doing this in the kernel does make it harder to quickly supply fixes for
> > a specific user space application. This will probably lead to
> > kludge-arounds in user space that could depend on kernel
> > version. Perhaps these EDID capabilities in the kernel should be
> > versioned separately?
> > 
> > I see good benefits from having user space able to see how the kernel is
> > interpreting EDID so that it can adapt as appropriate, but we should be
> > cautious about moving functionality into the kernel that would be more
> > easily maintained up in user space.
> >   
> 
> I agree. It seems likely that whatever happens (some) userspace is
> still going to implement (some) EDID parsing functionality, so it's
> hard to reason about what belongs where. Shared code in userspace
> (libdrm?) may well be better than exposing it from the kernel.
> 
> If it is exposed by the kernel, then it's still non-obvious to me
> how the kernel exposes that information/interpretation. Adding
> a property for every potentially-useful field really doesn't scale
> well, and what fields are useful isn't obvious - e.g. serial string vs
> serial no., as mentioned by Simon.
> 
> Uma's recent series: "Add HDR Metadata Parsing and handling in DRM
> layer"[1] is a good example of more stuff which userspace would want to
> parse out of the EDID (supported display colorimetry and transfer
> functions).
> 
> It would be nice to avoid duplicating all the CEA extension parsing
> code, but the EDID/CEA data structure is extensible by design. So the
> kernel API would need to be similarly extensible, or we'll just
> balloon loads of properties... and then the kernel API would likely
> just end up just looking similar to the CEA block anyway.
> 
> Cheers,
> -Brian
> 
> [1] https://lists.freedesktop.org/archives/dri-devel/2018-December/200154.html

I would agree with an effort to establish a userspace EDID parsing
library in any case. As mentioned above, there will probably be too
much to expose via kernel UABI, or it will become just another
encoded format that again should have a shared parser library in
userspace.

Would it be possible to architect the library so that it would be
shared with the kernel? Maybe the quirks database could be shared
with the kernel as well? That way both kernel and userspace would
more or less agree on the parsing details.

I've been dreaming of a "liboutput" that would e.g. parse EDID,
generate CVT video mode timings, and whatnot that all display
servers more or less will duplicate. Once upon a time Ajax started
minitru IIRC...

Another thing for "liboutput" was a device description database,
whose first use would have been the "non-desktop" property. Because
we don't expose monitors through udev to have udev rules tag them
with interesting bits.

Imagine this: monitors exposed as devices via udev, tagged with
helpers as regular monitor, HMD, TV, projector, ... and all EDID
fields decoded as well. And quirks in hwdb. But I suppose that
won't happen, because a "monitor device node" would have no other
use. Except... programmatical monitor controls? Like backlight,
brightness, contrast, and so on.

Ah, nevermind. :-)


Thanks,
pq