per-plane LUTs and CSCs?

[Daniel Vetter]

On Thu, Sep 10, 2020 at 07:50:59AM +0000, Simon Ser wrote:
> 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?

Uh, which drivers? This would be a driver bug (and there's been plenty of
those where the cursor has the wrong color temp and fun stuff like that).
We need to fix these driver issues instead of lamenting in userspace that
it's all kinda broken :-)
-Daniel

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

Yeah we can't expose such an uapi, instead what I have in mind that the
in-kernel lut/csc for yuv/broadcast rgb and whatever else are mixed in
with what userspace provides. That means a slight loss of precision and
we'll have to have a nice fixed point math library for this stuff in the
kernel. But color correction hw is too special between vendors that I
don't think there's any other solution. E.g. even on intel we sometimes
have dedicated register bits/hw functions for yuv/rgb broadcast value
range and whatever else, and on other platforms we need to do that by
adjusting the lut/csc.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch