On Mon, Jan 7, 2019, 09:07 Brian Starkey <Brian.Starkey@xxxxxxx wrote:
On Mon, Jan 07, 2019 at 07:57:54AM -0800, Keith Packard wrote:
> Daniel Vetter <daniel@xxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
