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: <g25hgb2mocl4sjny26k4nzn2hwpwhlodenqganzcqfzzg6itms@herenniualnw>
Date: Tue, 11 Mar 2025 21:46:39 +0200
From: Dmitry Baryshkov <lumag@...nel.org>
To: Maxime Ripard <mripard@...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 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.

>   - That the display is an HDMI output
>   - That the mode is allowed YUV420 by the sink EDIDs
> 
> > +	else
> > +		drm_dbg_kms(connector->dev,
> > +			    "%s output format not allowed for connector\n",
> > +			    drm_hdmi_connector_get_output_format_name(HDMI_COLORSPACE_YUV420));
> 
> And I think we should keep the catch-all failure message we had.
> 
> Maxime



-- 
With best wishes
Dmitry