per-plane LUTs and CSCs?

[Simon Ser]

On Thursday, September 10, 2020 10:18 AM, Daniel Vetter <daniel at ffwll.ch> wrote:

> 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 :-)

Apparently this is bug with the old radeon driver [1]. It works fine on
all i915 setups I've tried, and also works fine on amdgpu (with DC).

I've opened a radeon bug.

[1]: https://github.com/swaywm/wlroots/issues/968

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

Yeah, that makes sense to me.