Re: [PATCH 03/20] drm/i915: add constant alpha support to sprite ioctl

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

On Tue, Mar 19, 2013 at 10:57:25AM -0700, Jesse Barnes wrote:
> On Tue, 19 Mar 2013 09:42:56 +0100
> Daniel Vetter <daniel@ffwll.ch> wrote:
> > > --- a/include/uapi/drm/i915_drm.h
> > > +++ b/include/uapi/drm/i915_drm.h
> > > @@ -949,6 +949,7 @@ struct drm_intel_overlay_attrs {
> > >  #define I915_SET_COLORKEY_NONE		(1<<0) /* disable color key matching */
> > >  #define I915_SET_COLORKEY_DESTINATION	(1<<1)
> > >  #define I915_SET_COLORKEY_SOURCE	(1<<2)
> > > +#define I915_SET_COLORKEY_ALPHA		(1<<3)
> > 
> > We've added this driver-private ioctl before attributes everywhere was
> > possible. I think we need to convert that before adding more stuff ...
> > 
> > Also some discussion on dri-devel about a somewhat standardized set of
> > plane blending properties can't hurt.
> > 
> > Yes, I know that this will lead to a massive dri-devel bikeshed ;-)
> 
> Yeah we need some properties for this to fit in with the atomic bits.
> This patch actually pre-dates that by a bit (it's very old)...
> 
> I'm sure Ville has ideas on what he'd like to see.

Yeah, I've been pondering about this kind of stuff.

One idea was that we might want to make the props for
color key/mask, background color, const alpha etc. always use 16bpc,
and then we can just drop the least significant bits if the HW uses
less precision. And also fix the channel order to some common standard.
That might make it a bit easier to write generic user space code.

But I'm not sure how to deal w/ RGB vs. YCbCr. Sometimes you may
need to feed hardware RGB values, sometimes YCbCr.

Options:
1. use one prop but the driver will interpret the values as RGB or
   YCbCr as needed. Userspace just has to figure out what to stuff
   into prop somehow.
2. one prop for RGB, another one for YCbCr. If the hw has need for
   both, it'll pick the right one. Again userspace just has to figure
   out which one it should use at a given time
3. standardize on RGB and convert to YCbCr in the driver as needed


As for the per-pixel alpha, I'm not sure if relying on the pixel
format alone is the best idea. At least we need a way to tell the
premult and non-premult cases apart. But maybe we want to even allow
disabling per-pixel alpha for ARGB formats, so that we don't need
to create an XRGB fb for the same data. So maybe an enum prop w/
"no per-pixel alpha", "pre-mult", "non-premult" options.

-- 
Ville Syrjälä
Intel OTC