[PATCH] drm: document userspace expectations around the Colorspace connector property
Pekka Paalanen
pekka.paalanen at haloniitty.fi
Mon Feb 12 09:10:15 UTC 2024
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.
-------------- 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/20240212/263fc1e2/attachment.sig>
More information about the dri-devel
mailing list