Adam Jackson <ajax@xxxxxxxxxx> 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:
signature.asc
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
