From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcus Lorentzon Subject: Re: [RFC] Updated plane support v3 Date: Wed, 22 Jun 2011 11:16:29 +0200 Message-ID: <4E01B2ED.3070406@stericsson.com> References: <1308600701-7442-1-git-send-email-jbarnes@virtuousgeek.org> <20110621091913.0ad48875@jbarnes-desktop> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from eu1sys200aog106.obsmtp.com (eu1sys200aog106.obsmtp.com [207.126.144.121]) by gabe.freedesktop.org (Postfix) with ESMTP id 20D269E73F for ; Wed, 22 Jun 2011 02:16:55 -0700 (PDT) In-Reply-To: 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: Rob Clark Cc: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org On 06/22/2011 03:09 AM, Rob Clark wrote: > But I'm at least under the impression that some of the other SoC's > have similar flexibility to use video planes as either primary or > overlay layers. So I figure it is at least worth trying to handle > this in a more generic way if it doesn't cause too much ugliness to > KMS core. > Yes, our DSS have similar flexibility. That is, we don't have a special fullscreen framebuffer for the crtc. Instead we have generic "overlays" for all framebuffers that can be positioned anywhere and have any format, all on a background color of choice. So we are happy with a more generic approach where current implementation use a default plane for crtc fb. But it should not hog HW resources when not used. If a plane is used, I think it should be a "normal" plane that the user can control and enumerate. /BR /Marcus