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). Cheers, Jyri _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
