Re: Expose more EDID fields to userspace

[Daniel Vetter <daniel@ffwll.ch>]

On Wed, Jan 16, 2019 at 12:32:58PM -0800, Keith Packard wrote:
> 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

Connector properties are documented here:

https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#standard-connector-properties

I think we've caught up and have them all documented now, at least all the
ones that have been standardized. There's not much, from a quick look we
expose the following immutable props for userspace's benefit:

EDID, PATH, TILE (this has been used for other composite screens, not just
MST), non_desktop, "panel orientation". Plus vrr_capable, which is
documented in a separate chapter. All the other properties are meant
to be set, or not about parsing sink information.

For all the other bits I think it'd be good to do a better job, but most
likely we'll just muddle on. Exhibit A: The super consistent naming
scheme for properties we have, see above :-)

But in case we're going to do better, fully agree on documenting all this.
-Daniel

>  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



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


-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel