On Fri, May 5, 2017 at 9:06 AM, Sharma, Shashank <shashank.sharma@xxxxxxxxx> wrote: > On 5/5/2017 12:28 PM, Daniel Vetter wrote: >> >> On Thu, May 04, 2017 at 05:51:45PM +0300, 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. >> >> But that means we'd need to have a bit-perfect match with a canonical >> conversion matrix (even if maybe the hw has a rounding bug and implements >> something slightly different than the standard). That seems a bit an >> awkward interface. Or is your idea that hw with a ctm would simply not >> expose the colorspace enum, if it doesn't also have fixed-function bits on >> top of the ctm? >> -Daniel > > I think the idea is to have separate properties for CTM and Gamut Mapping, > so that we can have more control > over linear and non-linear data blocks. All transformation should happen in > one property whereas all gamut > mapping should go into other, which IMHO seems to be the correct way to > operate. Yeah, for the programmable hw we should probably go with the degamma/ctm/gamma combo, like we have on the CRTC already. My question was how this interactions with some fixed-function color space conversion the hw might also have, and how these two sets of properties are mean to interact. On that topic, I think it'd be good if we put the helper functions and property documentation into drm_color_mgmt.c, so that it is all in one place, and to make sure we don't accidentally have different meanings for gamma table and ctm blobs. -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
