Raspberry Pi + Processing + P3D + JOGL

Hi.

I'm trying to get a P3D Processing sketch running on the Raspberry Pi and, having done quite a bit of research, it seems that I need to use JOGL for this, but, having followed Xerxes Ranby's instructions, I'm merely getting a transparent Processing window and the errors below.

I am using the 32 bit linux version of Processing.
Java -version is 1.7.0-40

Looking in core/library, gluegen-rt-android-natives-linux-armv6hf.jar is missing, but the following similarly named files are present:

gluegen-rt-natives-android-armv6.jar
gluegen-rt-natives-linux-armv6.jar
gluegen-rt-natives-linux-armv6hf.jar

I also have a question regarding NEWT, as I have read that I need to force Processing to use NEWT as opposed to AWT. Does JOGL take care of this or is there more that I need to do here?

I'm brand new to JOGL and by no means a programmer, so any guidance greatly appreciated. I hope that I have provided sufficient information for you to understand my problem.

Thanks,

B.

<code>
pi@raspberrypi ~ $ cd processing-2.1
pi@raspberrypi ~/processing-2.1 $ ./processing
pi@raspberrypi ~/processing-2.1 $ See https://github.com/processing/processing/issues/2010
See https://github.com/processing/processing/issues/2010
Exception in thread "Animation Thread" java.lang.RuntimeException: Pixel operations are not supported on this device.
        at processing.core.PGraphicsJava2D.getRaster(PGraphicsJava2D.java:2345)
        at processing.core.PGraphicsJava2D.loadPixels(PGraphicsJava2D.java:2357)
        at processing.core.PApplet.loadPixels(PApplet.java:11085)
        at processing.app.tools.ColorSelector$ColorRange.setup(ColorSelector.java:426)
        at processing.core.PApplet.handleDraw(PApplet.java:2281)
        at processing.core.PGraphicsJava2D.requestDraw(PGraphicsJava2D.java:243)
        at processing.core.PApplet.run(PApplet.java:2177)
        at java.lang.Thread.run(Thread.java:724)
Exception in thread "Animation Thread" java.lang.RuntimeException: Pixel operations are not supported on this device.
        at processing.core.PGraphicsJava2D.getRaster(PGraphicsJava2D.java:2345)
        at processing.core.PGraphicsJava2D.loadPixels(PGraphicsJava2D.java:2357)
        at processing.core.PApplet.loadPixels(PApplet.java:11085)
        at processing.app.tools.ColorSelector$ColorSlider.setup(ColorSelector.java:501)
        at processing.core.PApplet.handleDraw(PApplet.java:2281)
        at processing.core.PGraphicsJava2D.requestDraw(PGraphicsJava2D.java:243)
        at processing.core.PApplet.run(PApplet.java:2177)
        at java.lang.Thread.run(Thread.java:724)


