Re: [PATCH 00/18] drm/vc4: hdmi: Add Support for the YUV output

From: Maxime Ripard <maxime@cerno.tech>
To: "Jernej Škrabec" <jernej.skrabec@siol.net>
Cc: Tim Gover <tim.gover@raspberrypi.com>,
	Neil Armstrong <narmstrong@baylibre.com>,
	David Airlie <airlied@linux.ie>, Jonas Karlman <jonas@kwiboo.se>,
	dri-devel@lists.freedesktop.org,
	Andrzej Hajda <a.hajda@samsung.com>,
	bcm-kernel-feedback-list@broadcom.com,
	Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	Daniel Vetter <daniel.vetter@intel.com>,
	Dave Stevenson <dave.stevenson@raspberrypi.com>,
	Phil Elwell <phil@raspberrypi.com>,
	linux-rpi-kernel@lists.infradead.org
Subject: Re: [PATCH 00/18] drm/vc4: hdmi: Add Support for the YUV output
Date: Fri, 19 Mar 2021 11:13:07 +0100	[thread overview]
Message-ID: <20210319101307.lznvguod2zvpxqp4@gilmour> (raw)
In-Reply-To: <4209616.oJxVDHRhuA@kista>

[-- Attachment #1.1: Type: text/plain, Size: 1846 bytes --]

Hi Jernej,

On Thu, Mar 18, 2021 at 07:16:33PM +0100, Jernej Škrabec wrote:
> Dne sreda, 17. marec 2021 ob 16:43:34 CET je Maxime Ripard napisal(a):
> > Hi,
> > 
> > Here's an attempt at support the HDMI YUV output on the BCM2711 SoC found on
> > the RaspberryPi4.
> > 
> > I took the same approach than what dw-hdmi did already, turning a bunch of
> > functions found in that driver into helpers since they were fairly generic.
> > 
> > However, it feels a bit clunky overall and there's a few rough edges that
> > should be addressed in a generic manner:
> > 
> >   - while the format negociation makes sense for a bridge, it feels a bit
> >     over-engineered for a simple encoder where that setting could be a 
> simple
> >     switch (and possibly a property?)
> 
> Property could work, but possible values should be then limited to cross 
> section of HW and connected display capabilities.

That's a good point. I'm not sure if the userspace should expect the
list of values of an enum to change under its feet

> > - more importantly, whether we're choosing an YUV output or not is
> >   completely hidden away from the userspace even though it might
> >   have some effect on > the visual quality output (thinking about
> >   YUV420 and YUV422 here mostly).
> 
> IMO driver should select highest achievable quality. So in case of
> YUV420 and YUV422, later should be selected. This should be the case
> even if the property is implemented.

Well, it depends on the hardware capability. On RPi4 in some situations
(high bpc count), we can't output anything else than YUV422. I'd expect
to have some way for the userspace to know at least. And then, for
subsampling formats it's fairly easy to tell which is the highest
achievable quality, but it would be pretty hard for YUV444 vs RGB?

Maxime

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel