On Tue, Apr 26, 2022 at 11:35:02AM +0300, Pekka Paalanen wrote: > Hi all, > > I'm working on setting HDR & WCG video modes in Weston, and I thought > setting "max bpc" KMS property on the connector would be a good idea. > I'm confused about how it works though. > > I did some digging in > https://gitlab.freedesktop.org/wayland/weston/-/issues/612 > > Summary: > > - Apparently the property was originally added as a manual workaround > for sink hardware behaving badly with high depth. A simple end user > setting for "max bpc" would suffice for this use. > > - Drivers will sometimes automatically choose a lower bpc than the "max > bpc" value, but never bigger. > > - amdgpu seems to (did?) default "max bpc" to 8, meaning that I > definitely want to raise it.
I've occasionally pondered about doing the same for i915, just to have the safest default possible. But I'd hate to lose the deep color testing coverage knowing very few people would in practice raise the limit. Also the number of systems where deep color doesn't work reliably (or can't be made to work by not using a crap cable) seems to be quite low. > > If I always slam "max bpc" to the highest supported value for that > property, do I lose more than workarounds for bad sink hardware? We don't have any workarounds implemented like this in the kernel. Or should not have at least. "max bpc" exists purely for the user to have a say in the matter in addition to whatever the EDID/quirks say. Ie. if the kernel knows for sure that deep color won't work on a particular setup then it should just not allow deep color at all despite what the prop value says. So the only danger is fighting with the user's wishes which I guess you can overcome with some kind of user visible knob. > > 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. > > Do I need to implement a fallback strategy in a display server, > starting from the highest possible "max bpc" value, and if my modeset > is rejected, repeatedly try with lower "max bpc" setting until it works > or I'm out of bpc options? IMO the bpc part should be handled by the kernel since we already had this behaviour even before the "max bpc" prop was introduced and we didn't add an explicit "use this bpc or fail" prop. But of course you should have some kind of sensible fallback strategy for things that just fail for other reasons. The one problem we have in the kernel is that we have no way to ask the user if the display we tried to light up is actually working. So our policy decisions can't really involve user input. Userspace should not generally have that problem. -- Ville Syrjälä Intel
