Rpi 4 / Raspbian Buster / openFrameworks


Phew, been outta the loop for the last few months between finishing my Master’s thesis, graduating and finally moving continents and haven’t really been able to work on new stuff or contribute otherwise. But, between all of that, haven’t missed the little bit of news about the new Raspberry Pi.

The last time I worked on a Rpi project (repo here, it’s also my Master’s thesis which you can read here), while everything went mostly fine, towards the end of the it, I was seriously hampered by the performance limits of the Rpi 3. The fourth gen Pi seems to be much much powerful in every regard and I’m itching to get my hands on it soon, as soon as it’s back in stock and my studio/workspace is up and running again - which should be at least a couple of more months.

In the meanwhile, a couple of things did come to my attention regarding the new Raspbian version, however, most notably the “new open source openGL driver” which is “on by default” (source). Now historically, we’ve always used the GLES drivers on the Pi and had a discussion regarding the same when Stretch came about the windowing system to use by default etc. It’s probably time to open up the discussion again and make sure oF works on the new Raspbian and takes advantage of the new driver? As soon as I get a monitor in my new/current space I’m up for testing it with the Rpi 3, which the OS is backwards compatible with, but making this forum post for a larger space of discussion regarding these matters. Would love to see @bakercp and @kashim join in as I know they are active in the rPi space as well, as well as everyone else who might be looking into this, too.

PS. Maybe I’m making this post a bit too early, but hey, good to know these things in advance for when we want to use the rPi4 in our projects!


Also good to note that older RPis < 4 will still use the the “legacy” drivers (the ones we support now) by default on the new Raspbian Buster.

It should be possible to test the default OpenGL driver using a Rpi3 / Stretch. You just have to enable it in raspi-config. GLFW windows should be possible. There just hasn’t been a big push to get it working AFAIK. Now that RPi is looking more desktop-like, it would probably be worth it.

See discussions Should we move to GLFW windowing by default on Raspberry Pi? and https://www.raspberrypi.org/forums/viewtopic.php?t=222264 and http://discourse.glfw.org/t/glfw-on-rpi-with-opengl/1215

If RPi4 doesn’t compile straight away with the linux64 makefiles and debian dependency install scripts, then we could make a raspberry pi GL makefile PLATFORM_VARIANT that defines a raspberry pi 4 variations.


Just tested today on a pi4 2GB running Buster. The install_dependencies script gives me the following error. I’m not very familiar with all this stuff, but happy to do more tests if you tell me what to do! :slight_smile:

installing OF dependencies
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Note, selecting 'libsndfile1-dev' instead of 'libsndfile-dev'
Package libgles1-mesa-dev is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
However the following packages replace it:

E: Package 'libgles1-mesa-dev' has no installation candidate
error installing dependencies, there could be an error with your internet connection
if the error persists, please report an issue in github: http://github.com/openframeworks/openFrameworks/issues

Hello everyone!
(I posted about this in Slack and on GitHub issues but will repeat here so that everything is in one spot)

