From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= Subject: Re: [RFC] drm: add overlays as first class KMS objects Date: Thu, 28 Apr 2011 20:54:32 +0300 Message-ID: <20110428175432.GC3093@sci.fi> References: <20110425151220.2f5dc17a@jbarnes-desktop> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Received: from filtteri2.pp.htv.fi (filtteri2.pp.htv.fi [213.243.153.185]) by gabe.freedesktop.org (Postfix) with ESMTP id 167059E747 for ; Thu, 28 Apr 2011 10:54:45 -0700 (PDT) Content-Disposition: inline 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 Thu, Apr 28, 2011 at 12:03:32PM -0500, Rob Clark wrote: > On Mon, Apr 25, 2011 at 5:12 PM, Jesse Barnes = wrote: > > Looking for comments on this. =A0Obviously if we're going to add a new = type > > of KMS object, we'd better get the ioctl more or less right to begin wi= th, > > which means having all the attributes we'd like to track, plus some > > padding, available from the outset. > > > > So I'd like comments on this; the whole approach may be broken for thin= gs > > like OMAP; if so I'd like to hear about it now. =A0Overall, overlays are > > treated a little like CRTCs, but without associated modes our encoder > > trees hanging off of them. =A0That is, they can be enabled with a speci= fic > > fb attached at a specific location, but they don't have to worry about > > mode setting, per se (though they do need to have an associated CRTC to > > actually pump their pixels out, post-blend). > > > > Flipping could be done either with the existing ioctl by updating the fb > > base pointer, or through a new flip ioctl similar to what we have alrea= dy, > > but taking an overlay object instead of a CRTC. > = > One thing I am wondering about is how to synchronize overlay position > w/ flipping in the primary gfx layer? Assuming you actually are > flipping in primary layer you'd want a new set of overlay > position/size to take effect on the same vblank that the flip in the > gfx layer happens, because you are probably relying on some > transparent pixels (or colorkey, if anyone still uses that) to be > drawn in the UI layer. That's a good reason to aim for an OpenWF Display type of API where you can commit the whole device state atomically. -- = Ville Syrj=E4l=E4 syrjala@sci.fi http://www.sci.fi/~syrjala/