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

[Jesse Barnes <jbarnes@virtuousgeek.org>]

On Tue, 26 Apr 2011 18:20:03 +0300
Ville Syrjälä <syrjala@sci.fi> wrote:

> On Mon, Apr 25, 2011 at 04:16:18PM -0700, Keith Packard wrote:
> > On Mon, 25 Apr 2011 15:12:20 -0700, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> > 
> > > Overlays are a bit like half-CRTCs.  They have a location and fb, but
> > > don't drive outputs directly.  Add support for handling them to the core
> > > KMS code.
> > 
> > Are overlays/underlays not associated with a specific CRTC? To my mind,
> > overlays are another scanout buffer associated with a specific CRTC, so
> > you'd create a scanout buffer and attach that to a specific scanout slot
> > in a crtc, with the 'default' slot being the usual graphics plane.
> 
> And what if you don't have a "default" plane as such. For example, OMAP3 
> has one graphics plane and two video planes, and two output paths. Each
> of the planes can be assigned to zero or one outputs. To accomodate this,
> the design should allow for CRTCs without any scanout buffers.
> 
> Also a glance at DirectFB and OpenWF Display APIs might be helpful.

The current drm crtc code ties together a crtc and fb, but it wouldn't
be too hard to split it out a little (such that passing a null fb on a
mode set wouldn't disable the crtc, or attaching a new scanout surface
to a crtc would enable it) to support something like that.

-- 
Jesse Barnes, Intel Open Source Technology Center