Listening for transport dt_socket at address: 8074
Catched FileNotFoundException: /home/pi/processing-2.1/core/library/gluegen-rt-android-natives-linux-armv6hf.jar (No such file or directory), while addNativeJarLibsImpl(classFromJavaJar class com.jogamp.common.os.Platform, classJarURI jar:file:/home/pi/processing-2.1/core/library/gluegen-rt-android.jar!/com/jogamp/common/os/Platform.class, nativeJarBaseName gluegen-rt-android-natives-linux-armv6hf.jar): [ file:/home/pi/processing-2.1/core/library/gluegen-rt-android.jar -> file:/home/pi/processing-2.1/core/library/ ] + gluegen-rt-android-natives-linux-armv6hf.jar -> slim: jar:file:/home/pi/processing-2.1/core/library/gluegen-rt-android-natives-linux-armv6hf.jar!/
java.lang.UnsatisfiedLinkError: Can't load library: /home/pi/processing-2.1/libgluegen-rt.so
        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1846)
        at java.lang.Runtime.load0(Runtime.java:795)
        at java.lang.System.load(System.java:1061)
        at com.jogamp.common.jvm.JNILibLoaderBase.loadLibraryInternal(JNILibLoaderBase.java:551)
        at com.jogamp.common.jvm.JNILibLoaderBase.access$000(JNILibLoaderBase.java:64)
        at com.jogamp.common.jvm.JNILibLoaderBase$DefaultAction.loadLibrary(JNILibLoaderBase.java:96)
        at com.jogamp.common.jvm.JNILibLoaderBase.loadLibrary(JNILibLoaderBase.java:414)
        at com.jogamp.common.os.DynamicLibraryBundle$GlueJNILibLoader.loadLibrary(DynamicLibraryBundle.java:388)
        at com.jogamp.common.os.Platform$1.run(Platform.java:209)
        at java.security.AccessController.doPrivileged(Native Method)
        at com.jogamp.common.os.Platform.<clinit>(Platform.java:179)
        at javax.media.opengl.GLProfile.<clinit>(GLProfile.java:83)
        at processing.opengl.PJOGL.initSurface(PJOGL.java:238)
        at processing.opengl.PGraphicsOpenGL.initPrimary(PGraphicsOpenGL.java:5988)
        at processing.opengl.PGraphicsOpenGL.requestDraw(PGraphicsOpenGL.java:1600)
        at processing.core.PApplet.run(PApplet.java:2177)
A library relies on native code that's not available.
Or only works properly when the sketch is run as a 64-bit  application.
        at java.lang.Thread.run(Thread.java:724)
</code>

Hi

Are you sure that you use the latest version of JOGL? Your problem reminds me a bug that I fixed in GlueGen. Please remove Android JARs (including gluegen-rt-android.jar) to avoid confusions so that GlueGen will only try to load the JARs containing the native libraries for Linux ARM 32 bits.

Hi Gouessej,

Thanks for your reply.

I took the Jogamp files from here: http://jogamp.org/deployment/jogamp-current/archive/jogamp-all-platforms.7z

I will try your suggestion tonight and report back.

Thanks,

B.

Ok thanks. There is probably a bug in GlueGen, it should never try to load Android native libraries under other operating systems.

When did you download this archive? If you didn't do it recently, please do it again.

Hi, sorry for the slow reply. It seems the forum was down this evening when I tried to login.

I tried your suggestion earlier and it appears to have solved Catched FileNotFoundException: /home/pi/processing-2.1/core/library/gluegen-rt-android-natives-linux-armv6hf.jar (No such file or directory) but now I get the errors (below) that I had before installing JOGL, which led me to realise that the correct .jar files were already there within the original Processing download, meaning that a manual (re)install was unnecessary?

Am I right to believe that I now need to force Processing to draw to NEWT rather than AWT? If so, are you aware of a simpler way to do this than to build from source? That seems like a world of pain.

Let me know if this is better placed on the Processing forum.

Thanks,

B.

<code>pi@raspberrypi ~ $ cd processing-2.1
pi@raspberrypi ~/processing-2.1 $ ./processing
pi@raspberrypi ~/processing-2.1 $ See https://github.com/processing/processing/issues/2010
See https://github.com/processing/processing/issues/2010
Exception in thread "Animation Thread" Exception in thread "Animation Thread" java.lang.RuntimeException: Pixel operations are not supported on this device.
        at processing.core.PGraphicsJava2D.getRaster(PGraphicsJava2D.java:2345)
        at processing.core.PGraphicsJava2D.loadPixels(PGraphicsJava2D.java:2357)
        at processing.core.PApplet.loadPixels(PApplet.java:11085)
        at processing.app.tools.ColorSelector$ColorSlider.setup(ColorSelector.java:501)
        at processing.core.PApplet.handleDraw(PApplet.java:2281)
        at processing.core.PGraphicsJava2D.requestDraw(PGraphicsJava2D.java:243)
        at processing.core.PApplet.run(PApplet.java:2177)
        at java.lang.Thread.run(Thread.java:724)
