Created attachment 772 [details] raspbian_test_dbg_logs.tar.gz On 9th Feb 2016 Raspbian started to ship their system with two incompatible implementations of OpenGL ES installed at the same time. https://www.raspberrypi.org/blog/another-new-raspbian-release/ The two implementations are: * The Mesa3D OpenGL + ES driver for the desktop X11 that work with NEWT X11 located in /usr/lib/arm-linux-gnueabihf/libEGL.so.1 /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2 /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1 * The half-properitary Broadcom OpenGL ES driver using DispmanX that work with NEWT BCM VC IV located in /opt/vc/lib/libEGL.so /opt/vc/lib/libGLESv2.so /opt/vc/lib/libGLESv1_CM.so --- 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.
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. https://github.com/sgothel/jogl/pull/96/files 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.
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)
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.
commit 347271ffdd09153a2334fda593774d49050f84e0: Expand query whether BCM IV is being used, exclude '/dev/dri/card0' Also refactor query to jogamp.nativewindow.BcmVCArtifacts +++ I close this bug for now, since this seems to be all we can do for now. If you disagree and can provide a solution/idea how we can further this from our side, please reopen and add artifacts. Also: Please test, thx.
Sven: can you explain me what the check for "/dev/dri/card0" is meant to fix? Have you tested this on any Raspberry Pi with Raspbian? Note that we also carry this additional change, which was necessary starting from the Raspbian August '17 release: https://github.com/gohai/jogl/commit/c46af91059c6f2883a3db20b309a877e120dd9a0 I am unsure if your commit attempts to fix the same in a different way, or is unrelated. BTW: see here for the full list of changes on top of 2.3.2 Processing is currently shipping with: https://github.com/gohai/jogl/commits/bcm-test