On Thu, Sep 10, 2020 at 4:29 AM Simon Ser <cont...@emersion.fr> wrote: > > On Thursday, September 10, 2020 10:18 AM, Daniel Vetter <dan...@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.pa...@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
This is a hardware limitation. I suspend all hardware of a certain age had this same limitation. Old stuff didn't have multiple planes. It had a primary plane and a cursor and gamma didn't apply to the cursor. The hardware supported by radeon goes back more than 20 years. Alex > > > > 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. > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
