per-plane LUTs and CSCs?

[Pekka Paalanen]

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


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20200910/7007ecef/attachment.sig>