Re: Expose more EDID fields to userspace

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

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

Adam Jackson <ajax@redhat.com> writes:

> If the kernel wanted to expose its quirks db somehow the library could
> certainly be taught to use it. However there are likely to be quirks
> relevant only to userspace (see below), making the kernel carry that
> doesn't make a ton of sense.

We do expose some of the quirks to user space, but not as a database,
and not consistently. Some of the quirks just match EDID data to drive
some decision (like non-desktop). Other quirks override some EDID data
that is 'wrong'. For these latter instances, I wonder if we shouldn't be
re-writing the EDID data that user space gets? Or at least making sure
the quirked values are available to user space?

> Part of the problem with the idea is that EDID parsing is not
> unambiguous. There are several fields for "physical output size" with
> slightly different semantics, which one do you want? There are both
> structured and free-form ways to encode monitor name and serial
> number.

Hrm. For places where the kernel *does* parse the data, it would sure be
nice to have the kernel version to at least make that
consistent. Model/serial data used to select quirks seems like something
we should be exposing?

I'm getting the feeling that either extreme approach (parse all of the
EDID data, or parse none of it) is not going to work and that our
current technique of picking some EDID-derived data to expose as
separate parsed values, and some to leave for user space to discover for
itself is where we'll be stuck for at least the near term.

If we come to agreement that this approach is what we'll be doing, then
I'd like to have a couple of suggestions:

 1) Document what we've got today

 2) Document basic guidelines of when to expose parsed EDID-derived data
    and when to just leave it in the EDID block for user space

 3) Plan on exposing all values which the kernel *does* use internally
    as parsed-out properties. Especially values which get quirked,
    possibly exposing both the "raw" value and the "quirk" value.

 4) Decide if we want to let user-space in on the quirking fun. I can
    imagine a user-space helper that gets run at hot-plug time, reads
    the EDID data and then pokes quirk values into the kernel.

 5) Decide, as a matter of policy, whether the kernel will ever edit
    EDID data that gets exposed to user space. I can think of good
    reasons on both sides, but I think we need to hash out what the
    kernel will do so that user space knows what's going on.

I think what I want is for kernel and user space to at least be
operating on the same data, even if we end up re-implementing a pile of
code 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