[PATCH] drm: document that user-space should avoid parsing EDIDs

[Ville Syrjälä]

On Fri, Oct 09, 2020 at 04:56:51PM +0300, Pekka Paalanen wrote:
> On Fri, 9 Oct 2020 16:10:25 +0300
> Ville Syrjälä <ville.syrjala at linux.intel.com> wrote:
> 
> > On Fri, Oct 09, 2020 at 01:07:20PM +0100, Daniel Stone wrote:
> > > Hi,
> > > 
> > > On Fri, 9 Oct 2020 at 10:24, Simon Ser <contact at emersion.fr> wrote:  
> > > > User-space should avoid parsing EDIDs for metadata already exposed via
> > > > other KMS interfaces and properties. For instance, user-space should not
> > > > try to extract a list of modes from the EDID: the kernel might mutate
> > > > the mode list (because of link capabilities or quirks for instance).
> > > >
> > > > Other metadata not exposed by KMS can be parsed by user-space. This
> > > > includes for instance monitor identification (make/model/serial) and
> > > > supported color-spaces.  
> > > 
> > > So I take it the only way to get modes is through the connector's list
> > > of modes. That sounds reasonable enough to me, but I think to properly
> > > handle colour (e.g. CEA modes have different behaviour for
> > > limited/full range depending on which VIC they correspond to IIRC)  
> > 
> > If the mode has a VIC and that VIC is not 1, then it's limited range,
> > otherwise full range. There are fortunately no cases where you would
> > have the same exact timings corresponding to different quantization
> > range depending on the VIC.
> > 
> > And the only reason the same timings could correspond to multiple VICs
> > is aspect ratio. Which is already exposed via the mode flags, assuming
> > the appropriate client cap is enabled.
> > 
> > So I think the only reason to expose the VIC would be if userspace is
> > non-lazy and wants to manage its colors presicely, but is otherwise lazy
> > and doesn't want to figure out what the VIC of the mode is on its own.
> 
> What would "figure out what the VIC of the mode is" require in userspace?
> 
> A database of all VIC modes and then compare if the detailed timings match?
> 
> Is that also how the kernel recognises that userspace wants to set a
> certain VIC mode instead of some arbitrary mode?

Yes and yes.

Note that atm we also don't have a way for userspace to say that it
wants to signal limited range to the sink but wants the kernel
to not do the full->limited range conversion. Ie. no way for userspace
to pass in pixels that are already in limited range. There was a patch
for that posted quite long ago, but it didn't go in.

> 
> Can CVT or GVT produce those exact timings? Can that accidentally
> result in limited range?

Not sure.

-- 
Ville Syrjälä
Intel