DRI2 Protocol Spec Draft

[Keith Packard]

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
level though.

> 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
sense.

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
this point.

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20080909/eb44fa9f/attachment.pgp>