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

Jesse Barnes jbarnes at virtuousgeek.org
Mon Apr 25 17:33:25 PDT 2011

On Mon, 25 Apr 2011 20:28:20 -0400
Alex Deucher <alexdeucher at gmail.com> wrote:

> On Mon, Apr 25, 2011 at 7:22 PM, Jesse Barnes <jbarnes at virtuousgeek.org> wrote:
> > On Mon, 25 Apr 2011 16:16:18 -0700
> > Keith Packard <keithp at keithp.com> wrote:
> >
> >> On Mon, 25 Apr 2011 15:12:20 -0700, Jesse Barnes <jbarnes at 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).
> A lot of older hardware had one overlay that could be sourced to any
> crtc, just not simultaneously.  The tricky part is the formats and
> capabilities: alpha blending, color/chromakey, gamma correction, etc.
> Even the current crtc gamma stuff is somewhat lacking in in terms of
> what hardware is capable of (PWL vs. LUT, user defined conversion
> matrices, gamut remapping, etc.).

Right, this implementation allows an overlay to be tied to any crtc
listed in the possible_crtcs mask (matching the other possible_*
fields), but only one at a time.  I think that's fairly common.

Agree about formats and capabilities.  I think enumerating available
formats is best, perhaps making that a driver specific array if we
can't agree on a common set.

Dealing with color correction could also be driver specific; once
the client has an overlay id it can use driver specific ioctls to
get/set specifics.

Jesse Barnes, Intel Open Source Technology Center

More information about the dri-devel mailing list