Referring to this discussion: https://patchwork.kernel.org/patch/9546905/ Since the discussion, has there been any planning/work been done about the CTM2 API? We would need for omap drm (for DSS5 and DSS6) a similar matrix API for two purposes. However, neither of them is an exact match to the CTM property. 1. CRTC specific Color Phase Rotation matrix is pretty close to CTM concept, but it is applied after the gamma correction. However, there is an optional static full-range or limited-range post-offset vector and with it the CTM can also be used to convert the RGB output to a YCbCr display output. 2. Plane specific Color Space Conversion matrix and pre-offset vector is for YUV to RGB conversion. For customization purposes we would like to expose this 3x3 matrix and the 3-element offset vector to user space. So in general this is almost the same thing at the previous, but for reverse conversion. So when adding a CTM2 property blob, I would also vote for adding pre- and post-offset vectors. Then a CSC would simply be a combination off CTM and either a pre- or post- offset vector or maybe both, depending on whether the block provides a conversion from RGB to YUV, the other way around, or both. Then it is a question whether the offset vectors should be absolute or or relative to the bit depth of RGB components. A relative, with enough precision, would be the most generic choice but it would leave a lot of work to the driver code in many cases. For convenience there could also be a standard enum for selecting either custom coefficients or predefined standard conversion (Full-range, ITU-R BT.601, and ITU-R BT.709 at least). In general the color space conversion arithmetic are described well on this web page: http://www.equasys.de/colorconversion.html Best regards, Jyri _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
