linux-kernel - Re: [PATCH v2 4/7] drm/connector: hdmi: Use YUV420 output format as an RGB fallback

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250314-airborne-magenta-corgi-afd52c@houat>
Date: Fri, 14 Mar 2025 14:47:53 +0100
From: Maxime Ripard <mripard@...nel.org>
To: Dmitry Baryshkov <lumag@...nel.org>
Cc: Cristian Ciocaltea <cristian.ciocaltea@...labora.com>, 
	Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, Thomas Zimmermann <tzimmermann@...e.de>, 
	David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>, 
	Dave Stevenson <dave.stevenson@...pberrypi.com>, Dmitry Baryshkov <dmitry.baryshkov@...aro.org>, 
	kernel@...labora.com, dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 4/7] drm/connector: hdmi: Use YUV420 output format as
 an RGB fallback

On Tue, Mar 11, 2025 at 09:46:39PM +0200, Dmitry Baryshkov wrote:
> On Tue, Mar 11, 2025 at 04:55:17PM +0100, Maxime Ripard wrote:
> > Hi,
> > 
> > I think the first thing we need to address is that we will need to
> > differentiate between HDMI 1.4 devices and HDMI 2.0.
> > 
> > It applies to YUV420, which is HDMI 2.0-only, and I guess your patches
> > are good enough if you consider YUV420 support only, but scrambler setup
> > for example is a thing we want to support in that infrastructure
> > eventually, and is conditioned on HDMI 2.0 as well.
> > 
> > On Tue, Mar 11, 2025 at 12:57:36PM +0200, Cristian Ciocaltea wrote:
> > > Try to make use of YUV420 when computing the best output format and
> > > RGB cannot be supported for any of the available color depths.
> > > 
> > > Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@...labora.com>
> > > ---
> > >  drivers/gpu/drm/display/drm_hdmi_state_helper.c | 69 +++++++++++++------------
> > >  1 file changed, 35 insertions(+), 34 deletions(-)
> > > 
> 
> [...]
> 
> > >  	return -EINVAL;
> > >  }
> > >  
> > > +static int
> > > +hdmi_compute_config(const struct drm_connector *connector,
> > > +		    struct drm_connector_state *conn_state,
> > > +		    const struct drm_display_mode *mode)
> > > +{
> > > +	unsigned int max_bpc = clamp_t(unsigned int,
> > > +				       conn_state->max_bpc,
> > > +				       8, connector->max_bpc);
> > > +	int ret;
> > > +
> > > +	ret = hdmi_try_format(connector, conn_state, mode, max_bpc,
> > > +			      HDMI_COLORSPACE_RGB);
> > > +	if (!ret)
> > > +		return 0;
> > > +
> > > +	if (connector->ycbcr_420_allowed)
> > > +		ret = hdmi_try_format(connector, conn_state, mode, max_bpc,
> > > +				      HDMI_COLORSPACE_YUV420);
> > 
> > I think that's conditioned on a few more things:
> >   - That the driver supports HDMI 2.0
> 
> Isn't that included into connector->ycbcr_420_allowed? I'd expect that
> HDMI 1.4-only drivers don't set that flag.

Yeah, I guess that's one way to do it, but we don't have any way to
express it at the moment

Maxime

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