Edit: The following was written when I didn’t remember the VC4 driver. Things might not make sense.
For reference, there’s the README-raspberrypi.md in the SDL source that describes some of these issues. Not in very much detail, but it may give some hints on what is supported and what not.
The distribution repositories usually have the default build configuration which never includes the Raspberry Pi driver. I also think that there should be a separate package if a distribution wants to offer the rpi driver.
I’ve spotted an issue with the default GL attributes that prevents OpenGL ES contexts from being created when SDL is built with OpenGL. The version and profile get set to OpenGL 2.1 and that’s obviously problematic in an OpenGL ES environment. I currently don’t see a way to workaround this one without modifying the application or SDL (unless the developer of the application was smart and built some options into it). This may need some augmenting with environment variables or the hint system.
There’s the option to build without OpenGL. Then the attribute defaults will work for the Raspberry Pi. Sadly, SDL applications that want to use OpenGL have a bad time now, but software rendering on this slow chip is painful anyway.
The next problem you’ll see now is that the EGL driver selection is a bit stubborn. If the Raspberry Pi is detected as the host, the default library paths get set to the Raspberry Pi ones at compile time. When launching an SDL application under X11, it tries to load with the Raspberry Pi EGL library which will fail. If you get the “Could not get EGL display” error, set the
SDL_VIDEO_EGL_DRIVER environment variable to
libEGL.so.1 or whatever the name is on your system. This forces SDL2 to load the library that goes with X11 instead. I got my test programs to work this way.
configure command I used:
./configure --host=armv6-raspberry-linux-gnueabihf --prefix=/usr --disable-rpath --disable-video-opengl
# Some other stuff I disabled because I don't need it.
--disable-esd --disable-oss --disable-sndio --disable-pulseaudio --disable-nas --disable-video-wayland --disable-video-wayland-qt-touch --disable-wayland-shared --disable-video-mir
Keyboard input comes from evdev. This allows for a more robust event handling instead of using the terminal stuff, but this also means that the terminal inputs don’t get consumed. I guess this is a somewhat difficult issue to solve because a library can’t just gobble up stdin. The terminal/console settings are very finicky and not a good solution in my opinion.
Like that program someone made, you can also use
script to capture stdin as long as your SDL2 application runs:
script -q -c "/usr/bin/sdl2application" /dev/null
Input does not get suppressed, but the shell won’t interpret the key presses as commands.