Re: [PATCH v4 03/11] drm/fourcc: Add DRM_FORMAT_Y8

[Tomi Valkeinen]

Hi,

On 27/03/2025 11:20, Pekka Paalanen wrote:
> On Wed, 26 Mar 2025 15:55:18 +0200
> Tomi Valkeinen <tomi.valkeinen@xxxxxxxxxxxxxxxx> wrote:
>
> > Hi,
> >
> > On 26/03/2025 15:52, Geert Uytterhoeven wrote:
> > > Hi Tomi,
> > >
> > > On Wed, 26 Mar 2025 at 14:23, Tomi Valkeinen
> > > <tomi.valkeinen@xxxxxxxxxxxxxxxx> wrote:
> > > > Add greyscale Y8 format.
> > > >
> > > > Acked-by: Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxx>
> > > > Signed-off-by: Tomi Valkeinen <tomi.valkeinen@xxxxxxxxxxxxxxxx>
> > >
> > > Thanks for your patch!
> > >    
> > > > --- a/include/uapi/drm/drm_fourcc.h
> > > > +++ b/include/uapi/drm/drm_fourcc.h
> > > > @@ -405,6 +405,9 @@ extern "C" {
> > > >    #define DRM_FORMAT_YUV444      fourcc_code('Y', 'U', '2', '4') /* non-subsampled Cb (1) and Cr (2) planes */
> > > >    #define DRM_FORMAT_YVU444      fourcc_code('Y', 'V', '2', '4') /* non-subsampled Cr (1) and Cb (2) planes */
> > > >
> > > > +/* Greyscale formats */
> > > > +
> > > > +#define DRM_FORMAT_Y8          fourcc_code('G', 'R', 'E', 'Y')  /* 8-bit Y-only */
> > >
> > > This format differs from e.g. DRM_FORMAT_R8, which encodes
> > > the number of bits in the FOURCC format. What do you envision
> > > for e.g. DRM_FORMAT_Y16? fourcc_code('G', 'R', '1', '6')?
> >
> > I wanted to use the same fourcc as on V4L2 side. Strictly speaking it's
> > not required, but different fourccs for the same formats do confuse.
> >
> > So, generally speaking, I'd pick an existing fourcc from v4l2 side if
> > possible, and if not, invent a new one.
>
> Hi Tomi,
>
> what's the actual difference between DRM_FORMAT_R8 and DRM_FORMAT_Y8?
>
> Is the difference that when R8 gets expanded to RGB, it becomes (R, 0,
> 0), but Y8 gets expanded to (c1 * Y, c2 * Y, c3 * Y) where c1..c3 are
> defined by MatrixCoefficients (H.273 terminology)?
>
> That would be my intuitive assumption following how YCbCr is handled.
> Is it obvious enough, or should there be a comment to that effect?

You raise an interesting point. Is it defined how a display driver, that 
supports R8 as a format, shows R8 on screen? I came into this in the 
context of grayscale formats, so I thought R8 would be handled as (R, R, 
R) in RGB. But you say (R, 0, 0), which... also makes sense.

I think that's a new argument in favor of Y8: Y8 means Y-only, so the 
meaning is more explicit.

How I see that the display controller would deal with Y8 (depending on 
the HW):

- Take the Y value as a greyscale value, if the HW supports greyscale 
format directly.
- Use the Y as YCbCr (Y, Cb-neutral, Cr-neutral), and use that if the HW 
supports YCbCr directly.
- Use the Y as YCbCr as above, and convert to RGB in the usual way.

And as it's an YUV format, the limited/full range applies, which I 
believe is not usually applied to RGB formats.

Does this make sense?

 Tomi