java.lang.RuntimeException: Pixel operations are not supported on this device.
        at processing.core.PGraphicsJava2D.getRaster(PGraphicsJava2D.java:2345)
        at processing.core.PGraphicsJava2D.loadPixels(PGraphicsJava2D.java:2357)
        at processing.core.PApplet.loadPixels(PApplet.java:11085)
        at processing.app.tools.ColorSelector$ColorRange.setup(ColorSelector.java:426)
        at processing.core.PApplet.handleDraw(PApplet.java:2281)
        at processing.core.PGraphicsJava2D.requestDraw(PGraphicsJava2D.java:243)
        at processing.core.PApplet.run(PApplet.java:2177)
        at java.lang.Thread.run(Thread.java:724)


Listening for transport dt_socket at address: 8638
glGetError 0x500
glGetError 0x500
java.lang.ClassCastException: javax.media.nativewindow.DefaultGraphicsConfiguration cannot be cast to com.jogamp.nativewindow.awt.AWTGraphicsConfiguration
        at javax.media.opengl.awt.GLCanvas.chooseGraphicsConfiguration(GLCanvas.java:1421)
        at javax.media.opengl.awt.GLCanvas.addNotify(GLCanvas.java:630)
        at java.awt.Container.addImpl(Container.java:1114)
        at java.awt.Container.add(Container.java:966)
        at processing.opengl.PJOGL.initSurface(PJOGL.java:326)
        at processing.opengl.PGraphicsOpenGL.initPrimary(PGraphicsOpenGL.java:5988)
        at processing.opengl.PGraphicsOpenGL.requestDraw(PGraphicsOpenGL.java:1600)
        at processing.core.PApplet.run(PApplet.java:2177)
        at java.lang.Thread.run(Thread.java:724)
</code>

Xerxes knows Processing a lot better than me. In 2013, its 2D and 3D rendering was still relying on AWT. If it has changed in the meantime, it should be possible to use an option to indicate to Processing that you'd like to use NEWT.

In my humble opinion, the proprietary drivers of the Raspberry Pi with secret hooks are really a world of pain, JOGL isn't to blame and there are some other scenegraphs and libraries using JOGL and NEWT that work on this kind of device.

Edit.: I have looked at its source code, especially here:
https://github.com/processing/processing/blob/master/core/src/processing/opengl/PJOGL.java#L118

You can use NEWT but you have to force its use somehow. @Xerxes Does anybody plan to add NEWT cursor supports into Processing like I did in JMonkeyEngine and Ardor3D?

Eric Anholt is hired by Broadcom to produce a MIT freesoftware GPU driver stack for the Pi.
http://anholt.livejournal.com/
Processing 2 using AWT will work without modifications using Eric's new drivers that enable OpenGL ES acceleration inside xorg 1.17+ using mesa3d and the new kernel modesetting vc4 driver.

I am helping Eric to test this new driver using my own "buildroot" cross-compile rpi branch setup
https://github.com/xranby/rpi-buildroot/commits/rpi


Meanwhile Processing 3.x is under development
Andres Colubri has "switched to GTWindow (no AWT embedding) in the opengl renderer in Processing, I will probably have more questions about NEWT as we move forward with the changes. "
thus Processing 3.x when released _may_ work with the current closed source broadcom drivers.
http://forum.jogamp.org/Creating-large-GLWindows-on-multiple-monitor-setups-tp4033552p4033557.html


Its the closed source broadcom drivers that do not support hardware acceleration under X11 that makes OpenGL ES hard on the Pi.
I hope these kind of issues will be sorted when Eric's freesoftware driver is stable.
I expect the first release of Erics work to be included in xorg server 1.17 and mesa3d that gets released around Jan 2015.

It's an excellent piece of news, thanks Xerxes.

I will have some questions to ask you about LibGDX so that I can maintain it while you keep concentrated on helping Eric.