From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sender4-pp-f112.zoho.com (sender4-pp-f112.zoho.com [136.143.188.112]) (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 960B1346FB5; Tue, 31 Mar 2026 10:34:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=136.143.188.112 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774953260; cv=pass; b=kYv/cdwzdhjYaY5wtch7bx+BJG8LwZx8kz7D6JwqCbRX/+BNVrxNmJlQS26hsNes6UAgw7ZP96N/rWmc1LOTgXeyR4hk1WZZ/zEhcxtSFleNK4h4NVTqcuIc3dwLsRJrzME0HM8+CGqnIK5RjVsyJkr8qBSYAYpHD1c3tB0Tj2k= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774953260; c=relaxed/simple; bh=mCV2SZpUK6sWJdM3cUU8IOdk/5G5tTsUpxdUhak3lrg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=uol2E4dgnriWuZkLAzH/YRePa/kVg/kx2JSqvxQONkUUFEnA5NO7DkwOnYrXYTzAzel37Z6c3z1gHw2JK9HTJipjQ6B4aXrlh1MHlCljEGBUJub0pzGQyajvJzt2+mCanbzQsR01XjYY3elPzjkmx7ke6gtCP8/4WnFDtokqk6s= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com; spf=pass smtp.mailfrom=collabora.com; dkim=pass (1024-bit key) header.d=collabora.com header.i=nicolas.frattaroli@collabora.com header.b=V3L9lwL5; arc=pass smtp.client-ip=136.143.188.112 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=collabora.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=collabora.com header.i=nicolas.frattaroli@collabora.com header.b="V3L9lwL5" ARC-Seal: i=1; a=rsa-sha256; t=1774953194; cv=none; d=zohomail.com; s=zohoarc; b=iq7d+EpWYAvrctcfxZoQjNJuhB62URk7xlbwaLsDMTNXTWCyQ4LwDyZ6I27wYYHAMP4YPM0hYR/rK8AWX1jqBcjhxQf8J51b99OQ+VF9yVDhEqMQMfzMcWZJUV2pGlG6D+JYKcdc63sYSJlX24pWsFdQZX2jKMN+WnVHhppSgRQ= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1774953194; 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=WONs+triHAG3oxKIDY5u6sC91+pizMI0mnGHgeGpMWA=; b=Vh9zaiChMYD6vskfjYkgIBkCpQIQmnxaqlBcmk8+El0hVORrkZFIntq9a8X6fTa7guKBYxcQC8K42tY0FIF9ir+fsdg58kFS9D0UjA9+cfr6iNC4IkwitdRA9MKj5MscyrlksfUfeV18AJAKMPFxt2cNzDqpvvQDy/G0UyUF4yQ= 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=1774953194; 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=WONs+triHAG3oxKIDY5u6sC91+pizMI0mnGHgeGpMWA=; b=V3L9lwL5t+B5HbtOLDaYfqYdeaZCN8rQT1mGU46AB79OOrvLI8lwlaGUlxYG0lKq G6V26eWcMkIy5x3/sgiT2LdI+GDuyPfzNDQ6VB5oOYteJoe+EnPXzgWeohswEwhMpkq 0cS3rPBVWJ25PctJ4X+Zp9Z74BEt6x2M/ZP7K/Yo= Received: by mx.zohomail.com with SMTPS id 1774953193153170.1511210439279; Tue, 31 Mar 2026 03:33:13 -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: Tue, 31 Mar 2026 12:33:00 +0200 Message-ID: <5583906.GXAFRqVoOG@workhorse> In-Reply-To: References: <20260324-color-format-v11-0-605559af4fb4@collabora.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Tuesday, 31 March 2026 01:56:16 Central European Summer Time Ville Syrj= =C3=A4l=C3=A4 wrote: > On Sat, Mar 28, 2026 at 02:49:04AM +0200, Ville Syrj=C3=A4l=C3=A4 wrote: > > On Fri, Mar 27, 2026 at 01:56:06PM +0100, Nicolas Frattaroli wrote: > > > On Thursday, 26 March 2026 18:58:25 Central European Standard Time Vi= lle Syrj=C3=A4l=C3=A4 wrote: > > > > On Thu, Mar 26, 2026 at 06:02:47PM +0100, Maxime Ripard wrote: > > > > > On Wed, Mar 25, 2026 at 08:43:15PM +0200, Ville Syrj=C3=A4l=C3=A4= wrote: > > > > > > On Wed, Mar 25, 2026 at 03:56:58PM +0100, Maxime Ripard wrote: > > > > > > > On Wed, Mar 25, 2026 at 01:03:07PM +0200, Ville Syrj=C3=A4l= =C3=A4 wrote: > > > > > > > > On Wed, Mar 25, 2026 at 09:24:27AM +0100, Maxime Ripard wro= te: > > > > > > > > > On Tue, Mar 24, 2026 at 09:53:35PM +0200, Ville Syrj=C3= =A4l=C3=A4 wrote: > > > > > > > > > > On Tue, Mar 24, 2026 at 08:10:11PM +0100, Nicolas Fratt= aroli wrote: > > > > > > > > > > > On Tuesday, 24 March 2026 18:00:45 Central European S= tandard Time Ville Syrj=C3=A4l=C3=A4 wrote: > > > > > > > > > > > > On Tue, Mar 24, 2026 at 05:01:07PM +0100, Nicolas F= rattaroli wrote: > > > > > > > > > > > > > +enum drm_connector_color_format { > > > > > > > > > > > > > + /** > > > > > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_AUTO: The driver= or display protocol > > > > > > > > > > > > > + * helpers should pick a suitable color format.= All implementations of a > > > > > > > > > > > > > + * specific display protocol must behave the sa= me way with "AUTO", but > > > > > > > > > > > > > + * different display protocols do not necessari= ly have the same "AUTO" > > > > > > > > > > > > > + * semantics. > > > > > > > > > > > > > + * > > > > > > > > > > > > > + * For HDMI, "AUTO" picks RGB, but falls back t= o 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 both support > > > > > > > > > > > > > + * YCbCr 4:2:0. > > > > > > > > > > > > > + * > > > > > > > > > > > > > + * For display protocols other than HDMI, the r= ecursive bridge chain > > > > > > > > > > > > > + * format selection picks the first chain of br= idge formats that works, > > > > > > > > > > > > > + * as has already been the case before the intr= oduction of the "color > > > > > > > > > > > > > + * format" property. Non-HDMI bridges should th= erefore either sort their > > > > > > > > > > > > > + * bus output formats by preference, or agree o= n a unified auto format > > > > > > > > > > > > > + * selection logic that's implemented in a comm= on state helper (like > > > > > > > > > > > > > + * how HDMI does it). > > > > > > > > > > > > > + */ > > > > > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_AUTO =3D 0, > > > > > > > > > > > > > + > > > > > > > > > > > > > + /** > > > > > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_RGB444: RGB outp= ut format > > > > > > > > > > > > > + */ > > > > > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_RGB444, > > > > > > > > > > > > > + > > > > > > > > > > > > > + /** > > > > > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR444: YCbCr = 4:4:4 output format (ie. > > > > > > > > > > > > > + * not subsampled) > > > > > > > > > > > > > + */ > > > > > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR444, > > > > > > > > > > > > > + > > > > > > > > > > > > > + /** > > > > > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR422: YCbCr = 4:2:2 output format (ie. > > > > > > > > > > > > > + * with horizontal subsampling) > > > > > > > > > > > > > + */ > > > > > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR422, > > > > > > > > > > > > > + > > > > > > > > > > > > > + /** > > > > > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR420: YCbCr = 4:2:0 output format (ie. > > > > > > > > > > > > > + * with horizontal and vertical subsampling) > > > > > > > > > > > > > + */ > > > > > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR420, > > > > > > > > > > > >=20 > > > > > > > > > > > > Seems like this should document what the quantizati= on 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. This > > > > > > > > > > > enum is more abstract than that, and is there to comm= unicate > > > > > > > > > > > YUV vs. RGB and chroma subsampling, with bit depth be= ing handled > > > > > > > > > > > by other properties. > > > > > > > > > > >=20 > > > > > > > > > > > If you mean the factor used for subsampling, then tha= t'd only be > > > > > > > > > > > relevant if YCBCR410 was supported where one chroma p= lane isn't > > > > > > > > > > > halved but quartered in resolution. I suspect 4:1:0 w= ill never > > > > > > > > > > > be added; no digital display protocol standard suppor= ts 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 rang= e, > > > > > > > > > > RGB can either be full or limited range depending on th= e=20 > > > > > > > > > > "Broadcast RGB" property and other related factors. > > > > > > > > >=20 > > > > > > > > > So far the HDMI state has both the format and quantizatio= n range as > > > > > > > > > different fields. I'm not sure we need to document the ra= nge in the > > > > > > > > > format field, maybe only mention it's not part of the for= mat but has a > > > > > > > > > field of its own? > > > > > > > >=20 > > > > > > > > I think we only have it for RGB (on some drivers only?). Fo= r YCbCr > > > > > > > > I think the assumption is limited range everywhere. > > > > > > > >=20 > > > > > > > > But I'm not really concerned about documenting struct membe= rs. > > > > > > > > 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 > > > > > > > Ack > > > > > > >=20 > > > > > > > > So I'm thinking (or perhaps hoping) the rule might be somet= hing like: > > > > > > > > - YCbCr limited range=20 > > > > > > > > - RGB full range if "Broadcast RGB" property is not present > > > > > > >=20 > > > > > > > Isn't it much more complicated than that for HDMI though? My > > > > > > > recollection was that any VIC but VIC1 would be limited range= , and > > > > > > > anything else full range? > > > > > >=20 > > > > > > Do we have some driver that implements the CTA-861 CE vs. IT mo= de > > > > > > logic but doesn't expose the "Broadcast RGB" property? I was ho= ping > > > > > > those would always go hand in hand now. > > > > >=20 > > > > > I'm not sure. i915 and the HDMI state helpers handle it properly = (I > > > > > think?) but it looks like only vc4 registers the Broadcast RGB pr= operty > > > > > and uses the HDMI state helpers. > > > > >=20 > > > > > And it looks like amdgpu registers Broadcast RGB but doesn't use > > > > > drm_default_rgb_quant_range() which seems suspicious? > > > >=20 > > > > If they want just manual full vs. limited then they should > > > > limit the property to not expose the "auto" option at all. > > > >=20 > > > > amdgpu also ties this in with the "colorspace" property, which > > > > originally in i915 only controlled the infoframes/etc. But on > > > > amdgpu it now controls various aspects of output color > > > > transformation. The end result is that the property is a complete > > > > mess with most of the values making no sense. And for whatever > > > > reason everyone involved refused to remove/deprecate the > > > > nonsensical values :/ > > > >=20 > > > > Looks like this series should make sure the documentation for > > > > the "colorspace" property is in sync with the new property > > > > as well. Currently now it's giving conflicting information. > > > >=20 > > >=20 > > > I take it the problematic information is in > > >=20 > > > * DOC: standard connector properties > > > * > > > * Colorspace: > > >=20 > > > and probably specifically BT2020_YCC's (and BT2020_RGB's?) insistence > > > that they "produce RGB content". > > >=20 > > > I think we probably just have to change the statement "The variants > > > BT2020_RGB and BT2020_YCC are equivalent and the driver chooses betwe= en > > > RGB and YCbCr on its own." > > >=20 > > > The "on its own" here would get turned into "based on the color format > > > property". > > >=20 > > > Speaking of i915, that patch is one of the very few (5) patches in > > > this series still lacking a review (hint hint nudge nudge). I'd like > > > to get some more feedback on the remaining patches before I send out > > > another revision, so that it's hopefully not just docs changes (I > > > know better than to think those patches must be perfect and won't > > > need revision.) > >=20 > > The i915 code around this is already a big mess, and I don't really > > adding to that mess. So I think we'll need to do some refactoring before > > we add anything there. I already started typing something and so far > > it looks fairly straightforward, so I should have something soon. >=20 > OK, posted something > https://lore.kernel.org/intel-gfx/20260330235339.29479-1-ville.syrjala@li= nux.intel.com/T/#m7c349478ca6c856fbc68d5e2178f1aa31678a05f Thanks! I'll take a look at this today to get a more solid idea of where the pain points you highlighted are. I'll also rebase/reimplement my i915 color format implementation (sans the DP-MST part, as discussed) on top of this on the next revision. I was never fully happy with the current one due to the logic being shoehorned into the already existing i915 fallback format logic, so I'm quite happy to have another opportunity to implement it with less historic baggage. > Are the wayland/compositor/color management folks on board with > these new properties? I don't think I see the usual suspects on > the cc list. I don't know which precise group of people you refer to, but at least from the Collabora side of things, the userspace Wayland people are on board with these new properties. In Weston, we use it to implement the Weston frontend's "color-format" option in a WIP branch at https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1859 I've also been made aware that LibreELEC is aware, and will look into making use of it rather than their own kernel patches. Kind regards, Nicolas Frattaroli > >=20 > > While doing that several questions came to my mind though: > >=20 > > * More interactions with the colorspace property, but I sent > > a separate mail already about that > >=20 > > * Which conversion matrix to use, and the answer I suspect > > should be "ask the colorspace property", as mentioned in the > > other mail > >=20 > > * Should we flat out reject color formats (and I suppose also > > colorspace prop values) the sink doesn't claim to support? > >=20 > > If yes, then I think we'll have to forget about adding anything=20 > > to i915 MST code. The way the MST stuff works is that if one > > stream needs a modeset then all the related streams get modeset > > as well. Thus if the user replaces a monitor getting fed with a > > YCbCr stream just as another stream is being modeset, then the > > entire atomic commit could fail due to the YCbCr stream getting > > rejected. > >=20 > > I think eventually we might have to invent some mechanism where > > all the input into the modeset computation is cached somehow, > > and said cache updated only on explicit userspace modesets. > > Either that or we have to come up with a way to skip some of > > the calculations that depend on external factors. Either way > > it's going to be a pain. > >=20 > > OTOH if we don't mind feeding the sink with stuff it can't > > understand, then I suppose we might add YCbCr 4:4:4 support > > for MST. It shouldn't be any different from RGB apart from > > the RGB->YCbCr conversion, which is handled elsewhere. But > > YCbCr 4:2:0 is definitely out either way, the MST code has > > no support for that currently. > >=20 >=20 >=20