DRI2 Protocol Spec Draft

[Keith Packard]

On Tue, 2008-09-09 at 18:41 +0200, Michel Dänzer wrote:

> Sounds like the DRI1 authentication mechanism. :)

I don't know how DRI1 works... But, what I do want is a cookie of size
sufficient to avoid any potential for security compromise. 32 bits
doesn't seem like enough to me.

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

> Consider me convinced that it doesn't need to return any position
> information though.

Cool.

> Some GLX synchronization extensions provide information about whether a
> buffer swap hit or missed the target.

We could have the request return an error if the sequence target could
not be met.

> Rather driconf vblank_mode=3. Hmm, though that would also require
> DRI2CopyRegion not to execute the copy if the target was missed...

Returning an error would make this possible.

> Generally, if DRI2CopyRegion seriously wants to be useful for
> synchronization purposes, it probably needs to provide at least the same
> functionality as the DRM vblank related ioctls.

Certainly the combination of DRI2CopyRegion and DRM should be able to
provide sufficient synchronization. The question is what portion of this
task belongs in the extension and what portion belongs in the DRM kernel
API.

> Of course, for redirected windows it should really synchronize to the
> compositing manager rather than to the display hardware directly, but
> I'm not sure that matters at this point.

For redirected windows, the CopyRegion will not block, and the
compositing manager will get a Damage event when it occurs. At that
point, it's up to the compositing manager to 'do the right thing' to get
contents sync'd to the screen (presumably by using CopyRegion itself).

This has gotten me thinking that we've now made vblank syncing possible
for DRM applications but not for 'normal' applications. It seems like
we'd really like non-DRM (X-based) compositing managers to get the same
benefits here. I'd say we should add a vblank sync'd CopyArea to XFixes
at the same time?

-- 
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/03465cbf/attachment.pgp>