On Thu, Apr 28, 2022 at 4:50 PM Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> wrote: > > On Thu, Apr 28, 2022 at 07:52:58AM +0000, Simon Ser wrote: > > 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. > > The main problem is that the bpc is not really al that well defined. > We have stuff like 4:2:0 subsampling, DSC (compression), etc. muddying > the waters. Of course max_bpc already suffers a bit from those issues, > but at least it can still claim to do what it says on the tin. > Guaranteeing any kind of minimum bpc is not possible without first > defining what that actually means. > > Oh and the various processing blocks in the pipeline might also have > varying input/output precision. So those can also degrade the quality > regardless of how many bits are coming out the end of the pipe. > > I suspect trying to exose all that explicitly would result in an API > that just has too many knobs and interactions between the knobs. So > likely no one would be able to succesfully use it. I said something similar on IRC earlier today and I agree. We have 3 options here: 1. Don't give user space any kind of information 2. Give user space all the information so that it can figure out the effective bpc 3. Let the kernel figure out the effective bpc We *need* the information in user space so 1. is not going to work. Exposing all hardware details in the current KMS API just won't work well. So that leaves the kernel having to estimate the effective bpc. I also agree that we have to define what the effective bpc is and IMO it should contain not only connector properties but also all the color processing blocks, pipe limitations and dithering in between the framebuffer and the connector. (or we can burn KMS down and create a libcamera kind of thing :>) > > -- > Ville Syrjälä > Intel >
