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

[Pekka Paalanen]

On Fri, 9 Oct 2020 17:20:18 +0300
Ville Syrjälä <ville.syrjala at linux.intel.com> wrote:

> 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.

Thanks for the heads-up.

If userspace uses all available KMS color management properties
(CTM, LUTs, etc.) *and* the video mode implies limited range on the
cable, at what point in the pixel pipeline does that conversion from
full to limited range occur?

That is something I expect to need codify into Weston at some point so
that the complete pixel pipeline works as intended.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20201012/2265ef2d/attachment-0001.sig>