Bug 1290 - Raspberry Pi Raspbian now ship with two incompatible implementations of OpenGL ES
Summary: Raspberry Pi Raspbian now ship with two incompatible implementations of OpenG...
Alias: None
Product: Jogl
Classification: JogAmp
Component: opengl (show other bugs)
Version: 2.4.0
Hardware: embedded_arm linux
: P4 normal
Assignee: Sven Gothel
Depends on:
Reported: 2016-02-17 17:12 CET by Xerxes Rånby
Modified: 2016-05-16 10:10 CEST (History)
1 user (show)

See Also:
SCM Refs:
Workaround: ---

raspbian_test_dbg_logs.tar.gz (34.80 KB, application/gzip)
2016-02-17 17:12 CET, Xerxes Rånby

Note You need to log in before you can comment on or make changes to this bug.
Description Xerxes Rånby 2016-02-17 17:12:23 CET
Created attachment 772 [details]

On 9th Feb 2016
Raspbian started to ship their system with two incompatible implementations of OpenGL ES installed at the same time.

The two implementations are:

* The Mesa3D OpenGL + ES driver for the desktop X11
that work with NEWT X11 located in

* The half-properitary Broadcom OpenGL ES driver using DispmanX 
that work with NEWT BCM VC IV located in

On a default Raspbian install the combination of having these two driver implementations installed at the same time will cause JogAmp JOGL 2.3.2 NEWT fail to initialize.

The attached debug logs demonstrate the issues seen when initializing from console and from inside X11:

X11 fails to initialize:
JNILibLoaderBase: loaded newt
java: symbol lookup error: /tmp/jogamp_0000/file_cache/jln6263276898817730441/jln7182988621672879444/natives/linux-armv6hf/libnewt.so: undefined symbol: bcm_host_init

This is caused by JOGL trying to use Mesa3D in combination with the NEWT BCM VC IV driver.

console fails to initialize:
Exception in thread "main" com.jogamp.opengl.GLException: Profile GL_DEFAULT is not available on EGLGraphicsDevice[type .egl, v0.0.0, connection decon, unitID 0, handle 0x0, owner true, NullToolkitLock[obj 0x140d5f0]], but: []
	at com.jogamp.opengl.GLProfile.get(GLProfile.java:991)
	at com.jogamp.opengl.GLProfile.getDefault(GLProfile.java:722)
	at com.jogamp.opengl.GLProfile.getDefault(GLProfile.java:733)
	at com.jogamp.newt.opengl.GLWindow.main(GLWindow.java:1075)

This is caused by JOGL trying to use Mesa3D that do not work on console.


A workaround is to remove one of the two implementations from the system.
Comment 1 Xerxes Rånby 2016-02-17 17:26:51 CET
gohai have posted a partial fix that makes JOGL skip use of the NEWT BCM VC IV driver if it detects that the users have enabled the VC4 kernel module that is required to when using the hardware accelerated X11 Mesa3D driver. 

With this fix installed then X11 do work when the user have enabled the new vc4 kernel driver, to be used with the Mesa3D X11 driver in raspi-config.
JogAmp will then not try to use the half-properitary Broadcom OpenGL ES driver using DispmanX when the vc4 kernel module is detected.
Comment 2 Gottfried Haider 2016-02-18 09:57:29 CET
I tried to learn from the Raspberry Pi foundation if/how they're going to change their current behavior, as it seems to break user-space applications like JOGL or GStreamer.

I haven't heard anything definitive so far, but they are aware.

Eric Anholt: "If they're leaving both libGLESv2s in the link path, we're in trouble. Back when I was working with them in October, we'd talked a boot script moving the libraries such that only one could be found." (https://github.com/anholt/mesa/issues/24#issuecomment-184451181)
Comment 3 Gottfried Haider 2016-05-16 10:10:47 CEST
Unfortunately, there hasn't been any progress in fixing this issue on the side of Raspbian. The most recent distribution release still exhibits the same issue.

I was wondering whether the following workaround in JOGL would be feasible or acceptable also:

If the file /opt/vc/lib/libbcm_host.so exists, and the directory /sys/module/vc4 does not exist, then attempt to load libGLESv2.so before libGLESv2.so.2.