Re: [PATCH v2] drm/color: Document CTM eqations

[Brian Starkey]

Hi Ville,

On Tue, Jan 31, 2017 at 05:18:28PM +0200, Ville SyrjÃlà wrote:
> On Tue, Jan 31, 2017 at 10:48:34AM +0000, Brian Starkey wrote:
> > Explicitly state the expected CTM equations in the kerneldoc for the CTM
> > property, and the form of the matrix on struct drm_color_ctm.
> >
> > Cc: Ville SyrjÃlà <ville.syrjala@xxxxxxxxxxxxxxx>
> > Cc: Lionel Landwerlin <lionel.g.landwerlin@xxxxxxxxx>
> > Cc: Daniel Vetter <daniel.vetter@xxxxxxxx>
> > Signed-off-by: Brian Starkey <brian.starkey@xxxxxxx>
> > ---
> >  drivers/gpu/drm/drm_color_mgmt.c |   13 +++++++++++++
> >  include/uapi/drm/drm_mode.h      |    8 +++++++-
> >  2 files changed, 20 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_color_mgmt.c b/drivers/gpu/drm/drm_color_mgmt.c
> > index 789b4c65cd69..7573ca4b6ea6 100644
> > --- a/drivers/gpu/drm/drm_color_mgmt.c
> > +++ b/drivers/gpu/drm/drm_color_mgmt.c
> > @@ -62,6 +62,19 @@
> >   *	unit/pass-thru matrix should be used. This is generally the driver
> >   *	boot-up state too.
> >   *
> > + *	The output vector is related to the input vector as below:
> > + *
> > + *	| ``out[0] = matrix[0] * in[0] + matrix[1] * in[1] + matrix[2] * in[2];``
> > + *	| ``out[1] = matrix[3] * in[0] + matrix[4] * in[1] + matrix[5] * in[2];``
> > + *	| ``out[2] = matrix[6] * in[0] + matrix[7] * in[1] + matrix[8] * in[2];``
> > + *
> > + *	The component order in the input/output vectors is assumed to be
> > + *	{ R, G, B }.
> > + *
> > + *	The color-space of the input vector must not be confused with the
> > + *	color-space implied by a framebuffer pixel format, which may be the same
> > + *	or different.
> > + *
> >   * âGAMMA_LUTâ:
> >   *	Blob property to set the gamma lookup table (LUT) mapping pixel data
> >   *	after the transformation matrix to data sent to the connector. The
> > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> > index ce7efe2e8a5e..3401637caf8e 100644
> > --- a/include/uapi/drm/drm_mode.h
> > +++ b/include/uapi/drm/drm_mode.h
> > @@ -525,7 +525,13 @@ struct drm_mode_crtc_lut {
> >  };
> >
> >  struct drm_color_ctm {
> > -	/* Conversion matrix in S31.32 format. */
> > +	/*
> > +	 * Conversion matrix in S31.32 format, in row-major form:
>
> s32.32 is how I'd state that (to match the regular s32 and whatnot
> types).

Can you explain a bit more what exactly you mean by s32.32? e.g. what
would be the bitfield representing the most negative number?

I understand the S31.32 here as a sign + magnitude format (which makes
it rather odd to store it in a signed variable, but never mind). This
also appears to be what igt does in set_ctm() in kms_pipe_color.c:

	for (i = 0; i < ARRAY_SIZE(ctm.matrix); i++) {
		if (coefficients[i] < 0) {
			ctm.matrix[i] =
				(int64_t) (-coefficients[i] * ((int64_t) 1L << 32));
			ctm.matrix[i] |= 1ULL << 63;
		} else
			ctm.matrix[i] =
				(int64_t) (coefficients[i] * ((int64_t) 1L << 32));
	}

If that's what you meant as well, then I don't think s32.32 is a good
way to describe it, because the integer part has only 31 bits
available.

If you meant a regular two's-complement fixed-point number, where the
most negative number would be 0x10000000.00000000, then yeah that's
what I thought it meant too originally. Clarifying the docs here
sounds like a great plan.

I guess the igt implementation means that it's a sign + magnitude
number, and the fact that it's stored in an s64 is a bizarre quirk
that we just live with.

Cheers,
Brian

> > +	 *
> > +	 * | matrix[0] matrix[1] matrix[2] |
> > +	 * | matrix[3] matrix[4] matrix[5] |
> > +	 * | matrix[6] matrix[7] matrix[8] |
> > +	 */
> >  	__s64 matrix[9];
> >  };
> >
> > --
> > 1.7.9.5
>
> --
> Ville SyrjÃlÃ
> Intel OTC