per-plane LUTs and CSCs?

[Simon Ser]

On Wednesday, September 9, 2020 12:57 PM, 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...

Apart from full color management mentioned by Pekka, are there other
use-cases for these per-plane props?

One thing I can think of is that some drivers annoyingly only apply the
per-CRTC gamma LUT to the primary plane. I think it would make more
sense to not attach a gamma prop to the CRTC and instead only attach it
to the primary plane to make that clear. But I guess that would also
break existing user-space?

The gamma LUT is currently used by some compositors to implement "night
light"/redshift-like features.

> 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...

So it wouldn't be enough for user-space to fill these gamma LUTs with
linear ramps and get colors that look fine? Would the process be more
involved? Would user-space need to know about the driver and generate
gamma LUTs depending on the driver?

That would be a show-stopper.