raspberry pi

has anyone already started to play with OF and raspi?
Porting OF to this board seems rather complex but not impossible, do you think it would take too much work to be worth?
Many libraries should be already available, except for fmodex and some little things.
Opengl ES implies an approach without glut or is there a different solution?
I made some essay and faced quite a long list of troubles I was not able to solve,
Is there an effort already going?

Hi Francesco

yes in fact there’s a long-standing effort to port openFrameworks to ARM CPU’s in general. we already have a working version for the Pandaboard (https://github.com/damiannz/openFrameworks/tree/damian-linuxarm7-softfp, GLUT|ES https://github.com/damiannz/glutes) and it shouldn’t be too much effort to port to ARM11/Raspberry Pi, i believe jvcleave has had some success with that already in fact.

the biggest issue so far has been figuring out how to open a window using the EGL that ships with the Raspberry Pi, as the way I made GLUT|ES work on the Pandaboard doesn’t seem to work on the Raspberry Pi. we will probably need an ofAppRaspberryPiWindow or ofAppLinuxNoX11Window or similar, and i’m not sure about how we will do keyboard/mouse input over the top. but it’s certainly something we’re actively working towards.


Yeah - here is a img of what I was working with. OF compiles and can launch an app with ofAppNoWindow

the user/pass is pi:raspberry (shipping default) or pi:pi - I changed it at some point but
not sure which one that is. It also has global SMB set up so you can
edit/read files over the network

compile flags I used:

CCFLAGS = -march=armv6j -mtune=arm1176jzf-s -mfpu=vfp  
-mfloat-abi=softfp -finline-functions -funroll-all-loops  -O3  
-funsafe-math-optimizations -ftree-vectorize  

Here are some of the things I came across:

  • RPi cannot launch an OpenGL ES based app in X11. (edit: hack for this http://www.youtube.com/watch?v=8Fy63w6WxOw)

  • RPi really wants OpenGL ES 2 but could possibly work with something like Damian’s glutes (maybe easiest route to try)

  • I’ve been told by multiple sources that only OpenGL ES 2 will work although this screenshot confuses me:

  • When porting take a look at these examples that work on the PI. These examples can run without X11 which is super appealing to me as you gain at least 30MB of RAM that is the minimal for X11


Misc stuff
Interesting distro focusing on hard float support for the Rpi


I definitely vote for this as the way to go b/c we need GL ES 2 support for iOS and Android anyways, but I’m not deeply familiar with how he’s set it up or with how that the would work on the Pi. I’m definitely game to try anything and to help out but I’m not as knowledgable as Damian or Jason, so, you know, I’m all learning :slight_smile:

A nice EGLWindow class working on the PI here:

The RPi apparently interfaces directly with the Videocore IV chip (no DirectFB, SDL, etc). This is what I believe this file is all about

also starting to see hardfp versions

Hey All, some discussion about the GLES2 renderer here as well:


Found this, which compiles (!) and opens up an OpenGL 2.0 context:

@jvcleave, is your copy of the OF code available on github or the like?

Or did you not have to edit any makefiles, etc to get it to compile? Have not had such luck so far.


Yeah - here is a img of what I was working with. OF compiles and can launch an app with ofAppNoWindow


I have a more recent version that I can upload - I did change the makefiles, etc

Awesome, would love to have a look.


I’m currently having trouble doing anything on a GL ES 1.1 context apart from clearing the screen in a color (from EGLDemo) and getting the vendor strings etc. Drawing (with vertex arrays of course) causes a segfault.
If anyone else is hacking on this give me a shout.

Will give ES2 drawing a try, but it would be much easier to start OF integration with 1.1, we have to go 2.0 in the long run though as the GPU is just sitting there otherwise.

Early beginnings on an ofAppEGLWindow here, currently opens a window but can’t draw:

Actually, I will try running the Quake3 demo on it, that seems to be drawing in 1.1, just to check it’s not something with my setup.


a window is better than no window :slight_smile: - good to see!

Just FYI, cause it seems to fill a similar niche: The Ouya console: Android, Tegra3, HDMI for $99

The problem was firmly between the keyboard and the chair, there were some errant references to -lGL and -lglew in the makefiles and that seems to have stopped it from working.

Got a window up now that I can draw to with all the OF commands I’ve tried so far, now the question is just how to handle input events, I’m reading the mouse as per an example (EGLDemo, http://jonmacey.blogspot.co.uk/search/label/EGL ) but this is probably not the best way to go long term, converting that to reliable mouse click events could be tricky and there is of course the issue of the keyboard.

I’d be interested in knowing what a good approach to this might be in Linux, without involving some large library like SDL, SFML, etc.

There is as far as I know, no GLUT for the Raspberry PI at the moment, I’m using EGL to open up the window.


looks like this has some mouse input by echoing the /dev/input/mouse0

this looks like the relevant section (actually a lot of interesting stuff in there)

That looks promising, at the very least it seems you can get normal events under X (as opposed to reading “what is the status of this device” every frame).

The Pi is obviously not brimming with RAM so I’m guessing most deployments would prefer to run software on it without X, but for education it seems like a steep learning curve to be doing stuff from the command line, so will definitely take a stab at supporting both if possible (and indeed it seems possible).

Moved the ofAppEGLWindow code here for the moment:


Just figured I’d throw this in there for reference, there is a Linux distro built especially for the Pi: http://liliputing.com/2012/07/raspbian-linux-now-available-for-raspberry-pi-up-to-40-percent-faster-than-debian.html

Raspbian is a rebuild of debian hardfloat with reduced CPU requirements so it will run on the Pi, pretty neat concept.

nice! I ran across it as it was in development but they had a lot of the packages to go. Looks like rPI is putting it as their recommended install.

What about using directfb for OF. You’d get a lot more rpi-like devices supported as a benefit as well as having input. They’ve got directfb running on rpi https://plus.google.com/109054407220184149542/posts/PGEHcHazRow

That looks really interesting actually, will have a look when I get a chance.