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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 25 Apr 2011 20:28:20 -0400
Alex Deucher <alexdeucher@xxxxxxxxx> wrote:

> On Mon, Apr 25, 2011 at 7:22 PM, Jesse Barnes <jbarnes@xxxxxxxxxxxxxxxx> wrote:
> > On Mon, 25 Apr 2011 16:16:18 -0700
> > Keith Packard <keithp@xxxxxxxxxx> wrote:
> >
> >> On Mon, 25 Apr 2011 15:12:20 -0700, Jesse Barnes <jbarnes@xxxxxxxxxxxxxxxx> 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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel



[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux