On Fri, May 5, 2017 at 4:36 PM, Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
