DRI2 Protocol Spec Draft
keithp at keithp.com
Tue Sep 9 10:51:58 PDT 2008
On Tue, 2008-09-09 at 19:34 +0200, Michel Dänzer wrote:
> On Tue, 2008-09-09 at 10:11 -0700, Keith Packard wrote:
> > On Tue, 2008-09-09 at 18:41 +0200, Michel Dänzer wrote:
> > > GLX_EXT_texture_from_pixmap needs the real front buffer.
> > Sure, but that's not through DRI2, this just references the object as an
> > X pixmap.
> I don't understand what you mean. How would a direct rendering,
> zero-copy implementation of GLX_EXT_texture_from_pixmap work without
> getting the pixmap buffer ID via DRI2GetBuffers?
I assumed that GLX would do this part of the protocol, not DRI2;
probably just a misunderstanding of how this all works at a protocol
> So in order to find out the effective sequence number, the client would
> need to keep incrementing the target number and check for the error?
> Doesn't sound very appealing to me.
Yeah, the protocol doesn't exactly provide any way of knowing what the
current vblank sequence number is.
> Not to mention X protocol errors tend to be a PITA.
In what way?
> That mechanism could be basically the same as the existing
> sync-to-vblank mechanisms, but with 'vertical blank' replaced by
> 'compositing manager screen update'. So it would provide the client with
> a way to express the display frame at which the buffer swap should take
> effect and to synchronize to the compositing manager making it so.
We chatted about this and Kristian suggested that we would throttle the
app to vblank rate, rather than compositing manager rate. On second
thought, perhaps driving this from the compositing manager would make
Somehow we'd have to connect compositing manager operations to specific
client actions though; I'm not sure we've got protocol to do that at
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: This is a digitally signed message part
More information about the xorg