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 841DD4949FF for ; Tue, 9 Jun 2026 15:46:42 +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=1781020003; cv=pass; b=YfbFmZYjuxvd3Gjed7CEQ0UppOWHRL1Pogl93wwrAAAKXoz9GEm4ZNl04WQwZZbGEjlD5Le1yAdVqdc0D/8zsZugrnmUX55l59DXPRV1U+qae9MfmQxd+Se+DC9XHHPmrNPj0TqTM3aiZjxkpGA5tb9Hgbc7qFnov+ygl30UKMU= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781020003; c=relaxed/simple; bh=nT6x7r28mlbei7KeEz7fiEqIZbqRKQMYCEe9tUXJdE0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=psMZ39Qu+1rYQX2LHR0nXpmfeu9FVGDk+mhakp2K/w6uQ+jQnCxLcYk7sZF2hskIh55U5fDFFfzfKcl3BPQYAvE0wVfbzvoqDi19n62MNp0j7ZdU1gq0M1UI+zs6cqXoCQJZ0g67Ogly8e9bADcBUxGleDLoL1z/y+k1kg4IfcU= 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=Y0wWEGSd; 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="Y0wWEGSd" ARC-Seal: i=1; a=rsa-sha256; t=1781019986; cv=none; d=zohomail.com; s=zohoarc; b=TdLep4iIGLSFu6R6E+jR3886lqG+OCDS5MpX71CqM5XqrBFMH6NI971iK6Zrw2sZp4DZdjL3kSYImAEobCmzF1GGrm0KbOcsoGfUouFdsYjO0j5O6CTtkUiYT9C+2iW9QzVExPSYbJYFxEuHM26iQKH8UKj2EBqNypqNVuYsvtU= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1781019986; 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=Yq0YedSy2ltlmXQkVjO4DFCO6XZqNvukn5YvwkChBo0=; b=kLTPWdCmRv3sP4u1sMo4Xo7gXrW4tY8VPaRe7Ka/dk7nDgYMHYAGHK4BLZoRpZUuYlTZn+fIb1MUgmSf2eNFLo7N+TS/3V7MzsVaxqEpiI1Oml98WdiPZvTBVjimIjrLaPDCNcEVOxaHSfCJvaxOcpRu1TdD0j70HX0Zmz/nAE4= 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=1781019986; 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=Yq0YedSy2ltlmXQkVjO4DFCO6XZqNvukn5YvwkChBo0=; b=Y0wWEGSdYOaBPbbzztYdYHB8/7iolZvaVNz7kXmENCdgsQmoA1EdTTPZwue0bbDL ZALT8mu5mpD40W0nn87vsxx3k11co/M5zAE7AcePsVriPJae5qy4ruAplPF+HGsPD1B OuWxlL0KRD1PTXNEaHJL2ZPy14B0WXMIRqRucpkI= Received: by mx.zohomail.com with SMTPS id 1781019985329809.925765084812; Tue, 9 Jun 2026 08:46:25 -0700 (PDT) From: Nicolas Frattaroli To: Maxime Ripard Cc: Maarten Lankhorst , Thomas Zimmermann , David Airlie , Simona Vetter , Dmitry Baryshkov , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, kernel@collabora.com Subject: Re: [PATCH 0/2] Make HDMI state helpers handle odd max bpc requests Date: Tue, 09 Jun 2026 17:46:20 +0200 Message-ID: In-Reply-To: <20260609-orthodox-cocky-bull-5ddef8@houat> References: <20260608-hdmi-max-bpc-fix-v1-0-6e8dcebc7274@collabora.com> <20260609-orthodox-cocky-bull-5ddef8@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 Tuesday, 9 June 2026 14:51:12 Central European Summer Time Maxime Ripard wrote: > Hi, > > On Mon, Jun 08, 2026 at 01:19:06PM +0200, Nicolas Frattaroli wrote: > > With the "max bpc" KMS connector property, userspace can arbitrarily > > restrict the upper end of the bits-per-component range. This is fine and > > good, except the HDMI state helpers never considered that max_bpc could > > be influenced by a userspace setting, so assumed it'll always be an even > > value from the HDMI standards. > > > > This, unfortunately, is not the world we live in anymore. Patch 1 > > corrects sink_supports_format_bpc to return false on BPCs outside of > > what HDMI allows. Patch 2 then corrects handling of odd-numbered max > > bpcs by rounding the loop start value down to an even number instead. It > > also adds a KUnit test to make sure nobody breaks this again in the > > future. > > > > Signed-off-by: Nicolas Frattaroli > > Do you have a bit more details on the world you live in? :) > > In particular, why would erroring out on setting an odd value in > atomic_set_property not work? It would work, but it'd be an inferior solution IMHO. (If the intent was to point out this is already done then I can't find the code where such a check is performed.) It's perfectly fine, albeit weird, for userspace to say it wants a max bpc of 11. That HDMI does not support 11 bpc isn't really something the upper end of the range should concern itself with, much like we don't error out on a max bpc of 14 either even though HDMI does not support bit depths of 14 bits. By counting from the next even number, we don't leak our implementation's choice of trying every other bit depth through the uAPI with an overly restrictive constraint being placed. In an alternate universe, mirror world Maxime may have decided to i-- in that for loop instead just in case, and the second patch wouldn't be needed. Kind regards, Nicolas Frattaroli > > Maxime >