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 <[email protected]> > > > > 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
signature.asc
Description: PGP signature
