On 05/04/17 17:51, Ville Syrjälä wrote: > On Thu, May 04, 2017 at 03:22:45PM +0200, Daniel Vetter wrote: >> On Thu, May 04, 2017 at 10:14:26AM +0300, Jyri Sarha wrote: >>> Add standard optinal property blobs for YCbCr to RGB conversion CSC >>> matrix and YCbCr preoffset vector in DRM planes. New enums are defined >>> to YCBCR_ENCODING property to activate the CSC and preoffset >>> properties. For simplicity the new properties are stored in the >>> drm_plane object, because the YCBCR_ENCODING is already there. The >>> blob contents are defined in the uapi/drm/drm_mode.h header. >>> >>> Signed-off-by: Jyri Sarha <jsarha@xxxxxx> >> Not sure we want to make this yuv2rgb specific, plenty of planes have >> generic degamma/offset, csc, gamme/offset hw. I think what we want instead >> is the generic csc support, plus a ycbcr2rgb mode of "bypass". > My idea is to not expose this. And instead just expose a normal > ctm, and then just refuse any combination of YCbCr->RGB/degamma/ctm > that can't be done by the hw. > So, pulling the suggestions together the properties would now look like this: YCBCR_RANGE - Full - Limited YCBCR_ENCODING - BT.601 - BT.709 - BT.2020 CTM (blob) And all these properties could be added to individual planes. I'll try to come up with a new patch to add simple enum properties for YCBCR_PREOFFSET and YCBCR_ENCODING for planes. Should we need any more enum values for those? The only functional thing that is missing from the above proposal is the possibility to define an arbitrary YCbCr preoffset vector, but that can be added later if there ever is any real need. The other thing that could be added for special purposes would be adding an "Identity" enum to YCBCR_ENCODING, that would allow setting the YCbCr CSC trough CTM without any driver level multiplication getting in way, but that can also be added if there is a need. Best regards, Jyri _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
