[PATCH v2 7/7] drm: rcar-du: Add new formats (2-10-10-10 ARGB, Y210)

[Laurent Pinchart]

Hi Sakari,

On Tue, Dec 20, 2022 at 11:36:35AM +0200, Sakari Ailus wrote:
> On Mon, Dec 19, 2022 at 11:47:04PM +0200, Laurent Pinchart wrote:
> > On Mon, Dec 19, 2022 at 04:01:39PM +0200, Tomi Valkeinen wrote:
> > > Add new pixel formats: RGBX1010102, RGBA1010102, ARGB2101010 and Y210.
> > > 
> > > Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas at ideasonboard.com>
> > > ---
> > >  drivers/gpu/drm/rcar-du/rcar_du_kms.c | 24 +++++++++++++
> > >  drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 49 +++++++++++++++++++++++++--
> > >  2 files changed, 71 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > > index 8c2719efda2a..8ccabf5a30c4 100644
> > > --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > > +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > > @@ -259,6 +259,24 @@ static const struct rcar_du_format_info rcar_du_format_infos[] = {
> > >  		.bpp = 32,
> > >  		.planes = 1,
> > >  		.hsub = 1,
> > > +	}, {
> > > +		.fourcc = DRM_FORMAT_RGBX1010102,
> > 
> > Ah, here the format makes sense.
> > 
> > > +		.v4l2 = V4L2_PIX_FMT_XBGR2101010,
> > 
> > But this is horrible :-( Could we use the same names as DRM for new
> > formats, when there is no conflict with existing V4L2 formats ?
> > 
> > Sakari, Hans, what do you think ? Please see patch 1/7 in the series for
> > the format definitions.
> 
> I think it'd be good to have only one set of definitions.
> 
> Can we can sort the endianness question in a reasonable way?

It's really a matter of macro names only in this case, so it's "just" up
to us to decide what we want to do. Hans' argument is that we would then
depart from the general V4L2 rule, and thus create confusion, but I
don't think there's such a clear cut rule in the first place and
confusion is there already. Having common definitions for new formats
would, I think, reduce confusion.

> Also new Bayer formats will probably be still needed on V4L2 side but will
> they be relevant for DRM? I suppose that would mean new DRM format for
> each pixel order, too? Or can we think of something smarter that would
> still work reasonably with existing formats?

We use DRM 4CCs in the libcamera public API, and the DRM maintainers
have agreed to add DRM 4CCs for formats that are used by cameras only,
such as MJPEG for instance, that's hardly useful for displays. The same
holds true for Bayer formats, and we use DRM modifiers to specify the
packing instead of defining different 4CCs. I'd like to do something
similar for the Bayer pattern, although specifying it out-of-band may be
even better.

-- 
Regards,

Laurent Pinchart