supports the Rpi 4 with EGL and GLFW. Closes #6436

[ofTheo]

This PR adds support for Rpi 4 for both rendering approaches.
Huge thanks to @ThomasColliers who did most of the work in this branch: nondescriptpointer@36fd56f

I just added a define to distinguish between the older models which can use the older EGL method and the newer models which can use both EGL and GLFW with X11.

NOTE: I don't think its possible to run EGL with the old legacy driver from what I was reading in other forum posts.

Things to still check/fix:

• TARGET_RASPBERRY_PI_4 naming is a little weird could be refactored - just used it for now. Especially if there is Model 3 support.
• Also to consider do we want to do anything for this file too?: https://github.com/openframeworks/openFrameworks/blob/master/libs/openFrameworksCompiled/project/linuxarmv7l/config.linuxarmv7l.raspberry2.mk
• Coming out of fullscreen issue with GLFW mode. Needs a resize to restore rendering. Will open a separate issue / PR after this is merged.

Note for anyone wanting to automate the bash detection of Debian version. See this solution ( https://unix.stackexchange.com/posts/6348/revisions )

[kod3000]

For the raspberry pi 4 installation

Is it possible to also update the file openFrameworks/scripts/linux/debian/install_dependencies.sh

The following error still occurs :

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:
libglvnd-dev
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

changing 'libgles1-mesa-dev' to 'libgles1' solves the problem.

[ofTheo]

@kod3000 Thanks for taking a look!

I have that change in the install_dependencies.sh here:
https://github.com/openframeworks/openFrameworks/pull/6438/files#diff-7263e131fbc295fdf3622c0c204a498aR40

Hopefully that is addressing what you mentioned.

[sourya-sen]

Checking in from an RPI 3B+

Without any changes to the makefiles, running the GL Full KMS GL Driver on Buster, graphicsExample compiles and runs from X11. NOT FROM CLI.

So, if it's running Buster and the GL driver is enabled, it doesn't matter if it's a RPI3 or an RPI4 (for the makefile target).

Using the legacy GL driver, it doesn't work from the CLI (I don't think it's supposed to, either?) and gives the eglSwapBuffer() error as is documented on the forums.

Edit: Should I be testing the GLFW mode as well or that doesn't work irrespective as originally commented on #6436 ? Also, Buster onwards, is there still a way to run stuff off the CLI or X11 is the way to go?

[arturoc]

The TARGET_RASPBERRY_PI_4 macro does seem a bit ad-hoc indeed. I would define TARGET_RASPBERRY_PI for every rpi no matter the version (if it's not already) which should remove most of the #if (!defined(TARGET_RASPBERRY_PI) || defined(TARGET_RASPBERRY_PI_4)) and similar and then define something like TARGET_RASPBERRY_LEGACY which could be use to ifdef out the couple of places where there's code that only works with the legacy driver

apart from that it looks good but would be nice to have it running from console as that's what most people use and it doesn't require a full desktop which potentially uses a lot of extra memory that could be used by applications instead

[ofTheo]

Thanks @arturoc - I think that all makes sense!

In terms of headless. There might be a way via: sudo apt-get install xvfb ( see https://www.raspberrypi.org/forums/viewtopic.php?p=506636&sid=9a675930f1f4dc6447c09a7971fdfc43#p506636 ) It will have to be different with the X powered window ( I don't think the other way is possible at this point as buster doesn't have the older drivers ).

@sourya-sen Thanks for testing!
Could you try building with this line commented out?
https://github.com/openframeworks/openFrameworks/pull/6438/files#diff-011c6dc421d3f054ec0e4dd9d10683d5R53

That should revert to the older approach.
I am guessing it won't work as I think its not so much a Rpi 4 hardware vs older but a Buster vs older distros issue. Would be interesting to see though.

Also I am guessing but I think GLFW mode should work for you as well.

LEGACY vs NEWER
If the distinction is more Buster and newer vs older Debian releases. We could do the following based on the Debian version being used.

• On Buster we can default to the newer approach.
• On Stretch we can default to the newer ( but I think both will work based on @bakercp 's post )
• On older builds it can default to the legacy mode.

[sourya-sen]

@ofTheo with the GL driver, I have a feeling headless through a VNC might work, I did set up the entire rPi headless through a VNC connection running X11 but I didn't actually check if OF works through that as well, switched to a proper monitor/keyboard combo once OF was compiled. The VNC server comes with the Raspbian distro, just needs to be enabled through raspi-config, through SSH. I can write a full guide if you want, specially if OF works through this approach.

I'll give the headless through VNC approach a go tomorrow, as well as the legacy approach with the line commented out - it's pretty late this side of the world right now :)

[ofTheo]

Thanks @sourya-sen !
Appreciate the help testing this.

From what I understand VNC can be made to work and ssh -X but having it run without an active connection is harder. I think this might solve that sudo apt-get install xvfb

Xvfb (short for X virtual framebuffer) is an in-memory display server for UNIX-like operating system (e.g., Linux). It enables you to run graphical applications without a display (e.g., browser tests on a CI server) while also having the ability to take screenshots.

[dimitre]

I've just checked out your pull request using the following commands:

git fetch origin pull/6438/head
git checkout -b pullrequest FETCH_HEAD

it only works here using Desktop and keyboard (not under ssh)
ofToggleFullscreen() doesn't work yet, only windowed.
and it fails if software uses FBO (sometimes with a message and others with Segmentation Fault.
Thank you!

[ofTheo]

Thanks @dimitre !
I got it working with headless after installing xvfb and enabling the GLFW renderer in the make file.

You can then run a headless example with:
xvfb-run ./examples/graphics/polygonExample/bin/polygonExample

you get a warning about the gamma ramp not being enabled, but you have a rendering environment and can do GL calls and save out screen grabs etc.

Will see if using GLFW fixes the fullscreen and fbo issues you mention.
Thanks!

[ofTheo]

@dimitre FBOs and fullscreen works with the GLFW approach.
I do see a weird issue a few frames after coming out of fullscreen with GLFW where the window has to be resized to restore rendering. I'll see if I can track that down.

[sourya-sen]

FBOs have had issues on the rPi historically when the locale has not been set properly. It could be something similar along those lines, see #5917. I don't think it was ever fully fixed.

[dimitre]

@ofTheo changed to GLFW and FBO is back working
tried xvfb-run and it returns an error
ofAppGLFWWindow: 65544: X11: RandR gamma ramp support seems broken

[ofTheo]

@dimitre ah yes, I get that error too, but it runs and renders GL calls fine.
Tested with some outputted screencaptures to png.

[ofTheo]

Updated the #defines to be less complex.

At the moment for older Raspbian releases you need to uncomment this line:
https://github.com/openframeworks/openFrameworks/pull/6438/files#diff-011c6dc421d3f054ec0e4dd9d10683d5R48

I imagine there could be a way to detect the Raspbian version in the make file and switch automatically, but this is not really my area of expertise and I think it might involve calling some bash scripts from the make file.

Maybe for now we could just include information on uncommenting this line in the Raspberry Pi Setup Guide?

[bakercp]

I should finally have access to a pi 3/4 this week. I can give it a run through and report back.

…

On Tue, Nov 12, 2019, 1:02 PM Theodore Watson ***@***.***> wrote: Updated the #defines to be less complex. At the moment for older Raspbian releases you need to uncomment this line: https://github.com/openframeworks/openFrameworks/pull/6438/files#diff-011c6dc421d3f054ec0e4dd9d10683d5R48 I imagine there could be a way to detect the Raspbian version in the make file and switch automatically, but this is not really my area of expertise and I think it might involve calling some bash scripts from the make file. Maybe for now we could just include information on uncommenting this line in the Raspberry Pi Setup Guide? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#6438?email_source=notifications&email_token=AACJLRGYWUNSOANLANEJIDDQTMDWZA5CNFSM4JLBE3E2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOED3X33Q#issuecomment-553090542>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACJLRHJOSOE6JTV7TZ3HXTQTMDWZANCNFSM4JLBE3EQ> .

[ofTheo]

Thanks @bakercp!
I think we're pretty close. I would be curious to see if a Rpi 3 with Stretch or Jessie can run fine with the legacy Driver and USE_PI_LEGACY uncommented in the OF make file.

[sourya-sen]

Hey @ofTheo! I haven't had a chance to run stuff on the rPi3 since last weekend but will try to test the newest commits as soon as possible.

[ofTheo]

ugg - not sure why these make file commits are failing in the CI.
pretty much all of them work on the PI. Regardless of if this line passes or fails.

81e2e54#diff-011c6dc421d3f054ec0e4dd9d10683d5R58

[kod3000]

I'm using the rp4. I got it to work by cloning straight from github using the branch "feature-rpi4".

Everything runs smoothly, the only thing extra that I did was copy the examples folder from the "of_v20191113_linuxarmv6l_nightly.tar.gz" build over to the cloned and ran them.

I also installed the "xvfb" but got an error "ofAppGLFWWindow: 65544: X11: RandR gamma ramp support seems broken". I wasn't able to run it headless.

Using a keyboard and mouse the compiled examples work as expected. Fullscreen also seems to be functional. I'm going to try a couple of more examples if anything comes up I'll post it up.

Thanks for getting this functional :)

[ofTheo]

@kod3000 - thanks!
That RandR error doesn't stop it running headless. It seems to work fine headless despite the error. I could see if I could catch it though or disable the call on Rpi.

Toggling fullscreen with ofToggleFullscreen() is weird though.
See this issue: #6445

[ofTheo]

Okay so I think at this point I can get the makefile doing what it needs to and working fine on the CI server.

The only thing is it looks like GLFW isn't installed on the Travis image which is being used and because the Debian version is Stretch ( VER_ID 9 ) the makefile is selecting the newer approach with GLFW and then erring when it can't find it.

@arturoc what would be the simplest way to add GLFW to the CI server? Locally on the Rpi 4 I didn't even have to include it in the makefile just have it installed at the system level.

The other alternative would be to detect that we are running on the CI and disable the GLFW approach, but I think it could be handy to have it use the system most users will be using.

[ofTheo]

Okay looks like this is building fine now.
Think this should be good to go once the rest of the CI tests have passed.

If there was ever a need for squash and merge its with this PR!
:)

[ofTheo]

The two CI failed checks are just for Android and MSYS2 and are unrelated to the PR so I think this is good to merge finally!

[arturoc]

from what i see the changes to the makefiles are mixing spaces and tabs which is super problematic for makefiles. can you change every new addition to tabs? some very specific lines need spaces though so don't use an autoformater or something that would turn the whole file to spaces please

[ofTheo]

@arturoc sure!
I ended up going back and forth a bit dealing with tab / space issues. All these files worked locally and on CI, but I can check and make the changes consistent.

[bakercp]

Hi All, I am installing this in class with a student right now and ran into the tabs spaces issue. I'm happy to help, but will let you take a stab at it.

Additionally, @ofTheo would you mind setting the permissions back to 100755 on this file?

scripts/linux/debian/install_dependencies.sh 100755 → 100644 

I had to manually chmod to get it running again.

Thx!

[ofTheo]

thanks @bakercp - will add that to the PR for the tabs

[dimitre]

I'm back home with access to a RPI4 and RPI3B+, let me know if you need any testing