[PATCH RFC v2 2/2] drm: Add YCBCR_DECODE_CSC and YCBCR_CSC_PREOFFSET properties to drm_plane

[Daniel Vetter]

On Fri, May 5, 2017 at 12:45 PM, Ville Syrjälä
<ville.syrjala at linux.intel.com> wrote:
> On Fri, May 05, 2017 at 08:58:17AM +0200, 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 at ti.com>
>> > >
>> > > 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).
>
> I don't see what this has to do with bit correctness. Different hw is
> likely to use different precision for this stuff anyway, so I'm 100%
> sure we'll not get the same results from all hardware. And really,
> getting 100% same output doesn't seem all that important here
> anyway.
>
> Anyway, all I'm saying is that we should expose a standard pipeline:
> ycbcr->rgb -> degamma -> ctm -> gamma
>
> And each driver can then expose whatever parts of that they wish. If you
> want to expoe a programmable matrix you expose it as the ctm. I don't
> think having a programmable matrix as both ycbcr->rgb and ctm would
> really benefit us.

Ok, that makes sense. I was somehow assuming you're suggesting we only expose a
colors -> degamma -> ctm -> gamma pipeline and drivers with only fixed
function ycbcr2rbg conversion would then need to infer which exact
btsomethingsomething standard it should pick.

The above makes perfect sense, sorry for the confusion.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch