[Intel-gfx] [RFC 1/1] drm/i915: Added support for setting plane alpha through drm property

[Ville Syrjälä]

On Wed, Feb 19, 2014 at 03:38:08PM +0530, sagar.a.kamble at intel.com wrote:
> From: Sagar Kamble <sagar.a.kamble at intel.com>
> 
> With this patch two properties are added. One for CRTC+Sprite planes
> and another for Cursor planes. Through these client will be able to
> change the pixel format of the planes w.r.t Alpha channel.
> Number of drm properties are limited so should we restrain from adding this
> as drm property or should we expose this as IOCTL itself.

We need to stop adding properties on a whim and design and document them
properly. So what I'd like to see is someone going over the current
properties and collecting them up in some (even bares bones) documentation
in Documentation/Docbook. The current way will lead to a huge mess when
userspace actually starts to depend on properties. So far properties
have been mostly some optional extra junk on the side people that may
want to frob, but that's going to change as we add more of them,
especially with plane and crtc properties, which actually affect how
the scene gets composed together.

And I think we need to put a hold on adding the plane properties to the
crtc since the plan is to convert everything to drm_plane. With the
current rate we're going to have a ton of properties on the crtc that no
one will use. Adding properties to the sprite planes seems OK in the
meantime.

As far as alpha blending is concerned I've had the following ideas:
- we need a plane property for constant alpha. Some drivers might
  already have this, so might be good to check. Although I'm fairly
  sure what's there won't be entirely future proof. I was thinking that
  we should standardize of using 16bits for color components in
  properties. That way you can still stick a full ARGB value into
  one property, and we should be good for a few more years until
  someone has the idea to move beyond 16bits per channel. And it's
  more or less hardware agnostic. Obviously if the hardware won't
  use the full precision, you get to throw away the low bits, but I
  don't think there's any other good way to go.
- we need another property to indicate whether the source pixels
  are premultiplied or not. Or maybe it's easier for people to think
  in terms of what operations the hardware will do, in which case
  we should make the property indicate whether the hardware will
  do the premultiplication during blending or not. I'm not sure
  which approach feels more natural to people.
- And finally we need to figure out how to blend it all together.
  It might make sense to model this after glBlendFunc(), so it would
  be an enum property, or maybe two if we want separate properties
  for source and destination factors.

Obviously the final result will depend on additional things like the
z-order, which is going to be another property. I think this one might
already exists in some form in other drivers. So we should definitely
look at what's there and try to do the same if possible. Which again
underlines the need to collect up the current properties into some
central documentation.

-- 
Ville Syrjälä
Intel OTC