On 12/12/22 19:21, Harry Wentland wrote: > This will let us pass kms_hdr.bpc_switch. > > I don't see any good reasons why we still need to > limit bpc to 8 bpc and doing so is problematic when > we enable HDR. > > If I remember correctly there might have been some > displays out there where the advertised link bandwidth > was not large enough to drive the default timing at > max bpc. This would leave to an atomic commit/check > failure which should really be handled in compositors > with some sort of fallback mechanism. > > If this somehow turns out to still be an issue I > suggest we add a module parameter to allow users to > limit the max_bpc to a desired value. While leaving the fallback for user space to handle makes some sense in theory, in practice most KMS display servers likely won't handle it. Another issue is that if mode validation is based on the maximum bpc value, it may reject modes which would work with lower bpc. What Ville (CC'd) suggested before instead (and what i915 seems to be doing already) is that the driver should do mode validation based on the *minimum* bpc, and automatically make the effective bpc lower than the maximum as needed to make the rest of the atomic state work. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and Xwayland developer
