Message-ID: <20260210-prophetic-elk-of-superiority-b0ab03@houat>
Date: Tue, 10 Feb 2026 18:24:46 +0100
From: Maxime Ripard <mripard@...nel.org>
To: Nicolas Frattaroli <nicolas.frattaroli@...labora.com>
Cc: Harry Wentland <harry.wentland@....com>, Leo Li <sunpeng.li@....com>, 
	Rodrigo Siqueira <siqueira@...lia.com>, Alex Deucher <alexander.deucher@....com>, 
	Christian König <christian.koenig@....com>, David Airlie <airlied@...il.com>, 
	Simona Vetter <simona@...ll.ch>, Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, 
	Thomas Zimmermann <tzimmermann@...e.de>, Andrzej Hajda <andrzej.hajda@...el.com>, 
	Neil Armstrong <neil.armstrong@...aro.org>, Robert Foss <rfoss@...nel.org>, 
	Laurent Pinchart <Laurent.pinchart@...asonboard.com>, Jonas Karlman <jonas@...boo.se>, 
	Jernej Skrabec <jernej.skrabec@...il.com>, Sandy Huang <hjc@...k-chips.com>, 
	Heiko Stübner <heiko@...ech.de>, Andy Yan <andy.yan@...k-chips.com>, 
	Jani Nikula <jani.nikula@...ux.intel.com>, Rodrigo Vivi <rodrigo.vivi@...el.com>, 
	Joonas Lahtinen <joonas.lahtinen@...ux.intel.com>, Tvrtko Ursulin <tursulin@...ulin.net>, 
	Dmitry Baryshkov <lumag@...nel.org>, Sascha Hauer <s.hauer@...gutronix.de>, 
	Rob Herring <robh@...nel.org>, Jonathan Corbet <corbet@....net>, kernel@...labora.com, 
	amd-gfx@...ts.freedesktop.org, dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org, 
	linux-arm-kernel@...ts.infradead.org, linux-rockchip@...ts.infradead.org, 
	intel-gfx@...ts.freedesktop.org, intel-xe@...ts.freedesktop.org, linux-doc@...r.kernel.org, 
	Marius Vlad <marius.vlad@...labora.com>
Subject: Re: [PATCH v7 03/22] drm: Add enum conversions between
 DRM_COLOR_FORMAT and HDMI_COLORSPACE

Hi,

On Sat, Feb 07, 2026 at 08:55:16PM +0100, Nicolas Frattaroli wrote:
> On Friday, 6 February 2026 15:08:46 Central European Standard Time Maxime Ripard wrote:
> > On Wed, Jan 21, 2026 at 03:45:10PM +0100, Nicolas Frattaroli wrote:
> > > While the two enums have similar values, they're not identical, and
> > > HDMI's enum is defined as per the HDMI standard.
> > > 
> > > Add a simple conversion function from DRM to HDMI. Unexpected inputs
> > > aren't handled in any clever way, DRM_COLOR_FORMAT_AUTO and any other
> > > value that doesn't cleanly map to HDMI just gets returned as
> > > HDMI_COLORSPACE_RGB.
> > > 
> > > Add a second conversion function that gets a DRM_COLOR_FORMAT from an
> > > HDMI_COLORSPACE as well. In this case, reserved HDMI values that can't
> > > be converted will result in an -EINVAL return value.
> > > 
> > > Co-developed-by: Marius Vlad <marius.vlad@...labora.com>
> > > Signed-off-by: Marius Vlad <marius.vlad@...labora.com>
> > > Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@...labora.com>
> > > ---
> > >  include/drm/drm_connector.h | 54 +++++++++++++++++++++++++++++++++++++++++++++
> > >  1 file changed, 54 insertions(+)
> > > 
> > > diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> > > index b5604dca728a..ffeb42f3b4a3 100644
> > > --- a/include/drm/drm_connector.h
> > > +++ b/include/drm/drm_connector.h
> > > @@ -2612,6 +2612,60 @@ int drm_connector_attach_color_format_property(struct drm_connector *connector);
> > >  
> > >  const char *drm_get_color_format_name(enum drm_color_format color_fmt);
> > >  
> > > +/**
> > > + * drm_color_format_to_hdmi_colorspace - convert DRM color format to HDMI
> > > + * @fmt: the &enum drm_color_format to convert
> > > + *
> > > + * Convert a given &enum drm_color_format to an equivalent
> > > + * &enum hdmi_colorspace. For non-representable values and
> > > + * %DRM_COLOR_FORMAT_AUTO, the value %HDMI_COLORSPACE_RGB is returned.
> > > + *
> > > + * Returns: the corresponding &enum hdmi_colorspace value
> > > + */
> > > +static inline enum hdmi_colorspace __pure
> > > +drm_color_format_to_hdmi_colorspace(enum drm_color_format fmt)
> > > +{
> > > +	switch (fmt) {
> > > +	default:
> > > +	case DRM_COLOR_FORMAT_AUTO:
> > > +	case DRM_COLOR_FORMAT_RGB444:
> > > +		return HDMI_COLORSPACE_RGB;
> > 
> > I don't think that's correct. What auto ends up as totally depends on
> > the atomic state it comes with.
> > 
> > At the very least, you should output a warning there, because that case
> > should never happen.
> 
> Yeah, my hope was to keep this function __pure so that the compiler
> has maximum freedom to do whatever. With a WARN, it's got side-effects
> now, and we're no longer pure. With a status return value and an output
> parameter, it's no longer pure either, because the output parameter is
> not local memory.
> 
> The limiting factor here is that as I understand correctly, I can't
> really extend the hdmi_colorspace enum, as it's basically 1:1 from
> the standard. Doing this would be the ideal solution, because we'd
> keep the function pure and without surprise conversions happening.

I feel like this kind of loops back into the other two reviews I did:
you paint yourself into a corner by having auto in the enum, and by
passing it directly to that function.

If, instead, you don't allow auto in the drm_color_format enum, and
resolve auto in the hdmi_compute_config function instead of passing it
directly, then we don't have to deal with it here.

> Looking at hdmi_colorspace_get_name in drivers/video/hdmi.c, it returns
> "Invalid" for any value not in the enum itself. Would it be allowable
> to tack an HDMI_COLORSPACE_INVALID at the end of the enum with perhaps
> a negative value, or is there a different approach you'd prefer?

And again, if we only ever have to deal with RGB, YUV420, 444 or 422,
then we always have valid values for HDMI_COLORSPACE.

Plus, the hdmi_colorspace enum matches what the hdmi spec defines, so we
can't really extend it, and most importantly, hdmi_colorspace_get_name()
is only ever used for debugging / logging purposes, it's never in the
"functional" path.

Maxime

Download attachment "signature.asc" of type "application/pgp-signature" (274 bytes)

Powered by blists - more mailing lists