[RFC] drm: add overlays as first class KMS objects
jbarnes at virtuousgeek.org
Mon Apr 25 16:58:17 PDT 2011
On Mon, 25 Apr 2011 16:37:46 -0700
Keith Packard <keithp at keithp.com> wrote:
> On Mon, 25 Apr 2011 16:22:16 -0700, Jesse Barnes <jbarnes at 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
More information about the dri-devel