[PATCH 1/2] drm: add plane support v2

[Jesse Barnes]

On Tue, 15 Nov 2011 13:42:40 +0200
Ville Syrjälä <ville.syrjala at linux.intel.com> wrote:

> On Tue, Nov 15, 2011 at 12:40:43PM +1000, Ben Skeggs wrote:
> > On Mon, 2011-11-14 at 12:21 -0800, Jesse Barnes wrote:
> > > Planes 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.
> > Out of curiosity, lets say you have a *really* stupid hardware overlay
> > that can't do scaling (or even, has limited scaling capabilities),
> > should we provide some way to expose this to userspace?
> 
> I think yes. In fact I'd like drm_plane to replace drm_crtc as far as
> scanout is concerned. That's how a lot of embedded hardware is laid
> out already, and I think it's a lot cleaner approach than what we
> have currently. Stuff like borders then become a simple matter or
> positioning the "CRTC plane" within the larger active video area,
> and panel fitters could be exposed through drm_plane scaling.
> 
> Se either we need to think ahead more with the GETPLANE ioctl
> structure, or we could add a PLANE_CAPS ioctl later to expose
> additional details about the hardware.

There are going to be all sorts of device specific bits we can expose
with driver ioctls too (e.g. the alpha blend with restrictions on Intel
stuff).

But overall, yes you can definitely support overlays w/o scalers with
these interfaces.  We could add a plane property to expose the scaling
factors supported if that helps, otherwise you could just return
-ENOSUPP for any configuration where the crtc size and source size
don't match.

-- 
Jesse Barnes, Intel Open Source Technology Center
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20111115/1e3bf73e/attachment-0001.pgp>