[Mesa-dev] [PATCH] glx: block attempt to swapbuffer on pixmap. (v2)

[Adam Jackson]

On Mon, 2011-12-19 at 16:45 +0100, Michel Dänzer wrote:
> On Mon, 2011-12-19 at 10:14 -0500, Adam Jackson wrote: 
>
> > The server is the only thing that knows how to handle this scenario, and
> > it _can_ get this request, so you have to fix it there anyway.
> 
> Actually no, the DRI2 code in the server can't know, as this is a
> perfectly legitimate request for a GLXPbuffer.

Only as an artifact of how we implement pbuffers (which is,
stylistically, a disaster).  And even then I don't think that's true,
just that the implementation would be unpleasant.  xserver gets
DRI2SwapBuffers on an XID for an X pixmap.  It can either be backing a
GLXPixmap or a GLXPbuffer, but not both*.  Therefore DRI2 needs to wrap
the glx drawable create path in the server, and stash a note on the
PixmapRec private for the GLXPixmap and GLXPbuffer cases.  That way
SwapBuffers has type information without needing to walk all GLXPixmaps
looking for an XID match with the backing pixmap.

This works because Pixmaps have to be created before GLXPixmaps, but the
backing pixmap for a pbuffer is created after the pbuffer.  So
technically that * above is a lie.  We create the backing pixmap for the
pbuffer inside xlib, and we don't leak that XID outside libGL, but the
client could guess.  The failure cases would be:

a) create pbuffer, guess Pixmap XID, bind a GLXPixmap to it
b) create Pixmap, create GLXPixmap, fabricate your own protocol for
CreatePbuffer and DRI2CreateDrawable to bind to the Pixmap

Both of which are detectable, because they involve calling
DRI2CreateDrawable a second time after you've already inferred type.

Or, better yet, if DRI2 insists on keeping the current weird 'alias'
semantics for DRI2CreateDrawable, it could alias based on the GLX
resource ID.  This would mean moving the creation of the backing pixmap
for pbuffers inside the server, but honestly that's a lot cleaner
anyway.  Among other things, there'd be no possibility of leaking an XID
to the client for the backing resource.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20111219/404f61c5/attachment.pgp>