Hi Laurent,
On Mon, Dec 19, 2022 at 11:47:04PM +0200, Laurent Pinchart wrote:
> Hi Tomi,
>
> (CC'ing Sakari and Hans)
>
> Thank you for the patch.
>
> 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+rene...@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?
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?
--
Kind regards,
Sakari Ailus
