per-plane LUTs and CSCs?

[Daniel Vetter]

On Thu, Sep 10, 2020 at 10:25:43AM +0300, Pekka Paalanen wrote:
> On Wed, 9 Sep 2020 13:57:28 +0300
> Laurentiu Palcu <laurentiu.palcu at oss.nxp.com> wrote:
> 
> > Hi all,
> > 
> > I was wondering whether you could give me an advise on how to proceed further
> > with the following issue as I'm preparing to upstream the next set of patches
> > for the iMX8MQ display controller(DCSS). The display controller has 3 planes,
> > each with 2 CSCs and one degamma LUT. The CSCs are in front and after the LUT
> > respectively. Then the output from those 3 pipes is blended together and then
> > gamma correction is applied using a linear-to-nonlinear LUT and another CSC, if
> > needed.
> > 
> > Currently, downstream, we have all those CSCs and LUTs hard-coded into a header
> > file. Based on the colorspace, range, gamut selected for the output and/or
> > plane input, we pick up the right CSCs and LUTs from that header file to
> > configure our pipes... I guess this solution does the job, userspace doesn't
> > need to care much about how to generate those tables. But, it's also not very
> > flexible in case there is an app smart enough to know and actually generate
> > their own custom tables. :/
> > 
> > Looking through the dri-devel archives, I've seen that there was a tentative to
> > implement a more or less generic per-plane LUT/CSC solution but it didn't make
> > it in due to lack of userspace consumers...
> > 
> > Adding CSC and degamma LUT properties for each plane as well as a gamma
> > LUT and CSC for CRTC, would help get rid of the LUT/CSC header and rely
> > entirely on userspace to fill in those tables. But userspace has to know
> > how to generate those LUTs and colorspace conversion matrices in the
> > first place...

I think even if we have userspace doing this, we still need the default
tables so that old userspace keeps working. E.g. I'm assuming this is also
used for yuv->rgb conversion and range limiting and all these things. In
i915 I think we even combine the userspace lut/csc with the one we need
for color space fixes in some cases.

So maybe a helper library which helps drivers do that would also be
needed.

> > So, how should I continue with this one? Any pointers?
> 
> Hi,
> 
> I can't help you, but I can say that we are currently in the process of
> designing a color management and HDR extension for Wayland, and I'm
> sure in the long term I would like to use per-plane color space
> transformation features of KMS in Weston eventually.
> 
> IOW, one more userspace that is going to be taking advantage of such
> features as long as they are not too driver-specific.

Personally I think best to wait for userspace to come up with color
manager protocols, that should give us a much clearer idea of what the
kernel interface should look like. Since hw is pretty special in this
area, I expect we'll have to do a bunch of impendendance mismatching in
the kernel anyway.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch