Just for reference ..

+++

Yours (buggy:

GL Version     3.0 (Compat profile, arb, ES2 compat, FBO, hardware) - 3.0 Mesa 9.2.1 [GL 3.0.0, vendor 9.2.1 (Mesa 9.2.1)]
Quirks         [NoDoubleBufferedPBuffer, NoSetSwapIntervalPostRetarget]
Impl. class    jogamp.opengl.gl4.GL4bcImpl
GL_VENDOR      Intel Open Source Technology Center
GL_RENDERER    Mesa DRI Intel(R) Ivybridge Mobile
GL_VERSION     3.0 Mesa 9.2.1
GLSL           true, has-compiler-func: true, version: 1.30 / 1.30.0

+++

Mine (buggy as well):

GL Profile     GLProfile[GL2ES2/GL3.hw]
GL Version     3.1 (Core profile, arb, ES2 compat, ES3 compat, FBO, hardware) - 3.1 (Core Profile) Mesa 9.2.1 [GL 3.1.0, vendor 9.2.1 ((Core Profile) Mesa 9.2.1)]
Quirks         [NoDoubleBufferedPBuffer, NoSetSwapIntervalPostRetarget]
Impl. class    jogamp.opengl.gl4.GL4bcImpl
GL_VENDOR      Intel Open Source Technology Center
GL_RENDERER    Mesa DRI Intel(R) Sandybridge Desktop 
GL_VERSION     3.1 (Core Profile) Mesa 9.2.1
GLSL           true, has-compiler-func: true, version: 1.40 / 1.40.0

- Intel(R) Core(TM) i3-2105 CPU @ 3.10GHz
- HD3000 in CPU Sandybridge
- http://ark.intel.com/products/55448/Intel-Core-i3-2105-Processor-3M-Cache-3_10-GHz

- Ubuntu 13.10 (kernel 3.11.0-13-generic)
- mesa 9.2.1

+++
+++

Working w/ GL 3.1 and ES 3.0
  com.jogamp.opengl.test.junit.jogl.demos.es2.newt.TestGearsES2NEWT

Buggy:
  com.jogamp.opengl.test.junit.jogl.acore.TestSharedContextVBOES2NEWT1

  - 1st 'master' context works
  - 2nd 'slave' context does not work - sharing of 'master'!

Last message (as reported):
"intel_do_flush_locked failed: No such file or directory"

http://www.bentasker.co.uk/documentation/linux/157-intel-do-flush-locked-on-kubuntu-12

"What causes it

Basically, the call 'intel_do_flush_locked' isn't supported in earlier kernels (such as the one that ships with K/Ubuntu), so the system is trying to run a command that just doesn't exist (in simple terms)."

This is not the issue on my Ubuntu 13.10 setup I guess,
i.e. the kernel does expose the method/command.

http://dri.freedesktop.org/wiki/Intel/
https://01.org/linuxgraphics/
https://01.org/linuxgraphics/documentation/how-report-bugs-0

Bugs are already reported:
<https://bugs.freedesktop.org/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=&content=intel_do_flush_locked>

i.e.:

<https://bugs.freedesktop.org/show_bug.cgi?id=41736>

Especially comment of Eric Anholt (assignee):
  <https://bugs.freedesktop.org/show_bug.cgi?id=41736#c7>
"This app is doing context sharing between multiple xlib Displays, which is crazy.  We don't support that.  If we were to support that, we would need some even-more-global structure than the per-Display intel_screen in which to store things like the bufmgr."

This matches our test case w/ context sharing in TestSharedContextVBOES2NEWT1,
where we share w/ an explicit offscreen/dummy drawable/context w/ own Display device.

However, even TestSharedContextVBOES2NEWT3 doesn't work,
since NEWT's X11 WindowDriver does create it's own display connection
to decouple X11 display locking:
   /jogl/src/newt/classes/jogamp/newt/driver/x11/WindowDriver.java line 75 (renderDevice).

If this is the final stance of Intel, we have to either claim concurrent context sharing on X11
with Intel's Mesa backend is not supported - or add a sluggish 'same display connection' code-path.

Problem is the 'non-blocking' part. 
We don't use X11 locking, and lock on the application level, which is good.

However, we don't like to block GL rendering w/ windowing commands or input events
hence the extra display connection.
Such display connection shall also be exclusive to one context to not block 
another context - otherwise we would have not proper mult

For reference ..

<https://bugs.freedesktop.org/show_bug.cgi?id=41736#c8>:

Re comment 7: Eric, how else can one achieve non-blocking rendering w/ I/O,
if not using exclusive X11 display connections for multiple shared GL context and X11 events ?

Using one X11 display connection for the many shared context, one would need to add
synchronization for the X11 display commands, which is bogus.
For JOGL, we explicitly use exclusive display connections to achieve block-free multithreading.

We would love to see this fixed to enable shared GL context in a concurrent use-case,
since it is essential to many applications of our user base.

Note: The described mechanism works flawless on all other OpenGL driver implementations,
including other Mesa backends, as well with NV and AMD proprietary drivers.

Further more, the spec does not disclose such scenario, as long the display connection
references the 'same' display.

See: <https://jogamp.org/bugzilla/show_bug.cgi?id=873#c4>

Type: ANNOTATION, since this is not our bug.

But 776 is related, i.e. 'convenient context sharing'

(In reply to comment #7)
> But 776 is related, i.e. 'convenient context sharing'

Bug 776

As a (terrible) workaround if you really need a jogl-using application to work, you can force software rendering and hope for the best.

export LIBGL_ALWAYS_SOFTWARE=1
{start you application}

This has at least made jaamsim usable for some users, be warned that mesa swrast only supports up to OpenGL 2.1 at the moment.

Harvey