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

[Jesse Barnes <jbarnes@virtuousgeek.org>]

On Mon, 25 Apr 2011 16:37:46 -0700
Keith Packard <keithp@keithp.com> wrote:

> On Mon, 25 Apr 2011 16:22:16 -0700, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> 
> > Yes, that matches my understanding as well.  I've deliberately made the
> > implementation flexible there though, under the assumption that some
> > hardware allows a plane to be directed at more than one CRTC (though
> > probably not simultaneously).
> 
> So you create a scanout buffer and assign it to the appropriate slot in
> the CRTC. Describing *how* the CRTC mixes pixels would be a good idea,
> so the ordering of the slots might be relevant, and they might have a
> blend mode (per-pixel alpha values, color key, separate alpha plane, etc).

Yeah, pixel blending and z order should be exposed.  I think that means
returning more info in the get_overlay_res ioctl.  Hm.. not sure of the
best way of representing that...

> > Arguably, this is something we should have done when the
> > connector/encoder split was done (making planes in general first class
> > objects).  But with today's code, treating a CRTC as a pixel pump and a
> > primary plane seems fine, with overlays tacked onto the side as
> > secondary pixel sources but tied to a specific CRTC.
> 
> I know of hardware that needs a lot more than one overlay...

Yeah I don't want to preclude that (and I don't think this
implementation does; it allows a many to one relationship between
overlays and CRTCs). TVs in particular can get messy since the z order
may be semi-fixed between certain planes, and blending may be limited to
different types at different layers.

-- 
Jesse Barnes, Intel Open Source Technology Center