On Mon, 25 Apr 2011 16:37:46 -0700 Keith Packard keithp@keithp.com wrote:
On Mon, 25 Apr 2011 16:22:16 -0700, Jesse Barnes jbarnes@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).
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.