From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcus Lorentzon Subject: Re: [RFC] Updated plane support v3 Date: Tue, 21 Jun 2011 10:55:39 +0200 Message-ID: <4E005C8B.3030908@stericsson.com> References: <1308600701-7442-1-git-send-email-jbarnes@virtuousgeek.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1308600701-7442-1-git-send-email-jbarnes@virtuousgeek.org> 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: Jesse Barnes Cc: "intel-gfx@lists.freedesktop.org" , "dri-devel@lists.freedesktop.org" List-Id: dri-devel@lists.freedesktop.org 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. 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. /BR /Marcus