I just noticed, that the jogl nightly build from yesterday stopped working on the latest mustang weekly build (73) on linux. I have tested it on my notebook (Ubuntu/Gnome) and a friend couldn’t run it on his laptop (SUSE/KDE) either.
The small output is the same for both of us:
Beginning DRI hack
Ending DRI hack
and a bit later:
Xlib: unexpected async reply (sequence 0x149)!
where the hex-code can be different of course.
Anyone/Ken knows, what is behind of this?
Sounds like I broke the Xlib locking somewhere in the X11 port. What fails on your machine? Does the simple Gears demo provoke the failure or do you have a more complicated test case which is broken?
Hi Ken,
sorry for the late reply.
The demos.gears.Gears demo also fails to run (grey canvas) with the following output:
Beginning DRI hack
Ending DRI hack
INIT GL IS: com.sun.opengl.impl.GLImpl
Xlib: unexpected async reply (sequence 0xce)!
GL_VENDOR: NVIDIA Corporation
GL_RENDERER: Quadro FX Go1400/PCI/SSE2
GL_VERSION: 2.0.0 NVIDIA 76.67
btw. everything runs fine with java version “1.5.0_06”.
best regards,
micha
It turns out this is a regression in Mustang which has been present since build 53 but which didn’t become apparent until we made JOGL’s internal locking of the AWT less overly strict. I’ve filed bug 6394099 about this and hope that it will be fixed soon. Until then please work with 5.0u6 on X11 platforms. There is no possible workaround for this that can be done in JOGL.
Thanks for answering and filling the bug report 
I’m also seeing this on VIA UniChrome (KM400), when I run the latest snapshot I get a Gray Screen:
[bburns@localhost Desktop]$ java -classpath ./tmp/jogl.jar:jogl-demos.jar demos.gears.Gears
INIT GL IS: com.sun.opengl.impl.GLImpl
Xlib: unexpected async reply (sequence 0x13d)!
[bburns@localhost Desktop]$ java -version
java version “1.5.0_06”
Java™ 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)
Java HotSpot™ Client VM (build 1.5.0_06-b05, mixed mode, sharing)
The Feb. 17th release works (well it uses the indirect renderer, see my earlier message)
Any ideas?
–brendan
We recently made some changes to what X11-level locking JOGL does to support multi-screen X11 setups and it’s possible there are some lurking bugs, though the most recent problem above was actually a bug in the JDK. The same bug doesn’t exist in 5.0u6, though.
I’ll ask for some advice on exactly what locking is needed on X11 platforms. In the meantime, does Java3D work on your system? It would be helpful if you could download their 1.4 release and try compiling and running the HelloUniverse example.
When I try to run HelloUniverse I get the following (with LIBGL_DEBUG set to verbose)
libGL: XF86DRIGetClientDriverName: 4.1.0 unichrome (screen 0)
libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/unichrome_dri.so
libGL error: dlopen /usr/X11R6/lib/modules/dri/unichrome_dri.so failed (/usr/X11R6/lib/modules/dri/unichrome_dri.so: undefined symbol: _glapi_add_entrypoint)
libGL error: unable to find driver: unichrome_dri.so
Java 3D WARNING : reported GLX version = 1.2
GLX version 1.3 or higher is required
The reported version number may be incorrect. There is a known
ATI driver bug in glXQueryVersion that incorrectly reports the GLX
version as 1.2 when it really is 1.3, so Java 3D will attempt to
run anyway.
Java 3D WARNING : OpenGL 1.3 will be required in the near future (GL_VERSION=1.2)
and a window which simply displays a black screen.
Thanks!
–brendan
After speaking with one of the Java3D engineers I now understand why the new X11 locking code in JOGL is breaking with indirect contexts. To make Java3D work with an indirect rendering context you need to specify the system property j3d.renderLock to be true (-Dj3d.renderLock=true). I will check in changes to JOGL to autodetect this case and fall back to the necessary more strict locking.
fixed in mustang beta 2 build 77, great
Ive got the same issue, even with the latest jogl build- but only if I use my Laptop…
Any chances to get this working (Im not sure what the posting before means 
)?
EDIT: Just tried it with 1.6b2-77 - the same problem 
Could you try this test again tomorrow with a nightly build dated 3/27 or later (or build the JOGL sources from the CVS repository)? In particular, if the Xlib error is still reported, please try running with the system property -Djogl.GLContext.noopt specified and see if that changes the behavior. There is a bug in the implementation of this flag up to and including the 3/26 build currently on the JOGL home page.
It works with the build dated 3/27 
I didnt try it with the -Djogl… flag but I could if you want me to test it?!.
Well I tested it with the -Djogl.GLContext.noopt flag and it does also work- but its very slow (Im not sure if it is my system)?
EDIT: I checke my system an everything else seems to run properly- the jogl demos run also fast… the code itself cant cause the performance loss because on every other machine it runs fast as hell.
Well here are the specs:
Pentium M 1.4GHz
ATI Radeon mobility 9700 w 64MB VRAM
1GB Ram
Fedora Core 5
With the jogl demos or just your app? I don’t see any slowdown of the demos on my machine with that flag specified.
Sorry but this doesn’t mean the code can’t be causing the problem. Different drivers cope with OpenGL errors differently and it’s absolutely possible that your code is causing an OpenGL error to be generated which will cause the drivers to run incredibly slowly. Please try installing a DebugGL in your GLEventListener.init() method and see if it reports any errors.
ATI’s drivers, in particular their Linux drivers, have in my opinion been notoriously unreliable. I have a machine similar in configuration to yours except it has an NVidia Quadro FX Go700 and have had no reliability problems with it.
Sorry I expressed it a little bit wrong
It works with and without the -Djogl… flag But its very slow no matter if I use the -Djogl flag or not. Every other gl app seems to run fast on the same machine.
Ive had the same app( with nearly the same code) running excellent on the same machine. The only changes are the jogl version and (uhhm maybe a little big change) the OS (i upgraded from fedora 4 to 5). But as I stated above Im not sure if the cause is jogl- my new installation might also be messed up. One other thing is that it runs on every other Linux machine very good… and one of those machines was equipped with a radeon 9800 (with nearly the same poor drivers).
Btw, slow means less than 2 fps for a scene you shouldnt call scene (<1k polys).
But hey- thanks for your answers so far
It seems that the slowlyness is also if I use Windows with the same machine- it runs fast on every other machine. Could someone provide me a jogl version before Mar. 17th? This is the easiest way to check if its due to jogl.
my application is crashing with the latest nightly builds too
it is the first upgrade of jogl i did for two month or so
and during 3-4month i haven’t upgraded my system (you may be aware of a certain drivers problem with the latest versions of xorg)
i can’t figure out how to check my version of xlibs
my system is a debian, with an ati ( :’( ) 9600
please, tell my all the informations you need to know
also do you know the last ‘stable’ version regarding this issue ?
The problem is indeed jogl!!
If I use jsr beta 1 (jan 04) it runs like hell - any suggestions, anything I could check?
It seems to be a problem with mobility cards only?!