Re: Expose more EDID fields to userspace

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

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

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.

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.

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