On 2022-04-27 12:52, Pekka Paalanen wrote:
On Tue, 26 Apr 2022 20:55:14 +0300 Ville Syrjälä ville.syrjala@linux.intel.com 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.