I had the same compilation error from install_dependencies script as @iwgouldstone, but replaced the offending libgles1-mesa-dev and libgles2-mesa-dev with the recommended libglvnd-dev. After that everything compiles but I had to add the -latomic LD flag to config.make for an emptyExample because it was missing `__atomic_fetch_add_8’

Everything compiles correctly but the window won’t open and throws the following error:

createSurface(): setting up EGL Display
* failed to add service - already in use?

@bakercp Do I need to change anything to use the linux64 makefiles from what is automatically used?
If I understand correctly, I need to try to switch the emptyExample app window from using OpenGL ES to using GLFW. Is there an example of that somewhere so I can look at it for how to do that?

1 Like

Basically you’ll need to convince the openFrameworks preprocessors that you’re basically a linux machine rather than a raspberry pi, so a quick starting point would be to redefine this



That should trick the preprocessors into treating you like desktop linux and configure a GLFW window. There are probably some other side-effects of doing that, but I can’t think of them off the top of my head … basically a quick search of the codebase for TARGET_RASPBERRY_PI will highlight RPi-specific stuff, though most if not all of it is in ofAppEGLWindow. Perhaps also some FMod related sound stuff?

Next, you’ll need to make sure that GLFW is compiled and available, so make sure you don’t exclude it. Thus, remove this line:

Finally you’ll need to make sure you have arm-compatible libraries installed for GLFW. Theoretically this is already done when you run

… I’m sure something will go wrong, but at least you can then post some new errors :slight_smile:


One more thing – a good place to start looking for errors caused by removing TARGET_RAPSBERRY_PI is to look here:

I suspect that you’ll need to manually include “bcm_host.h” somewhere … but perhaps this isn’t required anymore with the new GL drivers?

1 Like

Just to confirm - running the GLFW windowing mode means it’s from within the Desktop/X environment? Running a RPi in CLI mode would NOT run oF apps this way, correct?


If anyone wants to look into implementing this so we can include it in the core, this part in ofConstants.h:

	#include <unistd.h>

			#include "bcm_host.h"
			// rpi firmware headers define countof
			// which messes up other libraries like glm
			#undef countof

		#include "GLES/gl.h"
		#include "GLES/glext.h"
		#include "GLES2/gl2.h"
		#include "GLES2/gl2ext.h"

		#include "EGL/egl.h"
		#include "EGL/eglext.h"
	#else // desktop linux
		#include <GL/glew.h> 

should become something like:

	#include <unistd.h>

			#include "bcm_host.h"
			// rpi firmware headers define countof
			// which messes up other libraries like glm
			#undef countof

        #ifdef TARGET_OPENGLES
		#include "GLES/gl.h"
		#include "GLES/glext.h"
		#include "GLES2/gl2.h"
		#include "GLES2/gl2ext.h"

		#include "EGL/egl.h"
		#include "EGL/eglext.h"
	#else // OpenGL
		#include <GL/glew.h> 

Then in ofMainLoop.cpp https://github.com/openframeworks/openFrameworks/blob/master/libs/openFrameworks/app/ofMainLoop.cpp#L49-L63

Change that chunk to not choose GLFW or EGL window based on the platform but based on the platform + opengles, so RPI + opengl = glfw, RPI + opengles = egl, desktop linux + anything = glfw

Then adding a define in every linux platform makefile config to specify TARGET_OPENGL or TARGET_OPENGLES, possibly configurable from config.make as PROJECT_OPENGL_API or something similar

That would allow to choose from opengl or opengles on any linux platform.

Apart from that @eshkrab can you send a PR with your changes? It looks like that would be needed in other platforms soon but by now having a check for the debian version with something like https://www.unixtutorial.org/check-raspbian-version should be enough to make it work on new and old versions

@ayruos yes as far as i understand the opengl driver is only usable from an x session not from a console


Hey guys,

Thank you so much for all this. I was pulled away for a work emergency but will get back to it, execute everything and report results in the next 2-3 days.

1 Like

Happy to do any testing that would be useful here. I am just working on an OF project on a Pi3 and it would be cool to see how running it on the 4 differs (in terms of both performance and temperature). For now I shall wait for the PR as people work out the details (to avoid duplicating work), but I have a 2GB Pi 4 ready to test my current code against and a 4GB Pi 4 arriving this week (although I doubt there will be any difference between the two).



So I’ve tried to do the switchover to TARGET_LINUX as suggested but that was getting really messy so I’m trying to implement this with the proper macros as you suggested. Going over the ofMainLoop.cpp, I found a weird line I figured I should as about (L49-L63):

54  #elif defined(TARGET_RASPBERRY_PI)
55	shared_ptr<ofAppEGLWindow> window = std::make_shared<ofAppEGLWindow>();
56	#elif defined(TARGET_EMSCRIPTEN)
57	shared_ptr<ofxAppEmscriptenWindow> window = std::make_shared<ofxAppEmscriptenWindow>();
58	#elif defined(TARGET_OPENGLES)
59	shared_ptr<ofAppGLFWWindow> window = std::make_shared<ofAppGLFWWindow>();
60	#else
61	shared_ptr<ofAppGLFWWindow> window = std::make_shared<ofAppGLFWWindow>();
62  #endif

Why does TARGET_OPENGLES make an ofAppGLFWWindow window and not ofAppEGLWindow?

If I understood you correctly, that chunk should eventually look like this:

 49   shared_ptr<ofAppNoWindow> window = std::make_shared<ofAppNoWindow>();
 50 #else
 51   #if defined(TARGET_OF_IOS)
 52   shared_ptr<ofAppiOSWindow> window = std::make_shared<ofAppiOSWindow>();
 53   #elif defined(TARGET_ANDROID)
 54   shared_ptr<ofAppAndroidWindow> window = std::make_shared<ofAppAndroidWindow>();
 55   #elif defined(TARGET_RASPBERRY_PI) && defined(TARGET_OPENGLES)
 56   shared_ptr<ofAppEGLWindow> window = std::make_shared<ofAppEGLWindow>();
 57   #elif defined(TARGET_RASPBERRY_PI) && defined(TARGET_OPENGL)
 58   shared_ptr<ofAppGLFWWindow> window = std::make_shared<ofAppGLFWWindow>();
 59   #elif defined(TARGET_EMSCRIPTEN)
 60   shared_ptr<ofxAppEmscriptenWindow> window = std::make_shared<ofxAppEmscriptenWindow>();
 61   #elif defined(TARGET_LINUX)
 62   shared_ptr<ofAppGLFWWindow> window = std::make_shared<ofAppGLFWWindow>();
 63   #endif

Is that not correct, @arturo ? I don’t really see how a linux platform that’s not RPI could end up with OpenGLES with this set of constants.
Should I add a TARGET_LINUX && TARGET_OPENGLES condition that sets

shared_ptr<ofAppEGLWindow> window = std::make_shared<ofAppEGLWindow>() ?

Obviously I missed something in moving/introducing macros, as using TARGET_RASPBERRY_PI and adding TARGET_OPENGL didn’t work properly and the app still was using ofAppEGLWindow. I tried using TARGET_LINUX again and that renders the following linker error -

ofAppRunner.cpp:(.text+0x4c28): undefined reference to `ofAppGLFWWindow::setup(ofGLFWWindowSettings const&)'
/usr/bin/ld: ofAppRunner.cpp:(.text+0x5470): undefined reference to `ofAppGLFWWindow::pollEvents()'
/usr/bin/ld: ../../../libs/openFrameworksCompiled/lib/linuxarmv6l/libopenFrameworks.a(ofMainLoop.o): in function `ofMainLoop::createWindow(ofWindowSettings const&)':
ofMainLoop.cpp:(.text+0x40fc): undefined reference to `ofAppGLFWWindow::ofAppGLFWWindow()'
/usr/bin/ld: ofMainLoop.cpp:(.text+0x4608): undefined reference to `ofAppGLFWWindow::pollEvents()'
collect2: error: ld returned 1 exit status
make[1]: *** [../../../libs/openFrameworksCompiled/project/makefileCommon/compile.project.mk:399: bin/raspberrypi_hello_world] Error 1
make[1]: Leaving directory '/home/pi/openFrameworks/apps/devApps/raspberrypi_hello_world'

