Re: [PATCH v2 0/2] rcar-du, vsp1: rcar-gen3: Add support for colorkey alpha blending

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Alex et all,

On Tuesday, 9 May 2017 10:12:31 EET Gheorghe, Alexandru wrote:
> On Mon, Monday, May 8, 2017 9:29 PM +0200, Daniel Vetter wrote:
> > On Mon, May 08, 2017 at 09:33:37AM -0700, Eric Anholt wrote:
> >> Alexandru Gheorghe <Alexandru_Gheorghe@xxxxxxxxxx> writes:
> >>> Currently, rcar-du supports colorkeying  only for rcar-gen2 and it
> >>> uses some hw capability of the display unit(DU) which is not available
> >>> on gen3.
> >>> 
> >>> In order to implement colorkeying for gen3 we need to use the
> >>> colorkey capability of the VSPD, hence the need to change both
> >>> drivers rcar-du and vsp1.
> >>> 
> >>> This patchset had been developed and tested on top of
> >>> v4.9/rcar-3.5.1 from
> >>> git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git
> >> 
> >> A few questions:
> >> 
> >> Are other drivers interested in supporting this property?  VC4 has the
> >> 24-bit RGB colorkey, but I don't see YCBCR support.  Should it be
> >> documented in a generic location?
> 
> As far as I identified  armada, i815, nouveau, rcar-du, vmwgfx drivers have
> this notion of colorkey. There could be other HW which don't have this
> implemented yet.

Among those drivers only armada, nouveau and rcar-du expose the color key 
through DRM properties. The i915 and vmwgfx drivers use custom ioctls. Here is 
what is currently implemented.

- armada

"colorkey" range  0x00000000 0x00ffffff
"colorkey_min" range  0x00000000 0x00ffffff
"colorkey_max" range  0x00000000 0x00ffffff
"colorkey_val" range  0x00000000 0x00ffffff
"colorkey_alpha" range  0x00000000 0x00ffffff
"colorkey_mode" enum "disable", "Y component", "U component", "V component", 
"RGB", "R component", "G component", "B component"

All range properties store a RGB888 or YUV888 triplet.

The min and max properties store the comparison ranges. When a match occurs 
for one of the components, the value and alpha from the val and alpha 
properties replace the pixel. It's not clear which of the alpha "components" 
is used when a match occurs in RGB mode.

The colorkey property is a shortcut that stores identical values in min, max 
and val and 0 in alpha.

- i915

#define I915_SET_COLORKEY_NONE          (1<<0)
#define I915_SET_COLORKEY_DESTINATION   (1<<1)
#define I915_SET_COLORKEY_SOURCE        (1<<2)

struct drm_intel_sprite_colorkey {
        __u32 plane_id;
        __u32 min_value;
        __u32 channel_mask;
        __u32 max_value;
        __u32 flags;
};

- nouveau

"colorkey" range 0x00000000 0x01ffffff

The format isn't documented but it seems from the source code that bits 23:0 
store the color key value (written directly to a register, so possibly in a 
pixel format-dependent format) and bit 24 enables color keying.

- rcar-du

"colorkey" range 0x00000000 0x01ffffff

Bits 23:0 store the color key value in RGB888 (regardless of the pixel format 
of the plane) and bit 24 enables color keying. This supports Gen2 hardware 
only, where the only available more is  exact match. The pixel then becomes 
fully transparent (the hardware doesn't support custom target alpha values).

On Gen3 hardware color keying can be performed in exact RGB match, exact Y 
match or range Y match (only the max value is programmable, the min value is 
always 0). Furthermore in exact match modes the hardware can operate with a 
single match value, in which case it can then override the full ARGB or AYUV 
pixel, or double match value, in which case it can then override the alpha 
component only, but with two distinct match values each associated with a 
target alpha.

- vmwgfx

struct drm_vmw_control_stream_arg {
        __u32 stream_id;
        __u32 enabled;

        __u32 flags;
        __u32 color_key;

        __u32 handle;
        __u32 offset;
        __s32 format;
        __u32 size;
        __u32 width;
        __u32 height;
        __u32 pitch[3];

        __u32 pad64;
        struct drm_vmw_rect src;
        struct drm_vmw_rect dst;
};

The color_key field isn't documented, but the following (unused) macros hint 
that it could store an RGB888, with the color key feature enabled through the 
flags field.

#define SVGA_VIDEO_FLAG_COLORKEY        0x0001
#define SVGA_VIDEO_COLORKEY_MASK             0x00ffffff

> >> Does your colorkey end up forcing alpha to 1 for the plane when it's
> >> not matched?
> 
> I think this  behavior is HW dependent, on R-CAR Gen3, the alpha for pixel
> that don't match is not touch.
> 
> > I think generic color-key for plane compositioning would be nice, but I'm
> > not sure that's possible due to differences in how the key works.
> 
> I'm thinking of starting from the drivers that do have this property and see
> if there is any common ground for a generic color-key property/ies

Looking at the 5 drivers we have in mainline that support color keying one way 
or another, we can already see that the hardware implementations differ quite 
widely. There are however similarities, and we could express most of the above 
features through a set of generic properties similar to the ones already 
implemented by the armada driver.

- The match range could be set through minimum and maximum properties. Drivers 
that support exact match only would report an error with minimum != maximum.

- The replacement value could be set through a value property. The property 
could store both the pixel value (RGB or YUV) and the alpha value, or we could 
separate those in two properties. With a single property bits that are not 
applicable would be ignored (for instance RGB/YUV bits when the driver 
supports alpha replacement only). If programmable color replacement isn't 
supported (as in the R-Car Gen2 example above) the property could be omitted.

- The mode could be set through a mode property. Enabling color keying through 
one bit in a color property (like done by the nouveau and rcar-du drivers) is 
a hack and I don't think we should carry it forward. A mode property would 
also allow configuring source or destination color keying.

- Part of the mode information could be deduced automatically without a need 
to specify it explicitly. For instance RGB/YUV mode can be configured based on 
the pixel format of the plane. Similarly, exact match vs. range match can be 
configured based on whether the minimum and maximum value differ.

- Properties that store pixel values could either contain a value in a fixed 
format (e.g. RGB888) or in a format that varies depending on the pixel format 
(e.g. encoded in the same pixel format as the plane). I have a preference for 
the former but I'm open for discussions.

- We need to keep the existing "colorkey" properties implemented by armada, 
nouveau and rcar-du for backward compatibility reasons, but this proposed API 
doesn't require a "colorkey" property. We could however decide to standardize 
a "colorkey" property as a shortcut similar to what the armada driver does.


Some of the R-Car Gen3 hardware features wouldn't be supported by the above 
proposal. Selecting exact match vs. range match should be fine, with atomic 
commit returning an error if minimum != 0 && minimum != maximum. The dual 
target mode, however, can't really fit the properties proposed here. I don't 
have a use case for that mode at the moment but I'm fairly certain that 
someone will come up with one, at least if not for the R-Car for a different 
display engine that provides similarly exotic features.

We could also decide to standardize the color keying properties in a way that 
would balance complexity vs. hardware features support, and let drivers that 
need exotic features implement additional properties.

Ideas and comments are welcome, I'd like to start working on this fairly soon.

-- 
Regards,

Laurent Pinchart




[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux