[PATCH RFC 3/6] drm: Plane YCbCr to RGB conversion related properties

[Ville Syrjälä]

On Mon, Apr 24, 2017 at 06:49:04PM +0300, Jyri Sarha wrote:
> On 04/24/17 18:13, Ville Syrjälä wrote:
> >> What about the uapi structs? In the patch there is an explicit struct
> >> naming each coefficient for what they are for in YCbCr to RGB
> >> conversion. Is this Ok, or should we go with a generic (CTM style)
> >> matrix, that could be used for RGB to YCbCr conversion too?
> > Not sure what we're talking about here, but like I said I think we
> > should stick to a fairly limited set of standard props and just have
> > each driver map the hardware resources to them as best they can.
> > 
> 
> Just about the implementation detail, if we should have a separate uapi
> struct for YCbCr to RGB CSC and RGB to YCbCr CSC. If we are going to use
> the same struct, then we could as well use the already existing CTM struct.
> 
> > If you just have csc+(de)gamma then I guess it might make sense
> > to just expose the YCbCr->RGB and degamma. If you have
> > degamma+csc+gamma then it might make sense to expose both
> > YCbCr->RGB, degamma, CTM, and gamma, and just refuse any
> > combination that can't be done. Eg. can't do YCbCr->RGB if
> > degamma is used, and YCbCr->RGB + CTM would require multiplying
> > the matrices together which you may or may not want to bother
> > with, I guess we could try to put some matrix math helpers into
> > the core to make such things less painful for drivers?
> 
> In fact we have plane specific YCbCr to RGB CSC (only preoffset
> possible), then (per crtc) gamma table, and finally a (per crtc) RGB to
> YCbCr CSC with optional post offset (so it can be used either as CSC or
> CTM).

So with that plane hw you could perhaps do:
- YCbCr->RGB if you input is not linear, but then you must
  blend using non-linear data
- colorspace conversion if your input is alredy linear

And with your crtc hw you could do:
- degamma + CTM
- gamma + RGB->YCbCr

-- 
Ville Syrjälä
Intel OTC