glXGetConfig fails: error code GLX_BAD_SCREEN??

OpenGL Development JOGL Development
#1

Anyone know what GLX_BAD_SCREEN means?

I had code running on an earlier version of JOGL (circa mid-November) - demos ran fine too. Seeing I was a bit behind in my builds, did a new checkout and build (linux.amd64). All went well. Have the new AWT object and X11 classes. I pointed my eclipse projects at the new .jar and the new native libs. Changed my canvas creation to new GLCanvas instead and of the factory methods. I now get the following error when trying to run demos or my own code (this was taken from a failed run of jogl-demo’s Gears.java):


Exception in thread "main" javax.media.opengl.GLException: glXGetConfig failed: error code GLX_BAD_SCREEN
	at com.sun.opengl.impl.x11.X11GLDrawableFactory.glXGetConfig(X11GLDrawableFactory.java:453)
	at com.sun.opengl.impl.x11.X11GLDrawableFactory.xvi2GLCapabilities(X11GLDrawableFactory.java:276)
	at com.sun.opengl.impl.x11.X11GLDrawableFactory.chooseGraphicsConfiguration(X11GLDrawableFactory.java:125)
	at javax.media.opengl.GLCanvas.<init>(GLCanvas.java:110)
	at javax.media.opengl.GLCanvas.<init>(GLCanvas.java:82)
	at javax.media.opengl.GLCanvas.<init>(GLCanvas.java:75)
	at demos.gears.Gears.main(Gears.java:19)

I can run JGears - sans the gears displaying. console output:

INIT GL IS: com.sun.opengl.impl.GLImpl
GL_VENDOR: NVIDIA Corporation
GL_RENDERER: GeForce 7800 GTX/PCI/SSE2
GL_VERSION: 2.0.1 NVIDIA 81.74
GL_VENDOR: NVIDIA Corporation
GL_RENDERER: GeForce 7800 GTX/PCI/SSE2
GL_VERSION: 2.0.1 NVIDIA 81.74

I’m running FC4 the nvidia card referenced above w/ sun’s jvm (build 1.5.0_05-b05).

Thanks in advance.
-william

#2

Have you ensured that all of the old copies of jogl.jar and the .so’s have been removed from your system?

I haven’t tested on AMD64 in a while and it’s possible the 64-bit code is broken. There were some changes to GlueGen in how it produces Java code which accesses 32/64-bit data structures and it is possible that something was broken in that restructuring.

Could you do a little debugging in this area and see whether obviously garbage values are being picked up and passed down into glXGetConfig? I don’t know whether it’s going to be easy to find a Linux/AMD64 machine around here with 64-bit Mesa binaries, etc.

#3

[quote]Have you ensured that all of the old copies of jogl.jar and the .so’s have been removed from your system?
[/quote]
yes. i’m pointing to the correct versions. Also rebuilt all this morning.

[quote]Could you do a little debugging in this area and see whether obviously garbage values are being picked up and passed down into glXGetConfig? I don’t know whether it’s going to be easy to find a Linux/AMD64 machine around here with 64-bit Mesa binaries, etc.
[/quote]
I spent some time today poking around trying to understand what is going on. i didn’t notice any obvious garbage values being passed, but then again i’m a n00b at GL so not sure what would constitute garbage outside of null objects, etc. The exception is thrown on the second iteration of the loop (X11GLDrawableFactory:125). The particulalr XVisualInfo object looks similar to one on the first iteration - just a different long address value in the ByteBuffer. The things that does seem odd to me is that the loop bound (infos.length) == 40…I don’t understand why there are so many GLCapabilities being created. (My hunch is that this loop is attempting to setup GLCapabilities per screen? if so, I’m not sure why GLX.XGetVisualInfo() is returning 40 (line 119), but I only have one display).

Not sure how to proceed at this point. Any direction you’d like me to head?

I hope this is helpful. If not, just point me somewhere.
-wb

note: FYI build.xml does not have javac tasks’ debuglevel set to include vars. I changed my local copy so I could trace all the way to the java native calls. curiosity: any particulalr reason (a bad one?) that the debug level was not set to include vars?

#4

The reason for the large number of GLCapabilities objects is that that code is trying to allow the GLCapabilitiesChooser to see all valid visuals for the screen so the end user could in theory choose one rather than leaving the choice to the window system.

