This problem was initially reported to the mesa-dev mailing list, see http://sourceforge.net/mailarchive/forum.php?thread_id=7498802&forum_id=5154. It seems like there's some issue with GLXGetVisualConfigs when used with Solaris and IRIX OpenGL clients. It might be a compatibility problem or a byte order issue: With Mesa 6.X, if I run "glxinfo -v" locally (on a plain FC3 machine), all my visuals are of render type RGBA. Example: Visual ID: 32 depth=24 class=DirectColor bufferSize=24 level=0 renderType=rgba doubleBuffer=0 stereo=0 rgba: redSize=8 greenSize=8 blueSize=8 alphaSize=0 auxBuffers=0 depthSize=24 stencilSize=8 accum: redSize=16 greenSize=16 blueSize=16 alphaSize=0 multiSample=0 multiSampleBuffers=0 visualCaveat=Slow Opaque. However, if I run glxinfo (or xglinfo) on a remote machine with a different byte order, it claims that the render type is COLOR INDEX. On a Solaris 8 machine, running /usr/openwin/demo/GL/xglinfo gives: DirectColor visual: ID = 0x32 (hex) 50 (decimal), screen = 0, gamma = 2.22 SINGLE buffered MONO COLOR INDEX visual with (Z Stencil) GL Sizes: ColorIndex=24, Z=24, Stencil=8 number of sample buffers=0, samples per pixel =0 ERROR: CI visual, but RGB has non-zero sizes (8,8,8) ERROR: CI visual, but Accum has non-zero sizes (16,16,16,0) Core X: depth=24, colormapSize=256 RGB: masks=(0xff0000,0xff00,0xff) bits=8 Note the "COLOR INDEX" output. Also, when using "+printRawVisualInfo", it says "rgba=0". When running "glxinfo" on a IRIX 6.5 machine, still using the same display, the output is: visual x bf lv rg d st r g b a ax dp st accum buffs ms id dep cl sp sz l ci b ro sz sz sz sz bf th cl r g b a ns b ----------------------------------------------------------------- -1 -1 ?? . 16 . c y . 5 6 5 . . 16 . . . . . . . -1 -1 ?? . 16 . c y . 5 6 5 . . 16 8 16 16 16 . . . -1 -1 ?? . 24 . c y . 5 6 5 8 . 16 8 16 16 16 16 . . -1 -1 ?? . 24 . c . . 5 6 5 8 . 16 8 16 16 16 16 . . -1 -1 ?? . 16 . c y . 5 6 5 . . 16 . . . . . . . -1 -1 ?? . 16 . c y . 5 6 5 . . 16 8 16 16 16 . . . -1 -1 ?? . 24 . c y . 5 6 5 8 . 16 8 16 16 16 16 . . -1 -1 ?? . 24 . c . . 5 6 5 8 . 16 8 16 16 16 16 . . The problem seems limited to Mesa 6.X, and it seems to be a Xserver-side issue. I"ve tested some different versions: XFree86 4.3.0, Mesa DRI G400, Mesa 4.0.4: Works Xorg 6.7.0, Mesa GLX Indirect, Mesa 5.0.2: Works xf4vnc 4.3.0.999: Mesa GLX Indirect, 5.0.2: Works Xorg 6.8.2, Mesa DRI G400, Mesa 6.2.1: Fails xf4vnc cvs: Mesa GLX Indirect, 6.2.1: Fails If I disable the GLX_SGIX_fbconfig extension (by editing glxscreens.c), the problem disappears.
I want to make sure that I have a complete understanding of what's happening here. Is glxinfo being run on the Solaris / IRIX system with DISPLAY pointing to the Linux system? If that's the case, I think this problem may be caused by the same thing as bug #3210. A fix for that bug has been committed to Xorg CVS. Could you see if you can reproduce this with Xorg CVS?
>Is glxinfo being run on the Solaris / IRIX system with DISPLAY pointing >to the Linux system? Yes. >If that's the case, I think this problem may be caused by the same thing as bug >#3210. A fix for that bug has been committed to Xorg CVS. Could you see if you >can reproduce this with Xorg CVS? Yes, will try.
>>If that's the case, I think this problem may be caused by the same thing as bug >>#3210. A fix for that bug has been committed to Xorg CVS. Could you see if you >>can reproduce this with Xorg CVS? > >Yes, will try. The problem occurs even with the latest Xorg CVS.
This bug should be fixed by this patch posted to the xorg-devel mailing list. http://lists.x.org/archives/xorg-devel/2009-December/003955.html I'll close this bug as soon as the patch lands in the tree.
(In reply to comment #4) > This bug should be fixed by this patch posted to the xorg-devel mailing list. > > http://lists.x.org/archives/xorg-devel/2009-December/003955.html > > I'll close this bug as soon as the patch lands in the tree. The patch has landed, time to close?
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.