Yeah, there's no open source implementation of these right now, but essentially they just allow the source driver to do whatever specific setup necessary to present to either of the two supplied shared buffers from the same headsurface, as well as having presentation driven by PresentTrackedFlippingPixmap() as opposed to some sort of internal mechanism.
It would probably be possible to implement (Start/Stop)PixmapTracking such that multiple calls on the same mscreenpix with different shared pixmaps achieves that behavior, but it would be less explicit and would probably result in some unnecessary setup/teardown when switching to externally driven presentation on the second call. As of right now, I would expect multiple calls to StartPixmapTracking() with the same mscreenpix but different shared pixmaps to result in two independently driven shared pixmaps presenting from the same mscreenpix. I've been trying to avoid tampering with the semantics of the old paths as much as possible. Thanks, Alex On Tue, 8 Dec 2015, Michel Dänzer wrote: > On 26.11.2015 11:39, Alex Goins wrote: > > > > (Start/Stop)FlippingPixmapTracking are merely the double-buffered > > equivalents of (Start/Stop)PixmapTracking, allowing the source driver to do > > whatever setup and teardown necessary for presenting on the two shared > > pixmaps. > > AFAICT there's no implementation of these hooks in this series. Is it > really necessary (or even worth) adding these hooks instead of just > calling Start/StopPixmapTracking separately for the front and back pixmaps? > > > -- > Earthling Michel Dänzer | http://www.amd.com > Libre software enthusiast | Mesa and X developer >
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
