On Thu, Apr 28, 2011 at 12:03:32PM -0500, Rob Clark wrote:
On Mon, Apr 25, 2011 at 5:12 PM, Jesse Barnes jbarnes@virtuousgeek.org wrote:
Looking for comments on this. Obviously if we're going to add a new type of KMS object, we'd better get the ioctl more or less right to begin with, 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 things like OMAP; if so I'd like to hear about it now. Overall, overlays are treated a little like CRTCs, but without associated modes our encoder trees hanging off of them. That is, they can be enabled with a specific 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 already, 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.