Hello,
This patch series adds cubic (3D) look up table support to the CMM and DU drivers, and extend the KMS userspace API to expose the cubic LUT to userspace.
The code is fairly straightforward. Patch 1/4 refactors the CMM (color management module, the Renesas R-Car IP core that handles 1D and 3D lookup tables for the display) driver, which currently supports the 1D (a.k.a. gamma) table only, to prepare for 3D LUT support (including a modification to the API between the CMM and DU drivers). The CMM driver is then extended in patch 2/4 to support the 3D LUT.
Patch 3/4 adds support for the 3D LUT in the KMS core and the KMS userspace API, in the form of two new properties. I expect this to be the most controversial part of the series, not so much for the feature itself, but for when it is inserted in the color management pipeline.
Finally, patch 4/4 wires the KMS extension to the DU driver.
The R-Car CMM applies the 3D LUT at the output of the display, where data is transmitted in RGB space (when outputting YUV data to the display the CMM can't be used according to the documentation, but I wouldn't be entirely surprised if this limitation could be worked around), before the 1D LUT. I've located the 3D LUT between the CTM and the gamma LUT, but it could equally be placed before the degamma LUT or between the degamma LUT and the CTM in my case, as the R-Car color management pipeline has no CTM and has a single 1D LUT on the output side (there's provision for 1D LUT on the input side for some of the planes, but that's a separate topic).
I however don't expect this to necessarily match all hardware though, and this feature may require us to give up on a fixed, one size fits them all, color management pipeline exposed to userspace. Whether this would mean device-specific APIs (not necessarily in the form of device-specific properties, but in how they map to hardware features, as I think helpers to handle a 3D LUT property in the KMS core can save code duplication in drivers), or the need for a new property to expose the order in which color management operations are implemented, I don't know.
I started having a look at userspace to see how this could be handled, searching for color management support in weston, kwin and wlroots/sway. All three support setting the gamma table when using the DRM/KMS backend, weston and kwin through the legacy API, and wlroots through the atomic API. Weston reads an ICC profile using Little CMS and applies the gamma table. kwin is a bit more elaborate, it also uses Little CMS to read an ICC profile, but additionally supports setting the brightness and color temperature. It however only sets a gamma table in the end. Wlroots seems to have an API to set the gamma table, but I haven't seen where sway uses it (I may have missed that though). In any case, there's limited support there for color management.
Inputs would be appreciated on this, for instance with feedback on how X.org and Android handle color management, on how 3D LUTs are implemented on other platforms, or in general on how we would like to use them. I don't mind doing some work in userspace to prototype this, but I won't have the bandwidth to design a completely new framework.
Kieran Bingham (3): drm: rcar-du: cmm: Provide 3D-CLU support drm: Extend color correction to support 3D-CLU drm: rcar-du: kms: Configure the CLU
Laurent Pinchart (1): drm: rcar-du: cmm: Refactor LUT configuration
drivers/gpu/drm/drm_atomic_helper.c | 1 + drivers/gpu/drm/drm_atomic_state_helper.c | 3 + drivers/gpu/drm/drm_atomic_uapi.c | 10 ++ drivers/gpu/drm/drm_color_mgmt.c | 41 ++++++-- drivers/gpu/drm/drm_mode_config.c | 14 +++ drivers/gpu/drm/rcar-du/rcar_cmm.c | 110 +++++++++++++++------- drivers/gpu/drm/rcar-du/rcar_cmm.h | 22 +++-- drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 45 ++++++--- include/drm/drm_crtc.h | 9 ++ include/drm/drm_mode_config.h | 11 +++ 10 files changed, 207 insertions(+), 59 deletions(-)