On Thu, Sep 10, 2020 at 10:25:43AM +0300, Pekka Paalanen wrote: > On Wed, 9 Sep 2020 13:57:28 +0300 > Laurentiu Palcu <laurentiu.palcu@xxxxxxxxxxx> 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... I think even if we have userspace doing this, we still need the default tables so that old userspace keeps working. E.g. I'm assuming this is also used for yuv->rgb conversion and range limiting and all these things. In i915 I think we even combine the userspace lut/csc with the one we need for color space fixes in some cases. So maybe a helper library which helps drivers do that would also be needed. > > 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. Personally I think best to wait for userspace to come up with color manager protocols, that should give us a much clearer idea of what the kernel interface should look like. Since hw is pretty special in this area, I expect we'll have to do a bunch of impendendance mismatching in the kernel anyway. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
