On Mon, 25 Apr 2011 16:22:16 -0700, Jesse Barnes <jbarnes at virtuousgeek.org> 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). > 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... -- keith.packard at intel.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20110425/3949a82c/attachment.pgp>
