On 2022-04-27 12:52, Pekka Paalanen wrote: > On Tue, 26 Apr 2022 20:55:14 +0300 > Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> wrote: >> On Tue, Apr 26, 2022 at 11:35:02AM +0300, Pekka Paalanen wrote: >>> >>> Do I lose the ability to set video modes that take too much bandwidth >>> at uncapped driver-selected bpc while capping the bpc lower would allow >>> me to use those video modes? >>> >>> Or, are drivers required to choose a lower-than-usual but highest >>> usable bpc to make the requested video mode squeeze through the >>> connector and link? >> >> IMO drivers should implement the "reduce bpc until it fits" >> fallback. We have that in i915, except for MST where we'd need >> to potentially involve multiple streams in the fallback. That >> is something we intend to remedy eventually but it's not an >> entirely trivial thing to implement so will take some actual >> work. ATM we just cap MST to <=8bpc to avoid users getting into >> this situation so often. > > Excellent, but judging from what Alex said, this is also not what > amdgpu does. We have two drivers doing different things then? > > So with Weston I probably have to document, that if you can't get the > video mode you want working, try turning the 'max bpc' knob down and > try again. > > Or, I could cap 'max bpc' based on my framebuffer depth. If I have an > electrical 8 bit FB (default in Weston), then there is not much use for > having 'max bpc' > 8. This ignores the KMS color pipeline a bit. Does > that make sense? I don't think so. The output of LUTs in current HW has at least 10 bpc, regardless of the FB format. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and Xwayland developer
