From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jesse Barnes Subject: Re: [RFC] Updated plane support v3 Date: Tue, 21 Jun 2011 09:19:13 -0700 Message-ID: <20110621091913.0ad48875@jbarnes-desktop> References: <1308600701-7442-1-git-send-email-jbarnes@virtuousgeek.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org To: Rob Clark Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org On Tue, 21 Jun 2011 06:21:11 -0500 Rob Clark wrote: > On Mon, Jun 20, 2011 at 3:11 PM, Jesse Barnes 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