linux-kernel - Re: [PATCH v4 03/11] drm/fourcc: Add DRM_FORMAT

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: <20250327175842.130c0386@eldfell>
Date: Thu, 27 Mar 2025 17:58:42 +0200
From: Pekka Paalanen <pekka.paalanen@...oniitty.fi>
To: Tomi Valkeinen <tomi.valkeinen@...asonboard.com>
Cc: Geert Uytterhoeven <geert@...ux-m68k.org>, Vishal Sagar
 <vishal.sagar@....com>, Anatoliy Klymenko <anatoliy.klymenko@....com>,
 Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, Maxime Ripard
 <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>, David Airlie
 <airlied@...il.com>, Simona Vetter <simona@...ll.ch>, Laurent Pinchart
 <laurent.pinchart@...asonboard.com>, Michal Simek <michal.simek@....com>,
 dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, Dmitry Baryshkov
 <dmitry.baryshkov@....qualcomm.com>
Subject: Re: [PATCH v4 03/11] drm/fourcc: Add DRM_FORMAT_Y8

On Thu, 27 Mar 2025 16:21:16 +0200
Tomi Valkeinen <tomi.valkeinen@...asonboard.com> wrote:

> Hi,
> 
> On 27/03/2025 11:20, Pekka Paalanen wrote:
> > On Wed, 26 Mar 2025 15:55:18 +0200
> > Tomi Valkeinen <tomi.valkeinen@...asonboard.com> 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@...asonboard.com> wrote:  
> >>>> Add greyscale Y8 format.
> >>>>
> >>>> Acked-by: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
> >>>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@...asonboard.com>  
> >>>
> >>> 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.

That is a good question too. I based my assumption on OpenGL behavior
of R8.

Single channel displays do exist I believe, but being single-channel,
expansion on the other channels is likely meaningless. Hm, but for the
KMS color pipeline, it would be meaningful, like with a CTM.
Interesting.

I don't know. Maybe Geert does?

> 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?

It makes perfect sense to me.

The KMS color pipeline is defined in terms of full-range RGB, so if any
of those KMS properties is set that might make a difference, the driver
is forced to go through RGB, regardless of the hardware signal format.


Thanks,
pq

Content of type "application/pgp-signature" skipped