Re: Expose more EDID fields to userspace

["Keith Packard" <keithp@keithp.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2759 bytes --]

Stéphane Marchesin <stephane.marchesin@gmail.com> writes:

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

Yeah, I think I've talked myself out of modifying EDID too. What I'm
thinking this afternoon is that we should ensure that every value
derived from EDID, (and potentially modified by the kernel), needs to be
exposed to user space so that it too can play with the same
information.

If we could get a common EDID parsing library shared between kernel and
user space, that would at least give everyone the same view of the data.

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

Oh, that's a fine point -- what this exposes is that user space should
be able to see the lower pixel clock value which the kernel is
using. And doing that separate from the EDID data means it can explain
what's going on.

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

If this isn't used by the kernel, then doing it in user space is
probably the right plan.

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

Right, having a shared library and database for these kinds of quirks
would be awesome.

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

Agreed, as long as we also fix the kernel to tell user space what it's
doing with the EDID data, especially where it's modifying values.

-- 
-keith

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel