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@xxxxxxxxxxxxxxxx> 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. -- Ville Syrjälä syrjala@xxxxxx http://www.sci.fi/~syrjala/ _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
