Compiling OF in raspbian Stretch

PiMakers · September 16, 2017, 7:13am

Hi!

The Cross env can’t find RT audio, so add:
PLATFORM_HEADER_SEARCH_PATHS += $(SYSROOT)/usr/include/rtaudio
to the cross section of config.linuxarmv6l.stretch.mk

I prepared "buildAllRPIExamples.sh script to cross compile then run all Rpi tests on my target Rpi3B for 10 sec.
Everything works fine except some shaders with ARB extension (RPI HW limit), must correct in OF.
So this make me brave enough to give a try for the new glm feature next time.

fresla · October 19, 2017, 1:17pm

Hey did you manage to solve the .ofAppEGLWindow: display(): eglSwapBuffers failed error.

I am facing this now and looking for a solution. I started with the normal Jessie Debian too.

fresla · October 20, 2017, 3:50pm

@PiMakers
Hi, I am trying to apply your fix, the first changes in the config.linuxarmv6l.default.mk are straight forward enough, but I am not sure where to make the changes you list after that.

I don’t need a cross compiler but all of the downloadable options are broken right now and I need to get the pi up and running. It would be great if you can shed some light on this.

Cheers

Fred

krizzl0r · October 24, 2017, 12:56pm

try disabling the opengl driver via raspi-config/advanced options.

ayruos · October 24, 2017, 5:17pm

I gave up trying to get OF running on stretch as the ofxGPIO addon that I needed wouldn’t compile either. [I did get OF nightly to compile but would get the same eglSwapBuffers error].

oF Nightly works like a charm on Jessie though, I downloaded and used that instead of Jessie.

bakercp · December 6, 2017, 2:04am

There are currently two options for running openFrameworks on Raspbian Stretch. Both offer hardware accelerated EGL/GLES functionality. The first uses the “Legacy” proprietary Broadcom drivers (brcm) and the second uses the newer open source (mesa) drivers.

Method 1 (brcm) has been tested with both 2017-11-29-raspbian-stretch and 2017-11-29-raspbian-stretch-lite. Method 2 (mesa) has been tested with 2017-11-29-raspbian-stretch on the Raspberry Pi desktop.

Method 1 (`brcm`)

All of the steps in Method 1 can be done from Terminal (e.g. ssh) or from a Terminal within the Desktop.

Prepare your Raspberry Pi Firmware to use the “Legacy” GL drivers

sudo raspi-config
a. Advanced Options > GL Driver > “G3 Legacy” "Original non-GL desktop driver
b. Finish and reboot.

Download and install openFrameworks (master branch)

cd ~
git clone --depth=1 https://github.com/openFrameworks/openFrameworks.git
cd openFrameworks
sudo /bin/bash scripts/linux/debian/install_dependencies.sh (sometimes you have to do this several times for it to finish correctly)
sudo /bin/bash scripts/linux/debian/install_codecs.sh
/bin/bash scripts/linux/download_libs.sh

Modify Your `config.linuxarmv6l.default.mk` File

nano libs/openFrameworksCompiled/project/linuxarmv6l/config.linuxarmv6l.default.mk

Basically you just replace these three lines:

github.com

openframeworks/openFrameworks/blob/master/libs/openFrameworksCompiled/project/linuxarmv6l/config.linuxarmv6l.default.mk#L123-L125


PLATFORM_LIBRARIES += GLESv2
PLATFORM_LIBRARIES += GLESv1_CM
PLATFORM_LIBRARIES += EGL

with

PLATFORM_LIBRARIES += brcmGLESv2
PLATFORM_LIBRARIES += brcmEGL

GLESv1_CM doesn’t exist anymore (for Jessie as it just pointed to GLESv2) and the older “Legacy” drivers are now prefixed with brcm (Broadcom) indicating that they are the proprietary Broadcom VideoCore blobs (which have been replaced with the newer open source mesa drivers in Stretch).

Compile a Test Project

cd ~/openFrameworks/
cp scripts/templates/linuxarmv6l/Makefile examples/templates/emptyExample/
cd examples/templates/emptyExample/
make -j2 -s
- More than -j2 often runs out of RAM, thrashing the very slow swap.
make run

Method 2 (`mesa`)

All of the steps in Method 1 can be done from Terminal (e.g. ssh) if a valid DISPLAY env. variable is set or simply from a Terminal within the Desktop.

