[RFC PATCH v4 1/2] drm: Add generic colorkey properties for display planes

[Russell King - ARM Linux]

On Tue, Aug 07, 2018 at 08:22:01PM +0300, Dmitry Osipenko wrote:
> + * Glossary:
> + *
> + * Destination plane:
> + *	Plane to which color keying properties are applied, this planes takes
> + *	the effect of color keying operation. The effect is determined by a
> + *	given color keying mode.
> + *
> + * Source plane:
> + *	Pixels of this plane are the source for color key matching operation.
...
> +	/**
> +	 * @DRM_PLANE_COLORKEY_MODE_TRANSPARENT:
> +	 *
> +	 * Destination plane pixels are completely transparent in areas
> +	 * where pixels of a source plane are matching a given color key
> +	 * range, in other cases pixels of a destination plane are unaffected.
> +	 * In areas where two or more source planes overlap, the topmost
> +	 * plane takes precedence.
> +	 */

This seems confusing to me.

What you seem to be saying is that the "destination" plane would be the
one which is (eg0 the graphic plane, and the "source" plane would be the
the plane containing (eg) the video.  You seem to be saying that the
colorkey matches the video and determines whether the pixels in the
graphic plane are opaque or transparent.

Surely that is the wrong way round - in video overlay, you want to
colorkey match the contents of the graphic plane to determine which
pixels from the video plane to overlay.

If it's the other way around (source is the graphic, destination is the
video) it makes less sense to use the "source" and "destination" terms,
I can't see how you could describe a plane that is being overlaid on
top of another plane as a "destination".

I guess the terminology has come from a thought about using a GPU to
physically do the colorkeying when combining two planes - if the GPU
were to write to the "destination" plane, then this would be the wrong
way around.  For starters, taking the above example, the video plane
may well be smaller than the graphic plane.  If it's the other way
around, that has other problems, like destroying the colorkey in the
graphic plane when writing the video plane's contents to it.

So, in summary, I don't think "destination" and "source" are
particularly good terms to describe the operation, and I think you have
them swapped in your description of
"DRM_PLANE_COLORKEY_MODE_TRANSPARENT".

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 13.8Mbps down 630kbps up
According to speedtest.net: 13Mbps down 490kbps up