libgl1-mesa-swx11:amd64 8.0.5-4+deb7u2 amd64
libglu1-mesa:amd64 8.0.5-4+deb7u2 amd64
libosmesa6:amd64 8.0.5-4+deb7u2 amd64
mesa-common-dev 8.0.5-4+deb7u2 amd64
mesa-utils 8.0.1-2+b3 amd64
GL_RENDERER = Mesa X11
GL_VERSION = 2.1 Mesa 8.0.5
GL_VENDOR = Brian Paul
Issue #1: glXGetFBConfigAttrib returns array of pointers with NULL in it
On 02/06/2014 12:16 PM, Dolda2000 [via jogamp] wrote:> In continuation on that
gdb attempt, it seems that, in this case,
> glXGetConfigAttrib dispatches to "Fake_glXGetFBConfigAttrib" in
> src/mesa/drivers/x11/fakeglx.c, which indeed returns -1 on having a NULL
> config passed in:
> if (!dpy || !config || !value)
> return -1;
> I just wanted to mention it, since it is congruent with the Exception message
> saying "Unknown error code -1".
On 02/06/2014 12:42 PM, Dolda2000 [via jogamp] wrote:
> Actually, I'm now inclined to ascribe this problem to some kind of bug in
> Mesa. I traced it back to glXChooseFBConfig, and Mesa actually seems to return
> a list with NULLs in it:
Issue #2: glXMakeContextCurrent fails with drawable write and read handles
glXMakeContextCurrent(display, drawable.getHandle(), drawableRead.getHandle(), temp_ctx)
Caused by: javax.media.opengl.GLException: main-SharedResourceRunner: Error making temp context(1) current: display 0x10454e0, context 0x10542a0, drawable X11OnscreenGLXDrawable[Realized true,
Surface WrappedSurface[ displayHandle 0x10454e0
, surfaceHandle 0xa00002
, size 64x64
, UOB[ OWNS_SURFACE | WINDOW_INVISIBLE ]
, X11GLXGraphicsConfiguration[X11GraphicsScreen[X11GraphicsDevice[type .x11, connection :6, unitID 0, handle 0x10454e0, owner true, ResourceToolkitLock[obj 0x1ebcda2d, isOwner true, <66100363, 254e8cee>[count 2, qsz 0, owner <main-SharedResourceRunner>]]], idx 0], visualID 0x22, fbConfigID 0x22,
requested GLCaps[rgba 8/8/8/0, opaque, accum-rgba 0/0/0/0, dp/st/ms 16/0/0, dbl, mono , hw, GLProfile[GL2/GL2.sw], on-scr[.]],
chosen GLCaps[glx vid 0x22, fbc 0x22: rgba 2/3/3/0, opaque, accum-rgba 16/16/16/16, dp/st/ms 16/8/0, dbl, mono , hw, GLProfile[GL2/GL2.sw], on-scr[.]]]
, surfaceLock <2f8a49e0, 1ff82982>[count 1, qsz 0, owner <main-SharedResourceRunner>]
, X11DummyUpstreamSurfaceHook[ 64x64]
, upstreamSurface false ]]
See forum discussion:
Created attachment 585 [details]
Shows glXGetFBConfigAttrib issue
Created attachment 586 [details]
Shows glXMakeContextCurrent issue
From the forum discussion:
> We surely have a problem, the returned FBConfigs are not >= 15 bits-per-pixel.
> I am surprised that it even went this far, sine we require an RGB[A] surface .. hmm.
If you refer to the color configuration being those weird 2/3/3/0 or 3/3/2/0 quadruplets, then I agree that that is strange. However, the mesa-swx11 on Debian 6.0, which works perfectly well, also reports those visuals. Moreover, when I actually render on that system, it does work perfectly well, and the results definitely seem to be 8/8/8/8. Alpha works and everything.
I can't say I know what is up with that; I didn't notice until now that I examined the visuals on the Debian 6.0 system in connection with this discussion.
Actually, it does appear that Xvfb only supports 8-bit visuals in its default configuration. When configured to 24-bit support (with the -screen option), JOGL started working on it.
I don't know why it worked on Debian 6.0, however, seeing as I had always started Xvfb unconfigured there, and the version of Xvfb on Debian 6.0 had the same default configuration. I can only assume that mesa-swx11 uses 32-bit buffers internally regardless of the X or GLX visual, but that doesn't quite seem to explain why JOGL worked on one but not the other.
With this discovery, my problems are solved and mesa-swx11 works perfectly again. To summarize then, what I needed to do was to:
1) Fix the glXGetFBConfigs bug in Mesa (this is reported to Debian in BTS #737841); and
2) Set up Xvfb to use a 24-bit screen, using its -screen option.
Are any of these issues anything you want to do something about in JOGL, and, if so, is there anything I can do to help?
(In reply to comment #5)
> Actually, it does appear that Xvfb only supports 8-bit visuals in its
> default configuration. When configured to 24-bit support (with the -screen
> option), JOGL started working on it.
> I don't know why it worked on Debian 6.0, however, seeing as I had always
> started Xvfb unconfigured there, and the version of Xvfb on Debian 6.0 had
> the same default configuration. I can only assume that mesa-swx11 uses
> 32-bit buffers internally regardless of the X or GLX visual, but that
> doesn't quite seem to explain why JOGL worked on one but not the other.
> With this discovery, my problems are solved and mesa-swx11 works perfectly
> again. To summarize then, what I needed to do was to:
> 1) Fix the glXGetFBConfigs bug in Mesa (this is reported to Debian in BTS
> #737841); and
> 2) Set up Xvfb to use a 24-bit screen, using its -screen option.
> Are any of these issues anything you want to do something about in JOGL,
> and, if so, is there anything I can do to help?
Thank you so much for your high quality report and cooperation Fredrik!
I guess I will at least add a patch to handle the NULL FBConfig in the array list,
otherwise there is nothing we can do.
Great to have learned about this configuration
- another success of choosing free software, would not be possible to
have walked this path w/o it.
PS: Keeping this open until I performed the patch.
(In reply to comment #6)
> I guess I will at least add a patch to handle the NULL FBConfig in the array list
Just as a thought, it might be better to check the return value of glXGetFBConfigAttrib and skip modes with error returns (instead of aborting the whole thing), instead of removing NULLs from the list. That could possibly cover other kinds of driver bugs as well, in the case a driver returns some invalid mode (that is not necessarily NULL).
Bug 961: Stabilize glXGetFBConfigAttrib(..) and glXChooseFBConfig(..) Usage Against OpenGL Bugs ; Fix glXGetFBConfigs
- Remove NULL FBConfig pointer from result in native code,
which has been observed in Mesa 8.0.5-4 libgl1-mesa-swx11 (Debian-7).
- Add manual implementation similar to glXChooseFBConfig
- Returns boolean reflecting success, don't throw exception - caller handles error
- Caller ignore failure if not essential (i.e. already chosen config)
Fix commit fdd60adb1d421f2018b47ee17e9079c94b54910f (memmove byte-count)
memmove's byte-count was just giving the element-count,
missing the element-size multiplier to actually pass byte-count