From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jesse Barnes Subject: Re: [RFC] drm: add overlays as first class KMS objects Date: Mon, 25 Apr 2011 16:58:17 -0700 Message-ID: <20110425165817.60ad730d@jbarnes-desktop> References: <20110425151220.2f5dc17a@jbarnes-desktop> <20110425162216.529c126c@jbarnes-desktop> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from oproxy1-pub.bluehost.com (oproxy1-pub.bluehost.com [66.147.249.253]) by gabe.freedesktop.org (Postfix) with SMTP id AD1559E70A for ; Mon, 25 Apr 2011 16:58:20 -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: Keith Packard Cc: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org On Mon, 25 Apr 2011 16:37:46 -0700 Keith Packard wrote: > On Mon, 25 Apr 2011 16:22:16 -0700, Jesse Barnes wrote: > > > Yes, that matches my understanding as well. I've deliberately made the > > implementation flexible there though, under the assumption that some > > hardware allows a plane to be directed at more than one CRTC (though > > probably not simultaneously). > > So you create a scanout buffer and assign it to the appropriate slot in > the CRTC. Describing *how* the CRTC mixes pixels would be a good idea, > so the ordering of the slots might be relevant, and they might have a > blend mode (per-pixel alpha values, color key, separate alpha plane, etc). Yeah, pixel blending and z order should be exposed. I think that means returning more info in the get_overlay_res ioctl. Hm.. not sure of the best way of representing that... > > Arguably, this is something we should have done when the > > connector/encoder split was done (making planes in general first class > > objects). But with today's code, treating a CRTC as a pixel pump and a > > primary plane seems fine, with overlays tacked onto the side as > > secondary pixel sources but tied to a specific CRTC. > > I know of hardware that needs a lot more than one overlay... Yeah I don't want to preclude that (and I don't think this implementation does; it allows a many to one relationship between overlays and CRTCs). TVs in particular can get messy since the z order may be semi-fixed between certain planes, and blending may be limited to different types at different layers. -- Jesse Barnes, Intel Open Source Technology Center