[PATCH RFC v2 2/2] drm: Add YCBCR_DECODE_CSC and YCBCR_CSC_PREOFFSET properties to drm_plane

[Daniel Vetter]

On Fri, May 5, 2017 at 4:36 PM, Laurent Pinchart
<laurent.pinchart at ideasonboard.com> wrote:
> I'm a bit concerned about this. The YCBCR_ENCODING property specifies how the
> content of the framebuffer is encoded. If I understand correctly, you're
> proposing adding an enumeration value that tells the driver not to try to be
> clever and multiply the CTM matrix by the CSC matrix corresponding to the
> encoding. That would probably work in most cases, but it would combine two
> pieces of information in a single property. The driver would then lose the
> knowledge of how the plane framebuffer is encoded. Couldn't there be cases
> where that knowledge is needed for other purposes than picking the right CSC
> matrix ? If so, it might be better to always set the YCBCR_ENCODING property
> to the actual encoding, and have another property to tell the driver to skip
> multiplication by the CSC matrix. Or could that be conveyed through the CTM
> blob property ? Some kind of flag that would essentially tell that the CTM
> matrix has been pre-multiplied already ?
>
> Before I forget, how do you plan to handle backward compatibility with
> userspace that won't set the YCBCR_ENCODING property ? Is that done by picking
> a driver-specific default value ? Do you think there would be a need for
> drivers to know that the property has not been set ?

Where do we need this? Afaik the encoding is to spec the yuv2rbg
conversion function, and that's it. But I'm fairly ignorant about
video and yuv and all these things. so does this specify something
else? If not, I don't see any possibilities that someone could
retrofit more meaning onto these conversion rules.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch