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 6D742E9B376 for ; Mon, 2 Mar 2026 12:54:34 +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=lPQKUxtVjexxEX4A7XuYCfJhBt0aFJEhGTj3wOuGAak=; b=E+wx3e8kvJQ3bdan+jQf7l42E3 cOyt7ZfDS+/rjaK6UFPM2xHIE55LSIfsEk72KMHVfZA7mbUNZI9a2NvtR4hxKmcF20nAKl1u4047i NQQqACMeqklgFIOr5DJyV6mrxXaOWYuO4aP/qBH0/JPSf/+QnDFNFteGFd313CZdWf7TJ59IsPByv fyGWPmLy3pNh7iexOumtUx5iiYApM9Ona+8nSGogAlKnZm3EeeYMHUptcwkc/R1imjUW31PkamOkH jWFtbHePMhVg9gQxJTovU1bAyarDjuItpG8Ue5YAAO9+1YX3hmXmF5a7fXjbR+uRIlGxgs8qb6ll1 fwKomCMg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1vx2n5-0000000D2an-44VO; Mon, 02 Mar 2026 12:54:28 +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 1vx2n3-0000000D2aF-3m12; Mon, 02 Mar 2026 12:54:26 +0000 ARC-Seal: i=1; a=rsa-sha256; t=1772456025; cv=none; d=zohomail.com; s=zohoarc; b=GMp6+xRMNwgsTM8iGKy0G8y6GkFeXPgakJzLr4g7v95spFf1QZd6gihYWQLeJL3rhTD72V5ksZSGquVESfiNqgKeGzY50/q6h8v1bi60drZGMwODJVl5oWq2gscFuxM8XEzd0q5iQhjpvN7xPzvuZds5ioTLzjp+OL7gf+moM5U= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1772456025; 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=lPQKUxtVjexxEX4A7XuYCfJhBt0aFJEhGTj3wOuGAak=; b=A8n4m9TSHOWSTtoNn2W97tLnoFen+A2T+MHjlMc1Fy2Osrzwbvz5wXokklGhxewaXenze4bkNrKTYl8owJrBUJ5XF9C1NhbLaSeq6TvYARrjCjqRSAlPfwuHpfzYaBKPOAlJuENarffaJUdtReMw0Vc+oQzIvMJ9+Pn+0UGA/IA= 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=1772456025; 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=lPQKUxtVjexxEX4A7XuYCfJhBt0aFJEhGTj3wOuGAak=; b=czCH1PwnW/CNSDoAUO7w4zjpsIwnu75I4YmbkTsbzGgEvfX7ryNg9YU9rmvgEoUo y3p5/qdnQXH9dJ1dsu7mEMvGlvt+UzU3mJRc0wVN7PDPDV0PuEoHXkeE5lIglxjq8Ht E9oAQ8KmXt0DU/LN72eVoyq0jW1mxhcUOCti0jF4= Received: by mx.zohomail.com with SMTPS id 1772456023924351.0985024371805; Mon, 2 Mar 2026 04:53:43 -0800 (PST) From: Nicolas Frattaroli To: Maxime Ripard Cc: 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 Subject: Re: [PATCH v9 04/19] drm/display: hdmi-state-helper: Act on color format DRM property Date: Mon, 02 Mar 2026 13:53:34 +0100 Message-ID: <8648916.T7Z3S40VBb@workhorse> In-Reply-To: <20260302-literate-shrew-of-health-ec19d2@houat> References: <20260227-color-format-v9-0-658c3b9db7ef@collabora.com> <20260227-color-format-v9-4-658c3b9db7ef@collabora.com> <20260302-literate-shrew-of-health-ec19d2@houat> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20260302_045426_009904_B32C4F13 X-CRM114-Status: GOOD ( 28.99 ) 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 Monday, 2 March 2026 09:46:06 Central European Standard Time Maxime Ripard wrote: > Hi, > > On Fri, Feb 27, 2026 at 08:20:09PM +0100, Nicolas Frattaroli wrote: > > With the introduction of the "color format" DRM property, which allows > > userspace to request a specific color format, the HDMI state helper > > should implement this. > > > > Implement it by translating the requested drm_connector_color_format to > > a drm_output_color_format enum value as per the logic HDMI should use > > for this: Auto is translated to RGB, and a fallback to YUV420 is only > > performed if the original color format was auto. > > > > Signed-off-by: Nicolas Frattaroli > > --- > > drivers/gpu/drm/display/drm_hdmi_state_helper.c | 28 +++++++++++++++++++++++-- > > 1 file changed, 26 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/display/drm_hdmi_state_helper.c b/drivers/gpu/drm/display/drm_hdmi_state_helper.c > > index 9f3b696aceeb..31c6d55fa995 100644 > > --- a/drivers/gpu/drm/display/drm_hdmi_state_helper.c > > +++ b/drivers/gpu/drm/display/drm_hdmi_state_helper.c > > @@ -669,10 +669,34 @@ hdmi_compute_config(const struct drm_connector *connector, > > unsigned int max_bpc = clamp_t(unsigned int, > > conn_state->max_bpc, > > 8, connector->max_bpc); > > + enum drm_output_color_format fmt; > > int ret; > > > > - ret = hdmi_compute_format_bpc(connector, conn_state, mode, max_bpc, > > - DRM_OUTPUT_COLOR_FORMAT_RGB444); > > + switch (conn_state->color_format) { > > + case DRM_CONNECTOR_COLOR_FORMAT_AUTO: > > + case DRM_CONNECTOR_COLOR_FORMAT_RGB444: > > + fmt = DRM_OUTPUT_COLOR_FORMAT_RGB444; > > + break; > > + case DRM_CONNECTOR_COLOR_FORMAT_YCBCR444: > > + fmt = DRM_OUTPUT_COLOR_FORMAT_YCBCR444; > > + break; > > + case DRM_CONNECTOR_COLOR_FORMAT_YCBCR422: > > + fmt = DRM_OUTPUT_COLOR_FORMAT_YCBCR422; > > + break; > > + case DRM_CONNECTOR_COLOR_FORMAT_YCBCR420: > > + fmt = DRM_OUTPUT_COLOR_FORMAT_YCBCR420; > > + break; > > + default: > > + drm_dbg_kms(connector->dev, "HDMI does not support color format '%d'.\n", > > + conn_state->color_format); > > + return -EINVAL; > > + } > > + > > + ret = hdmi_compute_format_bpc(connector, conn_state, mode, max_bpc, fmt); > > + > > + if (conn_state->color_format != DRM_CONNECTOR_COLOR_FORMAT_AUTO) > > + return ret; > > + > > We discussed it before, and it wasn't as trivial as it should have been, > but now, I really feel something like the following would be simpler: > > if (conn_state->color_format != DRM_CONNECTOR_COLOR_FORMAT_AUTO) { > enum drm_output_color_format fmt; > > switch (conn_state->color_format) { > case DRM_CONNECTOR_COLOR_FORMAT_AUTO: > drm_warn(connector->dev, "The format shouldn't be auto here"); // or any better message > fallthrough; Why shouldn't it be auto there? This is the function where the auto->rgb mapping is explicitly handled. > case DRM_CONNECTOR_COLOR_FORMAT_RGB444: > fmt = DRM_OUTPUT_COLOR_FORMAT_RGB444; > break; > .... > } > > return hdmi_compute_format_bpc(connector, conn_state, mode, max_bpc, fmt); > } > > ret = hdmi_compute_format_bpc(connector, conn_state, mode, max_bpc, > DRM_OUTPUT_COLOR_FORMAT_RGB444); > > It makes it much clearer what the two branches are, and we don't have to > test for auto multiple times. Testing for auto multiple times is done for the "4:2:0 fallback on AUTO only" case. If you fall through from AUTO to RGB and then return the result of hdmi_compute_format_bpc on RGB, then you will not let AUTO fall back to 4:2:0. hdmi_compute_format_bpc only does a fallback for lower bit depths, not different color formats. As far as I can tell, you're requesting a change of behaviour here that would require me to adjust the behaviour of every single other HDMI implementation and modify all the tests that you already gave a reviewed-by, so I assume this wasn't the intent? Kind regards, Nicolas Frattaroli > > Maxime >