Re: Expose more EDID fields to userspace

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

On Wed, Jan 16, 2019 at 08:35:26PM +0200, Pekka Paalanen wrote:
> On Mon, 7 Jan 2019 17:07:09 +0000
> Brian Starkey <Brian.Starkey@arm.com> wrote:
> 
> > On Mon, Jan 07, 2019 at 07:57:54AM -0800, Keith Packard wrote:
> > > 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.  
> > 
> > If the quirks can be re-encoded back into an EDID representation, then
> > this sounds like a fairly good approach to me.
> > 
> > > 
> > > 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.
> > >   
> > 
> > I agree. It seems likely that whatever happens (some) userspace is
> > still going to implement (some) EDID parsing functionality, so it's
> > hard to reason about what belongs where. Shared code in userspace
> > (libdrm?) may well be better than exposing it from the kernel.
> > 
> > If it is exposed by the kernel, then it's still non-obvious to me
> > how the kernel exposes that information/interpretation. Adding
> > a property for every potentially-useful field really doesn't scale
> > well, and what fields are useful isn't obvious - e.g. serial string vs
> > serial no., as mentioned by Simon.
> > 
> > Uma's recent series: "Add HDR Metadata Parsing and handling in DRM
> > layer"[1] is a good example of more stuff which userspace would want to
> > parse out of the EDID (supported display colorimetry and transfer
> > functions).
> > 
> > It would be nice to avoid duplicating all the CEA extension parsing
> > code, but the EDID/CEA data structure is extensible by design. So the
> > kernel API would need to be similarly extensible, or we'll just
> > balloon loads of properties... and then the kernel API would likely
> > just end up just looking similar to the CEA block anyway.
> > 
> > Cheers,
> > -Brian
> > 
> > [1] https://lists.freedesktop.org/archives/dri-devel/2018-December/200154.html
> 
> I would agree with an effort to establish a userspace EDID parsing
> library in any case. As mentioned above, there will probably be too
> much to expose via kernel UABI, or it will become just another
> encoded format that again should have a shared parser library in
> userspace.
> 
> Would it be possible to architect the library so that it would be
> shared with the kernel? Maybe the quirks database could be shared
> with the kernel as well? That way both kernel and userspace would
> more or less agree on the parsing details.

IIRC long ago I did manage to build drm_edid.c in userspace.
My idea was to potentially fuzz it without oopsing the kernel.
But I didn't get beyond just making it build before getting
distracted by something shinier.

Taking that further would involve pulling the edid parser into
a userspace helper entirely. Unfortunately that would open up
the big can of "how do we parse the edid during boot?" worms.
But I do kinda like the idea of not having the kernel parse
untrusted input directly.

-- 
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel