Expose more EDID fields to userspace

[Stéphane Marchesin]

On Mon, Jan 7, 2019, 09:07 Brian Starkey <Brian.Starkey at arm.com wrote:

> On Mon, Jan 07, 2019 at 07:57:54AM -0800, Keith Packard wrote:
> > Daniel Vetter <daniel at 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.
>


I don't have strong feelings for against this approach, but if we do this,
I think we should ensure we keep providing the original EDID to user space.
The contents of EDIDs have so many implications that even the kernel isn't
always in the best position to decide if a rewrite is a good idea.

For a simple example, we can look at the max pixel clock which is reported
in the EDID. If the EDID gets rewritten with a lower pixel clock that
matches what the link can do, user space loses the ability to pop up a UI
dialog telling the user that if they were using a better cable, they could
get higher resolutions. Something similar already happens today with some
display dongles which decide to rewrite EDIDs based on their own
limitations. It prevents user space from showing a dialog recommending a
better dongle. Of course one could argue the dongle is protecting itself
here :)



> >
> > 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).
>

FWIW for Chrome OS we do parse the color space in user space, since as you
mention this isn't available through the DRM properties.

Tangentially related, the content of these color points is often very...
"buggy". We have to do some sanity checking before deciding to use it or
not. That's why I think that even with all the information parsed by the
kernel, you still need another layer...



>
> 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.
>

Yes I like the idea of parsing in user space, since it doesn't require new
kernel changes at all, and typically updating a user space library is
simpler than changing kernel versions. Frankly it feels to me that the
kernel doesn't really have a business here except passing through the raw
EDID contents to a component which knows better.

Stéphane



>
> Cheers,
> -Brian
>
> [1]
> https://lists.freedesktop.org/archives/dri-devel/2018-December/200154.html
>
> > --
> > -keith
>
>
>
> > _______________________________________________
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20190117/96abc273/attachment.html>