From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 5623F10A62CD for ; Thu, 26 Mar 2026 13:27:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type: Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date :Subject:Cc:To:From:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=AMrMoDyMoCm1J1RqpO4nLs9/wPH8TbeR8ZH8ieMqM3M=; b=BGckRrdmKntSkbLRvPuhUv9lLo CiPM1HJKRMt5WgOFuPhsRq66dCNH5PgO9UDadtY6rREgxppeXffNIcg6Lm5E3pVgwlEdB/DSaz++v eIcUPQ1ZdGNnPFO7qtUkp+rjjSJNx7Cj1aRMKhyMUAKhfrvh+dGs9ltc4FC3xNVLlrElbLzljNYTi rfJOup0T1VyDy/Dw2PoRslaqPH6meboYoVoTELazAY8lT76+aUXi4cn8T5KD/YufbRBBlCb+5TcrJ uzKDriK70XCXEgTabkSLPtufW59FI/+JbyrLnUkg+NPiPExsccYT7gKGLU+AqgWjfasPMaR/X9JgI /zWQmO4g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1w5kkV-00000005YAQ-0zX0; Thu, 26 Mar 2026 13:27:47 +0000 Received: from sender4-pp-f112.zoho.com ([136.143.188.112]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1w5kkS-00000005Y9x-4AKz; Thu, 26 Mar 2026 13:27:46 +0000 ARC-Seal: i=1; a=rsa-sha256; t=1774531618; cv=none; d=zohomail.com; s=zohoarc; b=inF8c0T9S04BCFBJF/AFqs0QQE1fnL6+L0KLfp2qflAKOoeaNF7POilnvsA4ogT6zDYEJzs/DCseE80aWKaUz95nmU2U1FPPkxmNHr6fa9tAABj6/T0/YzxGOEfjkI2vE7iix4wdHGsYY+jGCIIpca2Is5cbPETQB2cW49W/Z1Q= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1774531618; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; bh=AMrMoDyMoCm1J1RqpO4nLs9/wPH8TbeR8ZH8ieMqM3M=; b=F/uVOgmOl/+m0cjgsZP2y8CQcCEJp7/Yg24rmTHvQeop6slol6pRNfz33yzdJwytMxRzBykwUO1UZRD6U1RSUHwIQfw2LwMYGCPCK7s0zi3sF3kvj1eLwMbFVG/l1Kolu1GsIta26G2M2I0EuRjqkDbRVtjCfe7IrS/JP9zacG8= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=collabora.com; spf=pass smtp.mailfrom=nicolas.frattaroli@collabora.com; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1774531618; s=zohomail; d=collabora.com; i=nicolas.frattaroli@collabora.com; h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-ID:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Content-Type:Message-Id:Reply-To; bh=AMrMoDyMoCm1J1RqpO4nLs9/wPH8TbeR8ZH8ieMqM3M=; b=HBcXyV1aOElHJrP/+ER67nmCR0XxtxLBZgcVosoR2oun5PXk84eq4XCERgt0txCj n1btqz4DhdJsscJVr/Z3XksBjfuJCDRFbqPwSO1mPImfxdfB188suw3+SZnrbcmpGbo LUMkv9IiZsZn/W4s/g4yu3jAGvxeNMghnaVP+9zg= Received: by mx.zohomail.com with SMTPS id 177453161763075.0968772878656; Thu, 26 Mar 2026 06:26:57 -0700 (PDT) From: Nicolas Frattaroli To: Ville =?UTF-8?B?U3lyasOkbMOk?= Cc: Maxime Ripard , Harry Wentland , Leo Li , Rodrigo Siqueira , Alex Deucher , Christian =?UTF-8?B?S8O2bmln?= , David Airlie , Simona Vetter , Maarten Lankhorst , Thomas Zimmermann , Andrzej Hajda , Neil Armstrong , Robert Foss , Laurent Pinchart , Jonas Karlman , Jernej Skrabec , Sandy Huang , Heiko =?UTF-8?B?U3TDvGJuZXI=?= , Andy Yan , Jani Nikula , Rodrigo Vivi , Joonas Lahtinen , Tvrtko Ursulin , Dmitry Baryshkov , Sascha Hauer , Rob Herring , Jonathan Corbet , Shuah Khan , kernel@collabora.com, amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org, linux-doc@vger.kernel.org, Werner Sembach , Andri Yngvason , Marius Vlad Subject: Re: [PATCH v11 03/22] drm: Add new general DRM property "color format" Date: Thu, 26 Mar 2026 14:26:47 +0100 Message-ID: <16004581.uLZWGnKmhe@workhorse> In-Reply-To: References: <20260324-color-format-v11-0-605559af4fb4@collabora.com> <3979783.tdWV9SEqCh@workhorse> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20260326_062745_085844_B54A8CD7 X-CRM114-Status: GOOD ( 52.21 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thursday, 26 March 2026 14:07:15 Central European Standard Time Ville Sy= rj=C3=A4l=C3=A4 wrote: > On Thu, Mar 26, 2026 at 01:44:03PM +0100, Nicolas Frattaroli wrote: > > On Wednesday, 25 March 2026 12:03:07 Central European Standard Time Vil= le Syrj=C3=A4l=C3=A4 wrote: > > > On Wed, Mar 25, 2026 at 09:24:27AM +0100, Maxime Ripard wrote: > > > > On Tue, Mar 24, 2026 at 09:53:35PM +0200, Ville Syrj=C3=A4l=C3=A4 w= rote: > > > > > On Tue, Mar 24, 2026 at 08:10:11PM +0100, Nicolas Frattaroli wrot= e: > > > > > > On Tuesday, 24 March 2026 18:00:45 Central European Standard Ti= me Ville Syrj=C3=A4l=C3=A4 wrote: > > > > > > > On Tue, Mar 24, 2026 at 05:01:07PM +0100, Nicolas Frattaroli = wrote: > > > > > > > > +enum drm_connector_color_format { > > > > > > > > + /** > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_AUTO: The driver or displa= y protocol > > > > > > > > + * helpers should pick a suitable color format. All imple= mentations of a > > > > > > > > + * specific display protocol must behave the same way wit= h "AUTO", but > > > > > > > > + * different display protocols do not necessarily have th= e same "AUTO" > > > > > > > > + * semantics. > > > > > > > > + * > > > > > > > > + * For HDMI, "AUTO" picks RGB, but falls back to YCbCr 4:= 2:0 if the > > > > > > > > + * bandwidth required for full-scale RGB is not available= , or the mode > > > > > > > > + * is YCbCr 4:2:0-only, as long as the mode and output bo= th support > > > > > > > > + * YCbCr 4:2:0. > > > > > > > > + * > > > > > > > > + * For display protocols other than HDMI, the recursive b= ridge chain > > > > > > > > + * format selection picks the first chain of bridge forma= ts that works, > > > > > > > > + * as has already been the case before the introduction o= f the "color > > > > > > > > + * format" property. Non-HDMI bridges should therefore ei= ther sort their > > > > > > > > + * bus output formats by preference, or agree on a unifie= d auto format > > > > > > > > + * selection logic that's implemented in a common state h= elper (like > > > > > > > > + * how HDMI does it). > > > > > > > > + */ > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_AUTO =3D 0, > > > > > > > > + > > > > > > > > + /** > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_RGB444: RGB output format > > > > > > > > + */ > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_RGB444, > > > > > > > > + > > > > > > > > + /** > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR444: YCbCr 4:4:4 outp= ut format (ie. > > > > > > > > + * not subsampled) > > > > > > > > + */ > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR444, > > > > > > > > + > > > > > > > > + /** > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR422: YCbCr 4:2:2 outp= ut format (ie. > > > > > > > > + * with horizontal subsampling) > > > > > > > > + */ > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR422, > > > > > > > > + > > > > > > > > + /** > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR420: YCbCr 4:2:0 outp= ut format (ie. > > > > > > > > + * with horizontal and vertical subsampling) > > > > > > > > + */ > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR420, > > > > > > >=20 > > > > > > > Seems like this should document what the quantization range > > > > > > > should be for each format. > > > > > > >=20 > > > > > >=20 > > > > > > I don't think so? If you want per-component bit depth values, > > > > > > DRM_FORMAT_* defines would be the appropriate values to use. Th= is > > > > > > enum is more abstract than that, and is there to communicate > > > > > > YUV vs. RGB and chroma subsampling, with bit depth being handled > > > > > > by other properties. > > > > > >=20 > > > > > > If you mean the factor used for subsampling, then that'd only be > > > > > > relevant if YCBCR410 was supported where one chroma plane isn't > > > > > > halved but quartered in resolution. I suspect 4:1:0 will never > > > > > > be added; no digital display protocol standard supports it to my > > > > > > knowledge, and hopefully none ever will. > > > > >=20 > > > > > No, I mean the quantization range (16-235 vs. 0-255 etc). > > > > >=20 > > > > > The i915 behaviour is that YCbCr is always limited range, > > > > > RGB can either be full or limited range depending on the=20 > > > > > "Broadcast RGB" property and other related factors. > > > >=20 > > > > So far the HDMI state has both the format and quantization range as > > > > different fields. I'm not sure we need to document the range in the > > > > format field, maybe only mention it's not part of the format but ha= s a > > > > field of its own? > > >=20 > > > I think we only have it for RGB (on some drivers only?). For YCbCr > > > I think the assumption is limited range everywhere. > > >=20 > > > But I'm not really concerned about documenting struct members. > > > What I'm talking about is the *uapi* docs. Surely userspace > > > will want to know what the new property actually does so the > > > uapi needs to be documented properly. And down the line some > > > new driver might also implement the wrong behaviour if there > > > is no clear specification. > > >=20 > > > So I'm thinking (or perhaps hoping) the rule might be something like: > > > - YCbCr limited range=20 > > > - RGB full range if "Broadcast RGB" property is not present > > > - RGB full or limited range based on the "Broadcast RGB" property > > > if it's present > > >=20 > > > I think the "Broadcast RGB" property itself might also be lacking > > > proper uapi docs, so that may need to be remedied as well. > > >=20 > > >=20 > >=20 > > Alright, so in v12 I'll do the following: > >=20 > > - Add a line to all YCBCR connector formats that specifies they're > > limited range as long as Broadcast RGB is limited. Whether it's limit= ed > > range when Broadcast RGB is full is purposefully left undefined. >=20 > "Broadcast RGB", as the name implies, only affects RGB output. Alright, I'll scratch the overcomplicated undefined behaviour thing and just say it's limited range, and in the future, we can extend it to limited range by default but full range if another new property is set. >=20 > > In the future, we can expand this to state they're limited range by > > default unless some other property is set. If we're not re-using > > Broadcast RGB for that, this will work out fine, because users who > > don't know about the eventual new property won't have this behaviour > > changed. If we do re-use "Broadcast RGB" for that, then only users > > relying on things we explicitly left undefined will get surprise > > full range YCBCR. > > - Add a line to the RGB connector format that specifies its range > > depends on the "Broadcast RGB" property > >=20 > > This is a bit of a mess, because it's entirely reasonable that a > > future YCBCR range property would want to default to full range > > so that users get the most color out of their monitors. But with > > this description of the connector color formats, we can't do that. > >=20 > > If there are alternate suggestions, I'm open for them. We can't > > really rename "Broadcast RGB" but if I had a time machine, that'd > > be my first choice. > >=20 > > Kind regards, > > Nicolas Frattaroli > >=20 >=20 >=20