From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from whm50.louhi.net (whm50.louhi.net [77.240.19.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 42F4A41AAC for ; Mon, 31 Mar 2025 07:55:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=77.240.19.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1743407716; cv=none; b=iawXpj/1hXufV/k1Iny6NOClSEi3byPBEvW7cEfXHm9k01vLTmcTQAhi6GIhtdeNSRLlpXhkg9JmWi5TPh6bR6MdI7ExCXaQ3ui8/gy7hdq7sXBwmEbAJTyJankICWdwOon7rU/G0aHZ8amuVJJPULOUYRx7HvMoXook/+QXbn0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1743407716; c=relaxed/simple; bh=hNnHvg/wEfDA8E3MTGoSHM5qE6jH67fIgWI8rSNxFUg=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Zkr/0dNBeYSgRku/kMhQpkPcLLaZs+bxuQ67+CLzhoAUFLq8clx27Pz8x53tFMd+rowBvmOsGtHhxlZY0X0x0YoS0K9+d5SgyXfbooHqyt1p5KZwq8YrGOyfqt5zcoy9t+4ucczidsHY/UjLL4ZMXbqDWGAak5yugAfbAIOECbc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=haloniitty.fi; spf=pass smtp.mailfrom=haloniitty.fi; dkim=pass (2048-bit key) header.d=haloniitty.fi header.i=@haloniitty.fi header.b=bwCC02T9; arc=none smtp.client-ip=77.240.19.51 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=haloniitty.fi Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=haloniitty.fi Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=haloniitty.fi header.i=@haloniitty.fi header.b="bwCC02T9" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=haloniitty.fi; s=default; h=Content-Type:MIME-Version:References: In-Reply-To:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=sb9hcwin4tLRp3oqgDcx/MjqTaRYlwB2vSQozhYeOj4=; b=bwCC02T90+w20Rigll6t4LOJse ncSrDoAbrpcYMOJlaUZabIrii55xXfB/50d2baNQ0o2q/k2uGQld46Amu876rqHxFKceZCSC3rfGl cimnpaAsO8McDHHL2DCw/QZ4E8Y5M5/Z0xljp0HmVmY7E8qhG9t0wLrejPZ+y+U7uJfNJHxW+px+B uUHpKajSPts78R9zJjsUUcs7hVK6X8/nD0BNDlLjOIHNsvFWeEwY7+k4j2dR1WnqQn5STbOqwc0h5 azEndrsep7ppw77ho/HbGrYMQGv8GAi4RrzoU7xT7gdAO/6D7L6YWn9jWFWt/TCra0sp0Cgy+OEOH iA5QCBlQ==; Received: from [194.136.85.206] (port=34794 helo=eldfell) by whm50.louhi.net with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.1) (envelope-from ) id 1tz9z0-0000000021R-2b7A; Mon, 31 Mar 2025 10:54:58 +0300 Date: Mon, 31 Mar 2025 10:54:46 +0300 From: Pekka Paalanen To: Geert Uytterhoeven Cc: Tomi Valkeinen , Vishal Sagar , Anatoliy Klymenko , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , Laurent Pinchart , Michal Simek , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Dmitry Baryshkov Subject: Re: [PATCH v4 03/11] drm/fourcc: Add DRM_FORMAT_Y8 Message-ID: <20250331105446.098f0fbe@eldfell> In-Reply-To: References: <20250326-xilinx-formats-v4-0-322a300c6d72@ideasonboard.com> <20250326-xilinx-formats-v4-3-322a300c6d72@ideasonboard.com> <20250327112009.6b4dc430@eldfell> <20250327175842.130c0386@eldfell> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/QZAnc9FdGv0CGGuBeb7Bgcd"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - whm50.louhi.net X-AntiAbuse: Original Domain - vger.kernel.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - haloniitty.fi X-Get-Message-Sender-Via: whm50.louhi.net: authenticated_id: pekka.paalanen@haloniitty.fi X-Authenticated-Sender: whm50.louhi.net: pekka.paalanen@haloniitty.fi X-Source: X-Source-Args: X-Source-Dir: --Sig_/QZAnc9FdGv0CGGuBeb7Bgcd Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Thu, 27 Mar 2025 17:35:39 +0100 Geert Uytterhoeven wrote: > Hi Pekka, >=20 > On Thu, 27 Mar 2025 at 16:59, Pekka Paalanen > wrote: > > On Thu, 27 Mar 2025 16:21:16 +0200 > > Tomi Valkeinen wrote: =20 > > > On 27/03/2025 11:20, Pekka Paalanen wrote: =20 > > > > On Wed, 26 Mar 2025 15:55:18 +0200 > > > > Tomi Valkeinen wrote: =20 > > > >> On 26/03/2025 15:52, Geert Uytterhoeven wrote: =20 > > > >>> On Wed, 26 Mar 2025 at 14:23, Tomi Valkeinen > > > >>> wrote: =20 > > > >>>> Add greyscale Y8 format. > > > >>>> > > > >>>> Acked-by: Dmitry Baryshkov > > > >>>> Signed-off-by: Tomi Valkeinen = =20 > > > >>> > > > >>> Thanks for your patch! > > > >>> =20 > > > >>>> --- 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 */ =20 > > > >>> > > > >>> 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')? =20 > > > >> > > > >> 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 confus= e. > > > >> > > > >> So, generally speaking, I'd pick an existing fourcc from v4l2 side= if > > > >> possible, and if not, invent a new one. =20 > > > > > > > > what's the actual difference between DRM_FORMAT_R8 and DRM_FORMAT_Y= 8? > > > > > > > > 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 a= re > > > > defined by MatrixCoefficients (H.273 terminology)? > > > > > > > > That would be my intuitive assumption following how YCbCr is handle= d. > > > > Is it obvious enough, or should there be a comment to that effect? = =20 > > > > > > You raise an interesting point. Is it defined how a display driver, t= hat > > > 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. =20 > > > > 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? =20 >=20 > I did some digging, and was a bit surprised that it was you who told > me to use R8 instead of Y8? > https://lore.kernel.org/all/20220202111954.6ee9a10c@eldfell Hi Geert, indeed I did. I never thought of the question of expansion to R,G,B before. Maybe that expansion is what spells R8 and Y8 apart? I do think that expansion needs to be specified, so that the KMS color pipeline computations are defined. There is a big difference between multiplying these with an arbitrary 3x3 matrix (e.g. CTM): - (R, 0, 0) - (R, R, R) - (c1 * Y, c2 * Y, c3 * Y) I forgot to consider that in the discussion of single-channel displays, because the displays obviously do not consider any other channel than the one. Using DRM_FORMAT_Y8 FB with a single-channel display might even be surprising, because the proposed Y8 definition would result in c1 * Y, and not Y. The default c1 comes from the BT.601 matrix IIRC? Therefore I think the difference between R8 and Y8 has been found. Now we just need to determine whether R8 means (R, 0, 0) or (R, R, R) to nail down the color operations as well. There are questions like what is the outcome at the video signal level when we have one KMS plane with an R8 FB and another KMS plane with an RGBA8888 FB on the same CRTC? What about Y8 or NV12 in the mix? What if the video signal is single-channel, RGB, or YCbCr? Thanks, pq --Sig_/QZAnc9FdGv0CGGuBeb7Bgcd Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEJQjwWQChkWOYOIONI1/ltBGqqqcFAmfqSkYACgkQI1/ltBGq qqc4pxAAnPZQ0QQxEZ5HZEAD/A561x3dmKYKf16AaBIpBhdwXvF672H3q7NOC3MH 4qWNrJHlv5TQ+rhcwQJfYzqnOTfOwoQdpz0siUUjtSrxwfpQ2T9KmAT1sWHSudet kmEWqPBDXwmnUui4Hi6bXgiKqYsMW6PaXwT/3GO3UI8Matmu5D0yeIqqC+p4UnH7 WCcZ4osqzkgxyRkw2r7+aZq6k0VsfYXjXTNQ1PXHCArJSx5Rwlucw96IvOvUSO/o EvA0h+UIqIiuq3Va7XfyeoTaVKZ52f8F5nkeTHYoc1X3AbOAiEIGANId3vGu8hZn 9UG0SAMxJBl2BGdJpi+auNSS1Mq5J8RT/X4Tlq0L9UOg6w3gB1SwbdnQIgolYYGu MiwdyAry2zffnH5e3/pfsiM37IZNMX2bC8XzfvpK+pVxpfTE+lU15ffEA8++LisI zdpckbn440o9I074KglAGkZaB33++gNlemoVZE0nl+YY+o0frBXeObf1OMuPnZ2m K5uwHCbQLRnQkKnL2gcbwaMtZmkohGnksoD+pT7FF6ebMd4yv/7JyXnBezyccGhv Q0xATae0gNbooT4s0VrduWFRariMVz0WUUsoIb2rYx2MHXnahtmS/zXkwbYXU2U1 1tg/KdcAxlpSiTCS+6UTRD1hai9FzgLLxz7vMUbdx2r2iEDjSPY= =dA9t -----END PGP SIGNATURE----- --Sig_/QZAnc9FdGv0CGGuBeb7Bgcd--