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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev