Re: [PATCH 0/2] Make HDMI state helpers handle odd max bpc requests

[Maxime Ripard <mripard@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 1473 bytes --]

On Wed, Jun 10, 2026 at 09:45:54AM +0200, Michel Dänzer wrote:
> On 6/9/26 14:51, Maxime Ripard wrote:
> > 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 <nicolas.frattaroli@collabora.com>
> > 
> > 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?
> 
> That doesn't make sense, since the "max bpc" property purely defines
> an upper limit. Setting an odd value for it doesn't mean the kernel
> has to use an odd effective bpc value, it can use any valid bpc <= the
> "max bpc" property value.

Ah, yes, of course. Thanks!
Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]