From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Cc: Vishal Sagar <vishal.sagar@amd.com>,
Anatoliy Klymenko <anatoliy.klymenko@amd.com>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <mripard@kernel.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
Michal Simek <michal.simek@amd.com>,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
Geert Uytterhoeven <geert@linux-m68k.org>,
Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>,
Pekka Paalanen <ppaalanen@gmail.com>,
Pekka Paalanen <pekka.paalanen@collabora.com>,
Dmitry Baryshkov <lumag@kernel.org>
Subject: Re: [PATCH v7 03/11] drm/fourcc: Add DRM_FORMAT_Y8
Date: Wed, 28 Jan 2026 15:09:48 +0200 [thread overview]
Message-ID: <20260128130948.GA3210848@killaraus> (raw)
In-Reply-To: <6bf4347b-ce70-4325-965f-40f81b24a0d1@ideasonboard.com>
On Wed, Jan 28, 2026 at 02:31:57PM +0200, Tomi Valkeinen wrote:
> On 28/01/2026 13:49, Laurent Pinchart wrote:
> > On Mon, Dec 01, 2025 at 02:18:45PM +0200, Tomi Valkeinen wrote:
> >> Add greyscale Y8 format.
> >
> > I would explain here why we need a new format and can't just use
> > DRM_FORMAT_R8. You don't need to convince me, but I think it's important
> > to summarize the rationale should someone later wonder why we introduced
> > this.
>
> Good point. I can take the text from the cover letter to this commit's
> description.
>
> Would this be fine:
>
> ==
>
> Add greyscale Y8 format.
>
> The 8-bit greyscale format has been discussed before, and the
> earlier guidance was to use DRM_FORMAT_R8, as a single-channel 8-bit pixel.
>
> However, adding DRM_FORMAT_Y8 makes sense, as:
>
> 1) We can mark it as 'is_yuv' in the drm_format_info, and this can help
> the drivers handle e.g. full/limited range. Probably some hardware
> handles grayscale as a value used for all RGB components, in which case
> R8 makes sense, but when the hardware handles the Y-only pixels as YCbCr,
> where Cb and Cr are "neutral", it makes more sense to consider the
> format as an YUV format rather than RGB.
>
> 2) We can have the same fourcc as in v4l2. While not strictly necessary,
> it's a constant source of confusion when the fourccs differ.
I wouldn't consider that as a goal (see my comment below about the 4CC
value). V4L2 and DRM 4CCs differ, and applications must handle them
separately. Implying we can take shortcuts for a subset of formats will
in my opinion generate more harm than good.
> 3) It (possibly) makes more sense for the user to use Y8/GREY format
> instead of R8, as, in my experience, the documentation usually refers
> to gray(scale) format or Y-only format.
>
> 4) We have other Y-only formats, like the Y10_P32 added in the following
> patches, with "Y" in the fourcc name.
If those two were the only reasons, I'd tell you to use R8 :-) I would
drop 2-4 and only document 1, that's the real reason.
> >> Acked-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> >> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.com>
> >> Reviewed-by: Vishal Sagar <vishal.sagar@amd.com>
> >> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
> >> ---
> >> drivers/gpu/drm/drm_fourcc.c | 1 +
> >> include/uapi/drm/drm_fourcc.h | 10 ++++++++++
> >> 2 files changed, 11 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> >> index b22ef86428a1..a39b9d7a5b62 100644
> >> --- a/drivers/gpu/drm/drm_fourcc.c
> >> +++ b/drivers/gpu/drm/drm_fourcc.c
> >> @@ -275,6 +275,7 @@ const struct drm_format_info *__drm_format_info(u32 format)
> >> { .format = DRM_FORMAT_YVU422, .depth = 0, .num_planes = 3, .cpp = { 1, 1, 1 }, .hsub = 2, .vsub = 1, .is_yuv = true },
> >> { .format = DRM_FORMAT_YUV444, .depth = 0, .num_planes = 3, .cpp = { 1, 1, 1 }, .hsub = 1, .vsub = 1, .is_yuv = true },
> >> { .format = DRM_FORMAT_YVU444, .depth = 0, .num_planes = 3, .cpp = { 1, 1, 1 }, .hsub = 1, .vsub = 1, .is_yuv = true },
> >> + { .format = DRM_FORMAT_Y8, .depth = 8, .num_planes = 1, .cpp = { 1, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
> >> { .format = DRM_FORMAT_NV12, .depth = 0, .num_planes = 2, .cpp = { 1, 2, 0 }, .hsub = 2, .vsub = 2, .is_yuv = true },
> >> { .format = DRM_FORMAT_NV21, .depth = 0, .num_planes = 2, .cpp = { 1, 2, 0 }, .hsub = 2, .vsub = 2, .is_yuv = true },
> >> { .format = DRM_FORMAT_NV16, .depth = 0, .num_planes = 2, .cpp = { 1, 2, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
> >> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> >> index 6c786701238e..5cfc188c4e72 100644
> >> --- a/include/uapi/drm/drm_fourcc.h
> >> +++ b/include/uapi/drm/drm_fourcc.h
> >> @@ -459,6 +459,16 @@ 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 */
> >>
> >> +/*
> >> + * Y-only (greyscale) formats
> >> + *
> >> + * The Y-only formats are handled similarly to the YCbCr formats in the display
> >> + * pipeline, with the Cb and Cr implicitly neutral (0.0 in nominal values). This
> >> + * also means that COLOR_RANGE property applies to the Y-only formats.
> >> + *
> >
> > Extra blank line.
> >
> >> + */
> >> +
> >> +#define DRM_FORMAT_Y8 fourcc_code('G', 'R', 'E', 'Y') /* 8-bit Y-only */
> >
> > I would have gone for 'Y', '8', ' ', ' '
> >
> >>
> >> /*
> >> * Format Modifiers:
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2026-01-28 13:10 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-01 12:18 [PATCH v7 00/11] drm: Add new pixel formats for Xilinx Zynqmp Tomi Valkeinen
2025-12-01 12:18 ` [PATCH v7 01/11] drm/fourcc: Add warning for bad bpp Tomi Valkeinen
2025-12-01 12:18 ` [PATCH v7 02/11] drm/fourcc: Add DRM_FORMAT_XV15/XV20 Tomi Valkeinen
2026-01-28 12:21 ` Laurent Pinchart
2026-01-28 13:53 ` Tomi Valkeinen
2026-01-28 14:31 ` Laurent Pinchart
2025-12-01 12:18 ` [PATCH v7 03/11] drm/fourcc: Add DRM_FORMAT_Y8 Tomi Valkeinen
2026-01-28 11:49 ` Laurent Pinchart
2026-01-28 12:31 ` Tomi Valkeinen
2026-01-28 13:09 ` Laurent Pinchart [this message]
2026-01-28 15:38 ` Tomi Valkeinen
2026-01-28 16:03 ` Laurent Pinchart
2025-12-01 12:18 ` [PATCH v7 04/11] drm/fourcc: Add DRM_FORMAT_Y10_P32 Tomi Valkeinen
2026-01-28 12:02 ` Laurent Pinchart
2025-12-01 12:18 ` [PATCH v7 05/11] drm/fourcc: Add DRM_FORMAT_X403 Tomi Valkeinen
2026-01-28 12:03 ` Laurent Pinchart
2025-12-01 12:18 ` [PATCH v7 06/11] drm/fourcc: Add DRM_FORMAT_XVUY2101010 Tomi Valkeinen
2025-12-01 12:18 ` [PATCH v7 07/11] drm: xlnx: zynqmp: Use drm helpers when calculating buffer sizes Tomi Valkeinen
2025-12-01 12:18 ` [PATCH v7 08/11] drm: xlnx: zynqmp: Add support for XV15 & XV20 Tomi Valkeinen
2025-12-01 12:18 ` [PATCH v7 09/11] drm: xlnx: zynqmp: Add support for Y8 and Y10_P32 Tomi Valkeinen
2026-01-28 12:10 ` Laurent Pinchart
2026-01-28 15:28 ` Tomi Valkeinen
2025-12-01 12:18 ` [PATCH v7 10/11] drm: xlnx: zynqmp: Add support for X403 Tomi Valkeinen
2025-12-01 12:18 ` [PATCH v7 11/11] drm: xlnx: zynqmp: Add support for XVUY2101010 Tomi Valkeinen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260128130948.GA3210848@killaraus \
--to=laurent.pinchart@ideasonboard.com \
--cc=airlied@gmail.com \
--cc=anatoliy.klymenko@amd.com \
--cc=dmitry.baryshkov@oss.qualcomm.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=geert@linux-m68k.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lumag@kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=michal.simek@amd.com \
--cc=mripard@kernel.org \
--cc=pekka.paalanen@collabora.com \
--cc=ppaalanen@gmail.com \
--cc=simona@ffwll.ch \
--cc=tomi.valkeinen@ideasonboard.com \
--cc=tzimmermann@suse.de \
--cc=vishal.sagar@amd.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.