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

[Ville Syrjälä]

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.

I guess one related thing we might want to expose is the "is
quantization range selectable?" bits from the EDID (assuming we
really want the "don't parse the EDID in userspace" policy [1]). That
would be needed for userspace to be able to figure out if it can
override the VIC based quantization range in the display. Although
with a bunch of crappy displays you will want to override it anyway
because they just didn't bother with implementing the spec correctly
and instead always expect full range data.

[1] which probably would mean a huge boatload if properties or
some structure inside a blob (which is pretty much just the EDID
with a different layout then).

> we'd need to take more bits out of drm_mode_modeinfo::flags, which is
> unfortunate since there aren't that many of them left and it's not an
> extensible structure. Maybe proper mode handling is going to require
> an expanded mode structure, but today is not that day, so:
> Acked-by: Daniel Stone <daniels at collabora.com>
> 
> Cheers,
> Daniel
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrjälä
Intel