Have you printed all of the fields of the XVisualInfo objects you’ve encountered?

[quote]note: FYI build.xml does not have javac tasks’ debuglevel set to include vars. I changed my local copy so I could trace all the way to the java native calls. curiosity: any particulalr reason (a bad one?) that the debug level was not set to include vars?
[/quote]
They take up a lot of space and the common case is that people aren’t debugging all the way into the JOGL code.

#5

Yes. The only difference I see between iteration 1 and 2 is inside Info’s ByteBuffer (the longaddress). Everything else is the same (including the viewedBuffer):
Iteration 1
Stack:
Thread [main] (Suspended)
X11GLDrawableFactory.glXGetConfig(long, XVisualInfo, int, int[], int) line: 452
X11GLDrawableFactory.xvi2GLCapabilities(long, XVisualInfo) line: 276
X11GLDrawableFactory.chooseGraphicsConfiguration(GLCapabilities, GLCapabilitiesChooser, AbstractGraphicsDevice) line: 125
GLCanvas.(GLCapabilities, GLCapabilitiesChooser, GLContext, GraphicsDevice) line: 110
Gears.main(String[]) line: 25

Variables:
long display= 46913894696480
XVisualInfo info= XVisualInfo64 (id=48)
StructAccessor accessor= StructAccessor (id=50)
ByteBuffer bb= DirectByteBuffer (id=53)
long address= 46913882628992
boolean bigEndian= false
int capacity= 40
Cleaner cleaner= null
byte[] hb= null
boolean isAMappedBuffer= false
boolean isReadOnly= false
int limit= 40
int mark= -1
boolean nativeByteOrder= true
int offset= 0
int position= 0
Object viewedBuffer= DirectByteBuffer (id=64)
long address= 46913882628992
boolean bigEndian= false
int capacity= 2560
Cleaner cleaner= null
byte[] hb= null
boolean isAMappedBuffer= false
boolean isReadOnly= false
int limit= 2560
int mark= -1
boolean nativeByteOrder= true
int offset= 0
int position= 0
Object viewedBuffer= null
CharBuffer cb= null
db= null
fb= null
IntBuffer ib= null
lb= null
sb= null
int attrib= 1
int[] tmp= int[1] (id=49)
int [0]= 1
int tmp_offset= 0
int res= 0

Iteration 2
Stack:
Thread [main] (Suspended)
X11GLDrawableFactory.glXGetConfig(long, XVisualInfo, int, int[], int) line: 452
X11GLDrawableFactory.xvi2GLCapabilities(long, XVisualInfo) line: 276
X11GLDrawableFactory.chooseGraphicsConfiguration(GLCapabilities, GLCapabilitiesChooser, AbstractGraphicsDevice) line: 125
GLCanvas.(GLCapabilities, GLCapabilitiesChooser, GLContext, GraphicsDevice) line: 110
Gears.main(String[]) line: 25

Variables:
long display= 46913894696480
XVisualInfo info= XVisualInfo64 (id=80)
StructAccessor accessor= StructAccessor (id=82)
ByteBuffer bb= DirectByteBuffer (id=83)
long address= 46913882629032
boolean bigEndian= false
int capacity= 40
Cleaner cleaner= null
byte[] hb= null
boolean isAMappedBuffer= false
boolean isReadOnly= false
int limit= 40
int mark= -1
boolean nativeByteOrder= true
int offset= 0
int position= 0
Object viewedBuffer= DirectByteBuffer (id=64)
long address= 46913882628992
boolean bigEndian= false
int capacity= 2560
Cleaner cleaner= null
byte[] hb= null
boolean isAMappedBuffer= false
boolean isReadOnly= false
int limit= 2560
int mark= -1
boolean nativeByteOrder= true
int offset= 0
int position= 0
Object viewedBuffer= null
CharBuffer cb= null
db= null
fb= null
IntBuffer ib= null
lb= null
sb= null
int attrib= 1
int[] tmp= int[1] (id=81)
int [0]= 0
int tmp_offset= 0
int res= 1

#6

Sorry, I wasn’t clear on what I was asking. The XVisualInfo class has several methods which correspond to the C fields of the underlying data structure. I was hoping to see the results of calling those methods for the various XVisualInfo objects rather than introspecting on the Java objects themselves.