Fix xserver build

[Edgar Toernig]

Michel Dänzer wrote:
>
> GLX_EXT_tfp only works with indirect rendering with AIGLX, compiz
> actually has a command line switch --indirect-rendering for that.

That doesn't work.  Only LIBGL_ALWAYS_INDIRECT works.

Some code browsing reveals that the direct flag to glXCreateContext
(which implements compiz's or glxinfo's indirect option) is not
honoured when computing the effective extensions reported by
glXQueryExtensionsString.  So "glxinfo -i" or "compiz --indirect-
rendering" see no GLX_EXT_tfp.  It seems, the only way to see
GLX_EXT_tfp in the GLX-extension string is to set LIBGL_ALWAYS_INDIRECT=1.

I think (but I'm pretty new to OGL), the following check in x11/glxcmds.c

    __glXCalculateUsableExtensions(psc,
#ifdef GLX_DIRECT_RENDERING
            (psc->driScreen.private != NULL),
#else
            GL_FALSE,
#endif
            priv->minorVersion);
    }

needs an additional check whether direct rendering is actually
requested (2nd arg is direct_rendering flag).

But are apps really expected to query the GLX extensions for
each context individually?  If so, why doesn't the query function
has the context as an argument?  Looks like an API design
bug/flaw somehow ...


> On Tue, 2006-10-10 at 00:38 +0200, Edgar Toernig wrote:
> >
> > So, why is the GLX_EXT_texture_from_pixmap not working?
>
> It's related to the recent reorganization of the server GLX code. The
> current code is missing a dispatch entry for GetDrawableAttributesSGIX,
> so compiz doesn't know which texture target to use.
>
> What I'm not sure about yet is whether it's expected that the server
> gets a request for GetDrawableAttributesSGIX when compiz calls the
> result of glXGetProcAddressARB("glXQueryDrawable"). There might be an
> issue in libGL as well.
>
> It's all a little messy right now, but I understand Ian Romanick is
> planning to push some more changes soon which will hopefully clear
> things up. In the meantime, you could use the 1.1 branch or master from
> before commit d7a7f12361d31001bbd9394a57de029ef0b934b8.

Ok, thanks for the answer.  For the moment I stick to the current head
and check the tree from time to time for changes in that area.


Anyway, the hangs I mentioned in the original posting (using
indirect rendering, i.e. glxinfo -i) are still happening
occasionally.  So the timed scheduler wasn't the culprit.
Here's a backtrace in case somebody wants to dig into it:

[...]
#4  0xa7e355a9 in ioctl () from /lib/tls/libc.so.6
#5  0xa7fd4183 in drmGetLock (fd=8, context=8, flags=0) at xf86drm.c:1221
#6  0x9f82ba43 in r200GetLock (rmesa=0x9d9c188, flags=0) at r200_lock.c:87
#7  0x9f828ddd in r200GetBufferSize (buffer=0x9d95c00, width=0x0, height=0x0) at r200_context.c:98
#8  0x9f94b034 in _mesa_resizebuffers (ctx=0x9da5a58) at buffers.c:609
#9  0x9f85dacd in _mesa_make_current (newCtx=0x9da5a58, drawBuffer=0x9d95c00, readBuffer=0x9d95c00) at context.c:1717
#10 0x9f829b5e in r200MakeCurrent (driContextPriv=0x986da80, driDrawPriv=0x9d95b98, driReadPriv=0x0) at r200_context.c:704
#11 0x9f825dcc in DoBindContext (dpy=0x0, draw=12582914, read=12582914, ctx=0x0, modes=0x820da08, psp=0x821c790) at dri_util.c:343
#12 0x9f825e38 in driBindContext (dpy=0x0, scrn=0, draw=12582914, read=12582914, ctx=0x986da68) at dri_util.c:376
#13 0xa7ce5119 in __glXDRIcontextMakeCurrent (baseContext=0xaffff4f0) at glxdri.c:246
#14 0xa7cc3f06 in DoMakeCurrent (cl=0x83f1550, drawId=12582914, readId=12582914, contextId=12582915, tag=0) at glxcmds.c:649
#15 0xa7cc411f in __glXDisp_MakeCurrent (cl=0x83f1550, pc=0x0) at glxcmds.c:395
#16 0xa7cc5e48 in __glXDispatch (client=0x83f1080) at glxext.c:551
#17 0x08130a00 in XaceCatchExtProc (client=0x83f1080) at xace.c:299
#18 0x08084b29 in Dispatch () at dispatch.c:457
#19 0x0806e208 in main (argc=6, argv=0xaffffca4, envp=0xaffffcc0) at main.c:445

The ioctl is hanging.  It's interruptible but it doesn't
return by its own.  The command which produced this hang was
a simple "LIBGL_FORCE_INDIRECT=1 glxinfo".  Doesn't happen
always but often.

I'm not really sure, but as far as I can remember, with the
time scheduler the effect was a little bit different.  There,
there were two alternating ioctls (one on fd 7 and one on fd 8)
that actually returned but nothing else was happening
(except the SIGALRM).  Just an idea - is it possible that
the two fds (both on /dev/dri/card0) are both trying to
acquire the lock which results in a typical dead-lock (fd 7
already has the lock and fd 8 wants it too)?

Ciao, ET.