Raspberry Pi 4 support (GLES 1.1)

SDL Development
1

Hi,

Just wanted to raise a thread here following the release of the Raspberry Pi 4. I’ve successfully got Wolfenstein Enemy Territory working with GLES 1.1 and SDL2, but there are some significant changes required to get GLES working on this new board.

  1. The “libbrcmGLESv2” library should not be linked to anymore and instead we should use the Mesa libs. For GLES 1.1, there is a library installed by default called “GLESv1_CM”.
  2. The “libgles1-mesa-dev” package is no longer available in Debian Buster, so in order to use GLES 1.1 headers, you need to reference the ones installed in the Pi firmware directory, i.e “/opt/vc/include”.
  3. In the past, people have referenced a number of flags to pass to SDL2’s configure if you want to build for GLES - simply running “./configure” is enough on the Pi 4, this is because X11 is used as the window manager instead of dispmanx.

GLES 1.1 performs very well on the Pi 4. Unsure of what changes may be required to SDL2 to reflect this.

Ian

2

I just built the latest SDL snapshot under Raspberry Pi 4, with no problems. It looks like testgles is using the correct headers and libraries, and display works fine under the desktop. It doesn’t run on the console anymore though, is that expected?

3

Thanks - yes I noticed that if I just configure SDL without any additional flags then it seems to work fine in GLES. Previous advice has been to add a number of configure flags to disable OpenGL etc…

Regarding console mode, I’ve read that the KMSDRM driver inside SDL could potentially be used - I haven’t personally got it working yet with Enemy Territory but will continue trying. The Kodi team and RetroPie will certainly want SDL running in a console mode without a window manager.

4

Any news on the non-x11 support for rpi4? Currently trying to run with the legacy rpi gl driver I get the proper resolution in initialization but after that everything hangs up and nothing is displayed. With the new driver I just get “no screens detected”

5

I’ve no idea whether this will help, but a release candidate for Mesa 19.2 is available (experimentally) for the Raspberry Pi 4.

6

The libsdl fork on a experimental fkms branch on the retropie repositories
seems to work, but will need some detective work on finding out all the
dependencies… Also trying to compile the forked libsdl without using the
retropie-setup scripts fails because of missing constant definitions…

In the end I’m trying to port a ramdisk-only environment for a stage timer
I have written for the rpi4 as the dual display outputs would be quite
usefull, but dependency management with buildroot and few hour compile
times aint fun…

7

Hi all,

I too am trying to get SDL 2.0.10 to work at the console (outside of X11 environment) but I have had no joy so far.

Are there any plans to support the Raspberry Pi 4 in this set-up?

Many thanks,

Neil.

8

Hi,

are there any news for SDL2 without X11 on Pi4?

The same code using rpi driver works an all pi’s except Pi4, very strange.

On Pi4 it hangs at second or third call to SDL_RenderPresent and of course nothing is displayed on the screen, even the console from where the program is run becomes unresponsive. Only a reboot resolve the hang.

I’ve managed to get it working using X11 and dtoverlay=vc4-fkms-v3d but there are two problems:

  • background alpha is not working
  • vsync problems when window it not fullscreen, I have also smaller windows.

I’m stucked, can someone point us (those with sdl in console) to the right track?

Thanks.