How should "max bpc" KMS property work?

Simon Ser contact at emersion.fr
Thu Apr 28 07:52:58 UTC 2022


On Thursday, April 28th, 2022 at 09:50, Pekka Paalanen <ppaalanen at gmail.com> 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.


More information about the dri-devel mailing list