[PATCH] drm: document userspace expectations around the Colorspace connector property

Sebastian Wick sebastian.wick at redhat.com
Mon Feb 12 16:50:36 UTC 2024


On Mon, Feb 12, 2024 at 11:10:15AM +0200, Pekka Paalanen wrote:
> On Fri,  9 Feb 2024 17:53:07 +0100
> Xaver Hugl <xaver.hugl at kde.org> wrote:
> 
> > Signed-off-by: Xaver Hugl <xaver.hugl at kde.org>
> > ---
> >  drivers/gpu/drm/drm_connector.c | 8 ++++++++
> >  1 file changed, 8 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> > index b0516505f7ae..01e13984629b 100644
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -2158,6 +2158,14 @@ EXPORT_SYMBOL(drm_mode_create_aspect_ratio_property);
> >   *     one supported. Sink supported colorspaces should be retrieved by
> >   *     userspace from EDID and driver will not explicitly expose them.
> >   *
> > + *     As userspace can't currently know whether or not the output is using
> > + *     RGB or YCC signalling, the driver must translate properties to their
> > + *     relevant RGB or YCC counterparts, depending on the actually used
> > + *     signalling. Property values that are only valid for either YCC or RGB
> > + *     and have no equivalent for the other signalling type must not be
> > + *     exposed as supported, unless the driver can guarantee it never uses
> > + *     the signalling that doesn't match the property.
> > + *
> >   *     Basically the expectation from userspace is:
> >   *      - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink
> >   *        colorspace
> 
> While this addition is good, I have another question:
> 
> Does "Colorspace" property choose also the RGB->YCbCr matrix that the
> driver will use when it happens to use YCbCr signalling?
> 
> So far we have only been talking about the primaries and white point.

Uh, yeah, good point. The InfoFrames do affect both the YCbCr conversion
and the transfer characteristics that the sink expects. Drivers should
do the RGB to YCbCr conversion with the new matrix. I think (and very
much hope) that drivers don't rely on the TF for any internal processing
but if they did, they also should use the one the sink expects.



More information about the dri-devel mailing list