On Thursday, April 28th, 2022 at 09:50, Pekka Paalanen <ppaalanen@xxxxxxxxx> wrote: > > > > Also like Alex said, the kernel does not know if the user prefers high > > > > color depth or high refresh rate either. One way to solve that is to > > > > light up the requested video mode any way the kernel can, and then > > > > report what the resulting color depth is. Another way is to have > > > > explicit "use this bpc or fail" KMS property, maybe in the form of 'min > > > > bpc' as I recall being discussed in the past, and let userspace guess > > > > what might work. The former is easier to light up, but probing requires > > > > actually setting the modes. The latter may require a lot of > > > > trial-and-error from userspace to find anything that works, but it > > > > takes only time and not blinking - as far as things can be detected > > > > with TEST_ONLY commits. Then one still has to ask the user if it > > > > actually worked. > > > > > > min_bpc sounds like something we might want for HDR use-cases, unless > > > the compositor has a way to confirm the output box (and format). min_bpc > > > would allow the KMS driver to pick the lowest required bpc so the > > > compositor always has a guarantee of quality. > > > > IMO that would be ideal. The driver should try to reduce bandwidth by lowering > > the bpc down to the min_bpc if the hardware can't drive the selected mode at a > > higher bpc. User space usually knows which bpc is sufficient for the use case > > but will never complain about too much bpc. Drivers which don't support > > lowering the bpc dynamically can then still go with the min_bpc and user space > > still gets all the modes which work with the minimum required bpc. > > > This would be nice, yes. > > I'm fairly sure 'min bpc' was discussed here on the dri-devel mailing > list in the past, but I don't remember when or by whom. Yup. I explained there that I'd prefer "current bpc" + "user bpc" props and let user-space deal with the fallback logic just like it does for modes, modifiers, etc.
