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 5F87B3B3C08; Mon, 2 Mar 2026 12:54:36 +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=1772456077; cv=pass; b=NJW0CD7HXA9r51AbKBJpLLns+5yELURFvkSQA84nnxyuSbOGuA7C0513J6Jmus2MnAc8MPXuBAOf/wASI6la8NA/KFnkDS+nLto1yn9rNqu+Cic5jSN7UXRZmmrj7qctjrTJJkJOKdjog1Y5kmul3t4nBRpgou6HaQpMaiWD3+Y= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772456077; c=relaxed/simple; bh=g4AFlY96iT5YpD5k2j20smDNy4coPan7tsQ6Tmq5UK8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=CgWRAHSi5hC/Oak3ftbzXP7skzv+cMY/gm+AQmy5mkBXwiJvwU8OoAVMdlcQo5p2qdQGaUgNxu5sfX+e3ffWtBFpN+N0Qzk2uZLkt/TsMPG1njTfYsb/l5XoXVHavb39t82sLTkcqrV6TcQ2wEQUMHX74WwofUFWsH8y+j5xYx0= 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=czCH1Pwn; 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="czCH1Pwn" 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> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" 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 >