Prepare your Raspberry Pi Firmware to use the “Legacy” GL drivers

sudo raspi-config
a. Advanced Options > GL Driver > “G1 GL (Full KMS) OpenGL desktop driver with full KMS”
b. Finish and reboot.

Download and install openFrameworks (master branch)

cd ~
git clone --depth=1 https://github.com/openFrameworks/openFrameworks.git
cd openFrameworks
sudo /bin/bash scripts/linux/debian/install_dependencies.sh (sometimes you have to do this several times for it to finish correctly)
sudo /bin/bash scripts/linux/debian/install_codecs.sh
/bin/bash scripts/linux/download_libs.sh

Modify Your `ofAppEGLWindow.cpp` File

nano libs/openFrameworks/app/ofAppEGLWindow.cpp

Basically you just delete these six lines:

github.com

openframeworks/openFrameworks/blob/master/libs/openFrameworks/app/ofAppEGLWindow.cpp#L440-L446


	// bool bIsX11Available = (pDisplay != NULL);


	bool bIsX11Available = getenv("DISPLAY") != NULL;


	if(settings.eglWindowPreference == OF_APP_WINDOW_AUTO) {
		if(bIsX11Available) {
			isUsingX11 = true;

As you can see, we’ve been waiting for this day!

Compile a Test Project

cd ~/openFrameworks/
cp scripts/templates/linuxarmv6l/Makefile examples/templates/emptyExample/
cd examples/templates/emptyExample/
make -j2 -s
- More than -j2 often runs out of RAM, thrashing the very slow swap.
make run

The Future

Now that the mesa drivers are available, we might consider moving to GLFW for Raspberry Pi (the windowing system we use on all other desktop platforms) if the performance doesn’t suffer. GLFW supports the newer mesa drivers. We need a volunteer to do some performance testing. If the performance is equal, the choice to switch to GLFW should be obvious. If not, then we should have a conversation!

jvcleave · December 6, 2017, 3:37pm

Does Method 2 require the Desktop environment to be enabled?

bakercp · December 6, 2017, 4:10pm

I have not tested Method 2 without the desktop yet – it’s creating an X11 window, so I’m assuming it needs some kind of x11 context. The ofAppEGLWindow checks to see if the DISPLAY environmental variable is set and then proceeds to use X11 (XCreateWindow, XDestroyWindow, etc), otherwise it tries to use dispmanx*.

In my experience so far, mixing the two methods doesn’t work (not to say that we have to use X11 to create a window … we could probably somehow use dispmanx to create the EGL context and still use the mesa drivers). Just haven’t tried it.

Jonas_Sorgenfrei · December 7, 2017, 1:55pm

Tried your methode 2 but still wasn’t successfull.
Now I get a Window but still the notice :
ofAppEGLWindow: display(): eglSwapBuffers failed:
and some errors before.

This was the 3DPrimitives Example nit the
eglSwapBuffers fail notice appears even on the emptyExample

…
[notice ] ofAppEGLWindow: createSurface(): setting up EGL Display
[notice ] ofAppEGLWindow: createSurface(): EGL Display correctly set 0xe34258
libEGL warning: DRI2: failed to authenticate
[notice ] ofAppEGLWindow: createSurface(): no current renderer selected
[notice ] ofAppEGLWindow: createSurface(): default renderer detected
[ error ] ofAppEGLWindow: createSurface(): no matching configs were found, num_configs: 0
[ error ] ofAppEGLWindow: setupPeripherals(): peripherals not supported on X11
[notice ] ofGstVideoGrabber: Probing devices with udev…
[ error ] ofGstVideoGrabber: initGrabber(): no devices found, exiting without initializing
[notice ] ofAppEGLWindow: display(): eglSwapBuffers failed:
…

Got an Raspberry 1 with the Rasbian Stretch OS
Linux raspberrypi 4.9.59+ #1047 Sun Oct 29 11:47:19 GMT 2017 armv61 GNU/Linux

Does any one have any further ideas?

In the meantime ill try method #1

bakercp · December 7, 2017, 6:48pm

If you’re using an RPI 1, double check to make sure you have enough GPU memory allocated. Did it work with method 1?

Jonas_Sorgenfrei · December 12, 2017, 7:06pm

I tried your method 1 and this one worked for me.
Thanks.
Is the GL Driver so much better ?
Do you think it would make sense going
on to try method 2?

bakercp · December 12, 2017, 7:31pm

The main reason the Method 2 will be good in the future is that it will be easier to maintain for openFrameworks since we can just use a normal desktop windowing system (e.g. GLFW). I’m not sure if RPi has any plans to stop supporting the brcm drivers, but since they are now referred to as legacy drivers, I’d guess that the future is in the open-source mesa drivers.

I don’t foresee any significant performance differences, but we need more rigorous testing to compare the two (e.g. is it possible to run openFrameworks applications on the “lite” version of Raspbian using the mesa drivers?).

Practically, I’m probably sticking with method 1 for now since it’s the status quo for oF since we got oF running on the RPI 5 years ago.

flx · December 12, 2017, 9:33pm

hello method one good so far but I can not find the config.linuxarmv6l.default.mk file to change it?

run a find search :::find: ‘config.linuxarmv6l.default.mk’: No such file or directory

thanks for any advice

TimChi · December 13, 2017, 5:18am

Hi @flx, you can find the file in the open frameworks directory /libs/openFrameworksCompiled/project/linuxarmv6l/.

Some of us have had a (somewhat) parallel thread here: Raspberry Pi Poco error.

@bakercp thank you so much for methods 1 and 2 above! I just installed Stretch on an RPi3 and successfully compiled the “master branch” via both methods. And the polygonExample builds and runs just fine with both methods. I also switched drivers in raps-config to match the chosen method.

I have not tried my own application with the ofxGPIO add-on yet (see post above from @ayruos), but will try soon and edit this post according to what I find. I’ll also try a 3d example to see how that goes.

For what its worth, I think the mesa drivers are the way to go, at least in terms of maintaining a common windowing system as @bakercp stated above. And I feel this is worth it even if there is a performance drop in the short term. The mesa drivers are open-source and likely will benefit the Pi and its users in the years to come. The Pi hardware will likely become faster and/or more capable as time goes by as well.

And thanks to everyone who has contributed to this and the other related threads. Its nice to have made some progress on the transition from Jessie to Stretch on the Pi. The forum has been really a great resource for this issue.

Edit: The 3dPrimitivesExample runs fine with both methods. I had the similar errors as @ayruos with ofxGPIO when compiling.

bakercp · December 13, 2017, 6:10am

I just added the paths to the post for both methods just to be more explicit.

bakercp · December 22, 2017, 3:33pm

7 posts were split to a new topic: Running ofxGPIO on Raspbian Stretch

flx · December 13, 2017, 9:48pm

Thanks …I found the file…

http://www.lazo.cl/
Visual & Audio Thinking
www.lazo.cl

ThreeDOgs · December 30, 2017, 2:26pm

RPi 3 OS: Stretch 64kb used for Graphics

Well I have tried openFrameworks on a RPi 3 and still cannot get it running, so I will give openFrameworks a miss.
I may be a problem finding an alternative though.

Perhaps in future it will run…I hope so .

ayruos · December 30, 2017, 2:56pm

I just got everything running on Stretch, including ofxGPIO (at least the MCP stuff). What issues are you facing?

ThreeDOgs · December 30, 2017, 4:08pm

TRpi 3 and Stretch?
WHat was your setup?

I get compiler errors (Podo(?) ) and a receiver error on a directory as posted by mar.carnet.
I also want to install opencv 3.3.1 on the system as well - in fact, this has priority -
so adjustments to the graphics that may influence this are to be avoided.

Compiling OF in raspbian Stretch

Method 1 (brcm)

Prepare your Raspberry Pi Firmware to use the “Legacy” GL drivers

Download and install openFrameworks (master branch)

Modify Your config.linuxarmv6l.default.mk File

Compile a Test Project

Method 2 (mesa)

Prepare your Raspberry Pi Firmware to use the “Legacy” GL drivers

Download and install openFrameworks (master branch)

Modify Your ofAppEGLWindow.cpp File

Compile a Test Project

The Future

Method 1 (`brcm`)

Modify Your `config.linuxarmv6l.default.mk` File

Method 2 (`mesa`)

Modify Your `ofAppEGLWindow.cpp` File