[RFC] drm: add overlays as first class KMS objects

[Ville Syrjälä]

On Thu, Apr 28, 2011 at 12:03:32PM -0500, Rob Clark wrote:
> On Mon, Apr 25, 2011 at 5:12 PM, Jesse Barnes <jbarnes at virtuousgeek.org> wrote:
> > Looking for comments on this.  Obviously if we're going to add a new type
> > of KMS object, we'd better get the ioctl more or less right to begin with,
> > which means having all the attributes we'd like to track, plus some
> > padding, available from the outset.
> >
> > So I'd like comments on this; the whole approach may be broken for things
> > like OMAP; if so I'd like to hear about it now.  Overall, overlays are
> > treated a little like CRTCs, but without associated modes our encoder
> > trees hanging off of them.  That is, they can be enabled with a specific
> > fb attached at a specific location, but they don't have to worry about
> > mode setting, per se (though they do need to have an associated CRTC to
> > actually pump their pixels out, post-blend).
> >
> > Flipping could be done either with the existing ioctl by updating the fb
> > base pointer, or through a new flip ioctl similar to what we have already,
> > but taking an overlay object instead of a CRTC.
> 
> One thing I am wondering about is how to synchronize overlay position
> w/ flipping in the primary gfx layer?  Assuming you actually are
> flipping in primary layer you'd want a new set of overlay
> position/size to take effect on the same vblank that the flip in the
> gfx layer happens, because you are probably relying on some
> transparent pixels (or colorkey, if anyone still uses that) to be
> drawn in the UI layer.

That's a good reason to aim for an OpenWF Display type of API where you
can commit the whole device state atomically.

-- 
Ville Syrjälä
syrjala at sci.fi
http://www.sci.fi/~syrjala/