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:13:02 -0700 Message-ID: <20110621091302.08031ae7@jbarnes-desktop> References: <1308600701-7442-1-git-send-email-jbarnes@virtuousgeek.org> <4E005C8B.3030908@stericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from oproxy5-pub.bluehost.com (oproxy5-pub.bluehost.com [67.222.38.55]) by gabe.freedesktop.org (Postfix) with SMTP id D6DBB9F5D2 for ; Tue, 21 Jun 2011 09:13:09 -0700 (PDT) In-Reply-To: <4E005C8B.3030908@stericsson.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: Marcus Lorentzon Cc: "intel-gfx@lists.freedesktop.org" , Alan@freedesktop.org, "dri-devel@lists.freedesktop.org" List-Id: dri-devel@lists.freedesktop.org On Tue, 21 Jun 2011 10:55:39 +0200 Marcus Lorentzon wrote: > On 06/20/2011 10: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). > > > > Thanks, > > Jesse > > > > > Is it possible to position a plane above and below the "normal" crtc > framebuffer? Plane z-order is unsigned, and I would assume 0 is default > z-order. > Applications will need to position planes above and below crtc normal > framebuffer. Below when using a translucent or color keyed framebuffer, > and above if framebuffer is opaque. I was thinking 0 would be the bottom layer. But either way we don't have a way of getting the primary plane z position atm, so it'll be hard to position a new plane above or below the main plane... I'm ok with a signed value here, but the real meaning will be defined by a new ioctl we use to get plane blending restrictions, z order, and such. > So maybe add a one liner comment about z-order meaning and make it > signed unless ordering should be solved in another way. > > And should it be possible to only define planes with no crtc framebuffer > at all? Use case, for example letter boxed video on black background > with small UI controls/subtitles. In this case it's not power efficient > to have a fullscreen fb with mostly if not all transparent pixels. A particular driver may be able to expose that somehow, maybe by allowing clients to define a special fb handle that can be used to indicate no plane should be bound to the CRTC as the "primary" plane. -- Jesse Barnes, Intel Open Source Technology Center