Re: [RFC] Updated plane support v3

From: Jesse Barnes <jbarnes@virtuousgeek.org>
To: Rob Clark <robdclark@gmail.com>
Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [RFC] Updated plane support v3
Date: Tue, 21 Jun 2011 09:19:13 -0700	[thread overview]
Message-ID: <20110621091913.0ad48875@jbarnes-desktop> (raw)
In-Reply-To: <BANLkTim4ecynzwm-vu9hSwppXBqHSP4D=w@mail.gmail.com>

On Tue, 21 Jun 2011 06:21:11 -0500
Rob Clark <robdclark@gmail.com> wrote:

> On Mon, Jun 20, 2011 at 3:11 PM, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> > This version adds both source and dest rect params to the set_plane
> > ioctl, and makes the source fixed point to support hardware that needs
> > it.
> >
> > I haven't changed the name of the SNB implementation yet (per Chris's
> > suggestions) but will before it gets upstream.
> >
> > I'd be interested to see whether these interfaces will work for other
> > hardware, so please take a close look at them and ideally implement them
> > on your hardware to make sure (see my userspace example code from
> > earlier posts if you want something to crib from).
> 
> Cool, thanks for this
> 
> I'm just thinking through how I'd implement the driver part in omap
> drm driver.. so please bear with me if I'm misunderstanding..
> 
> In particular I'm thinking about being able to use a given video pipe
> (basically like a dma channel) as either framebuffer layer or overlay
> at various points in time, depending on how many displays are
> attached.  Is the idea to use drm_plane *only* for overlay layer, and
> still use crtc->fb for the normal framebuffer layer?

Given the structure of the current KMS API, a CRTC implies a plane of
some sort, but I don't think the driver is restricted to using the same
plane for a given CRTC forever; it could allocate and switch them
around depending on usage, with planes beyond what's currently
associated with the CRTC exposed through this interface.

> I was thinking perhaps that if we let userspace DRM_IOCTL_MODE_SETCRTC
> pass in -1 for fb_id, followed by one or more
> DRM_IOCTL_MODE_SETPLANE's, to set things up the "new" way (explicitly
> specify the drm_plane's).  Or if _SETCRTC passes in a valid fb_id, we
> know it is the old way, and driver automatically picks a drm_plane.

Yeah that might work; we'd probably want a new GETPARAM flag to
indicate support for this...  The tough part is doing it in such a way
that we don't break existing userspace.

-- 
Jesse Barnes, Intel Open Source Technology Center