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

["Michel Dänzer" <michel.daenzer@mailbox.org>]

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.


-- 
Earthling Michel Dänzer       \        GNOME / Xwayland / Mesa developer
https://redhat.com             \               Libre software enthusiast