I’ll keep going over everything but wanted to post url to my fork (haven’t done a PR yet since I haven’t solved anything yet). My fork for eventual PR is here


The last defines you post look correct. The EGL window is very specific to the raspberry pi so better to leave glfw for both gles and gl in other linux platforms

About the error, it’s probably cause you need to remove this line: https://github.com/openframeworks/openFrameworks/blob/master/libs/openFrameworksCompiled/project/linuxarmv6l/config.linuxarmv6l.default.mk#L189

making it conditional to using opengles or opengl instead of simply removing it would allow to switch between the two


Oh man, that was totally it, thanks! Finally have a more interesting error to post, happens once I run.

No protocol specified
[ error ] ofAppGLFWWindow: 65544: X11: Failed to open display :0
[ error ] ofAppGLFWWindow: couldn't init GLFW
[ error ] ofAppGLFWWindow: 65537: The GLFW library is not initialized
Segmentation fault

It’s trying to open display 0 after I manually set DISPLAY env var (I’ve also tried 0.0). I’m launching from command line over SSH to the raspberry pi with a monitor and desktop, but also tried to just launch the binary and that failed as well. I’ve made sure GL drivers are enabled in raspi-config.

This, however, is with TARGET_LINUX because my macros with TARGET_RASPBERRY_PI and TARGET_OPENGL aren’t right somewhere still, EGL windows are included, and I get errors like the following:

/home/pi/openFrameworks/libs/openFrameworks/app/ofAppGLFWWindow.cpp:380:16: error: ‘getX11Display’ was not declared in this scope
  xim = XOpenIM(getX11Display(), 0, 0, 0);
/home/pi/openFrameworks/libs/openFrameworks/app/ofAppGLFWWindow.cpp:380:16: note: suggested alternative: ‘getEGLDisplay’
  xim = XOpenIM(getX11Display(), 0, 0, 0);

Should I submit a PR now or keep ironing that out first?


if you want to start a PR i think that might help, since others can also look into it and even test it and let you know if they see something wrong


Cool, my blunderings are now an rpi4 PR. I’ll keep trying to poke at it in the meantime


Hello, I’ve just pulled your pull request and have the same error here

error: ‘getX11Display’ was not declared in this scope

I’ll keep an eye in this thread

PS: Cloned using this command, if somebody else wants to test

git clone --recursive --depth 1 --single-branch --branch rpi4 https://github.com/eshkrab/openFrameworks


I am stuck at the same point.


Hey guys, forgive me for the long delay!

this last year is full of work
I abandoned RPI for some time
I’m working on FPGA built by my company
and I focused on this.

I expect to be active again in the community
by the end of this year.

I would like to bring some experiences I have developed in the last period into openframeworks in the form of addons!

in any case I remain available via email: d.longobardi@ziggurats.net
if you need some kind of support!

a big greeting to my favorite community !!


1 Like