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

[Jesse Barnes <jbarnes@virtuousgeek.org>]

On Mon, 25 Apr 2011 16:35:20 -0700
Stéphane Marchesin <stephane.marchesin@gmail.com> wrote:

> On Mon, Apr 25, 2011 at 16:22, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> > On Mon, 25 Apr 2011 16:16:18 -0700
> > Keith Packard <keithp@keithp.com> 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.
> >
> > 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).
> >
> > 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.
> >
> 
> What is the plan for supporting multiple formats? When I looked at
> this for nouveau it ended up growing out of control when adding
> support for all the YUV (planar, packed, 12 or 16 bpp formats) and RGB
> format combinations.

I know there are a ton of surface formats, but I don't want to restrict
what drivers can export as supported.

I was planning on adding a new fb ioctl to allow us to create fbs with
specific surface format types.  We could either enumerate all of the
ones we support (a list which will grow as drivers and devices are
added) or try to factor out commit bits into a separate surface struct:

struct drm_mode_surface {
	enum components; /* YUV, VUY, RGB, BGR, ARGB, ... */
	int depth;
	enum packing; /* some list of packing types? */
	...
};

Even if we did that we may end up needing special surface formats not
covered by the general description.  I think pixman just ends up
enumerating them all; it's a little messy, but we know it would be
extensible at least. :)

-- 
Jesse Barnes, Intel Open Source Technology Center