Bug 961

Summary: Add workaround(s) for 'Mesa 8.0.5 X11 SWRAST' issues (glXGetFBConfigAttrib, glXMakeContextCurrent)
Product: [JogAmp] Jogl Reporter: Sven Gothel <sgothel>
Component: openglAssignee: Sven Gothel <sgothel>
Status: RESOLVED FIXED    
Severity: enhancement CC: fredrik
Priority: ---    
Version: 2   
Hardware: All   
OS: all   
Type: --- SCM Refs:
fdd60adb1d421f2018b47ee17e9079c94b54910f fdea8596b2ccc1221a980e4c9fd10de85d885a3c
Workaround: TRUE
Attachments: Shows glXGetFBConfigAttrib issue
Shows glXMakeContextCurrent issue

Description Sven Gothel 2014-02-06 14:32:57 CET 
Platform:

Debian 7.3

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,
	Factory   jogamp.opengl.x11.glx.X11GLXDrawableFactory@30384065,
	Handle    0xa00002,
	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 ]]
	at jogamp.opengl.x11.glx.X11GLXContext.createImpl(X11GLXContext.java:346)
Comment 2 Sven Gothel 2014-02-06 14:37:51 CET 
Created attachment 585 [details]
Shows glXGetFBConfigAttrib issue
Comment 3 Sven Gothel 2014-02-06 14:38:11 CET 
Created attachment 586 [details]
Shows glXMakeContextCurrent issue
Comment 4 Fredrik Tolf 2014-02-07 02:24:30 CET 
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.
Comment 5 Fredrik Tolf 2014-02-07 04:01:44 CET 
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?
Comment 6 Sven Gothel 2014-02-07 21:35:16 CET 
(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.

KUDOS

~Sven

PS: Keeping this open until I performed the patch.
Comment 7 Fredrik Tolf 2014-02-08 03:46:10 CET 
(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).
Comment 8 Sven Gothel 2014-03-10 22:15:51 CET 
Bug 961: Stabilize glXGetFBConfigAttrib(..) and glXChooseFBConfig(..) Usage Against OpenGL Bugs ; Fix glXGetFBConfigs

- glXChooseFBConfig(..)
  - Remove NULL FBConfig pointer from result in native code,
    which has been observed in Mesa 8.0.5-4 libgl1-mesa-swx11 (Debian-7).

- glXGetFBConfigs
  - Add manual implementation similar to glXChooseFBConfig

- glXGetFBConfigAttrib(..)
  - glXGetFBConfig(..)
     - Returns boolean reflecting success, don't throw exception - caller handles error
     - Caller ignore failure if not essential (i.e. already chosen config)
Comment 9 Sven Gothel 2014-03-11 02:59:15 CET 
fdea8596b2ccc1221a980e4c9fd10de85d885a3c

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