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.
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
a. Advanced Options > GL Driver > “G3 Legacy” "Original non-GL desktop driver
b. Finish and reboot.
Download and install openFrameworks (master branch)
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).
More than -j2 often runs out of RAM, thrashing the very slow swap.
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!
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.
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.
@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.
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.