Hey guys, if you have a Raspberry Pi with Raspbian and want to help adding
support for it to SDL2, feel free to try the patch attached here:
http://bugzilla.libsdl.org/show_bug.cgi?id=2005
Feedback is very welcome! Thanks!–
Gabriel.
Gabriel - First I’d like to thank you for taking the initiative in porting SDL2 to the Raspberry Pi. I tried out your patch and my initial impression is that everything is working well. I had already implemented my own RPi window creation functions, and a quick review of your patch shows very similar code. Looks good! The only issue I encountered had nothing to do with the code itself, but rather with the patch. build-scripts/config.guess failed to patch. I checked the reject file left behind and was surprised that it gave me no info as to a problem. Assuming it had something to do with whitespace, I manually changed config.guess and created my own patch file that succeeds on config.guess. Should I submit it to bugzilla in the same thread?
2013/8/11 jlev31415
**
Gabriel - First I’d like to thank you for taking the initiative in porting
SDL2 to the Raspberry Pi. I tried out your patch and my initial impression
is that everything is working well. I had already implemented my own RPi
window creation functions, and a quick review of your patch shows very
similar code. Looks good! The only issue I encountered had nothing to do
with the code itself, but rather with the patch. build-scripts/config.guess
failed to patch. I checked the reject file left behind and was surprised
that it gave me no info as to a problem. Assuming it had something to do
with whitespace, I manually changed config.guess and created my own patch
file that succeeds on config.guess. Should I submit it to bugzilla in the
same thread?
Yes! Thanks!–
Gabriel.
I’ve uploaded a “Release Candidate” patch to Bugzilla [1], implementing
Raspberry Pi support (OpenGL ES 2, ALSA, mouse/keyboard/joystick input).
There’s also a link to a set of binaries to help people test this without
having to go through the hassle of patching and compiling SDL in the
slowest way known to man (this thing should come with a Turbo button).
[1] https://bugzilla.libsdl.org/show_bug.cgi?id=2005--
Gabriel.
Looks great! I do wonder about a few things?I am shamefully lacking
in Pi just now. A plan I intend to rectify shortly. 
It might just be a Mercurial thing, I’m a little unclear about where
some of the new files are to be added. For example, I see you’re
adding lots of udev/evdev input code? Does this patch make that
available to other Linux targets? (Are there any that’d use it?
DirectFB seems a valid such target, though that wouldn’t tend to have
EGL for other platforms?)
I’d suggest that changing all of the libraries to have a prefix is
not the right solution. Seems the prefix in src/video/SDL_egl.c
(around line 28) would be better done once using another define, say
DEFAULT_SYS_EGL_PREFIX maybe:
#if SDL_VIDEO_DRIVER_RPI
#define DEFAULT_SYS_EGL_PREFIX “/opt/vc/lib/”
#else
#define DEFAULT_SYS_EGL_PREFIX “”
#endif
#define DEFAULT_EGL DEFAULT_SYS_EGL_PREFIX “libEGL.so”
?etc?
That future-proofs it somewhat. Thoughts?
Also, it seems to me that for vc_vchi_dispmanx.h being buggy, it
probably is worth getting fixed in Raspbian. 
Obviously you need
to do what you need to do to get it compiled, but I’d suggest a FIXME
tag on that for when Raspbian fixes it. Probably the bug ultimately
originates with the vendor, but it’s always best to have bugs fixed
as close to the source as possible.
I cannot wait to try this out! Ooh ooh! Can we have support for
the camera board next? 
RUNS
JosephOn Thu, Sep 26, 2013 at 11:02:06AM -0300, Gabriel Jacobo wrote:
I’ve uploaded a “Release Candidate” patch to Bugzilla [1], implementing
Raspberry Pi support (OpenGL ES 2, ALSA, mouse/keyboard/joystick input).
There’s also a link to a set of binaries to help people test this without
having to go through the hassle of patching and compiling SDL in the
slowest way known to man (this thing should come with a Turbo button).
I’ve uploaded a “Release Candidate” patch to Bugzilla [1], implementing
Raspberry Pi support (OpenGL ES 2, ALSA, mouse/keyboard/joystick input).
Nice!
I’d suggest that changing all of the libraries to have a prefix is not the
right solution. Seems the prefix in src/video/SDL_egl.c (around line 28)
would be better done once using another define, say DEFAULT_SYS_EGL_PREFIX
maybe:#if SDL_VIDEO_DRIVER_RPI
#define DEFAULT_SYS_EGL_PREFIX “/opt/vc/lib/”
#else
#define DEFAULT_SYS_EGL_PREFIX “”
#endif#define DEFAULT_EGL DEFAULT_SYS_EGL_PREFIX “libEGL.so”
?etc?That future-proofs it somewhat. Thoughts?
This stuck me as well, the current setup makes future expansion
cumbersome, I’d prefer a prefix macro as proposed here.
VittorioOn Fri, Sep 27, 2013 at 2:25 AM, T. Joseph Carter wrote:
On Thu, Sep 26, 2013 at 11:02:06AM -0300, Gabriel Jacobo wrote:
Gabriel Jacobo wrote:
I’ve uploaded a “Release Candidate” patch to Bugzilla [1], implementing
Raspberry Pi support (OpenGL ES 2, ALSA, mouse/keyboard/joystick input).
There’s also a link to a set of binaries to help people test this without
having to go through the hassle of patching and compiling SDL in the slowest
way known to man (this thing should come with a Turbo button).[1] https://bugzilla.libsdl.org/show_bug.cgi?id=2005
Gabriel.
I was able to compile dd5a807cd5ec on the Raspberry Pi and
cross-compile from a x86 VM, both with Arch.
I wanted to test the testgles program, but I had to modify it and set
the SDL_GL_CONTEXT_MAJOR_VERSION to 1 or it would create a OpenGL ES 2
context and fail on glDrawElements (because no shaders were set?).
Automatic render driver selection seems to break. I built with X11 and
it tries its OpenGL first, but it fails trying to load glBegin. It
goes on to opengles and opengles2, but they all fail too now. Skipping
opengl or selecting opengles(2) directly works. Does it not unload
OpenGL properly or is it some weird issue like loading a specific
library first?
2013/10/1 Norfanin
Gabriel Jacobo wrote:
I’ve uploaded a “Release Candidate” patch to Bugzilla [1], implementing
Raspberry Pi support (OpenGL ES 2, ALSA, mouse/keyboard/joystick input).
There’s also a link to a set of binaries to help people test this without
having to go through the hassle of patching and compiling SDL in the
slowest
way known to man (this thing should come with a Turbo button).[1] https://bugzilla.libsdl.org/show_bug.cgi?id=2005
Gabriel.
I was able to compile dd5a807cd5ec on the Raspberry Pi and
cross-compile from a x86 VM, both with Arch.I wanted to test the testgles program, but I had to modify it and set
the SDL_GL_CONTEXT_MAJOR_VERSION to 1 or it would create a OpenGL ES 2
context and fail on glDrawElements (because no shaders were set?).Automatic render driver selection seems to break. I built with X11 and
it tries its OpenGL first, but it fails trying to load glBegin. It
goes on to opengles and opengles2, but they all fail too now. Skipping
opengl or selecting opengles(2) directly works. Does it not unload
OpenGL properly or is it some weird issue like loading a specific
library first?
I haven’t tried this under X11 in the Raspberry. What’s certain is that
there’s no OpenGL support, so it’s possible it’s picking up the Mesa
software implementation? In any case you should probably disable that from
configure or remove the dev headers for OpenGL as it’s useless in this case.
Also testgles (when ran from outside X) worked fine for me without changes.
When cross compiling, which configure switches did you use?–
Gabriel.
Norfanin wrote:
I built with X11
Oops. I meant I didn’t specifically disable the use of X11’s libraries
and OpenGL. I’m not actually trying to use it.
Gabriel Jacobo wrote:
I haven’t tried this under X11 in the Raspberry. What’s certain is that
there’s no OpenGL support, so it’s possible it’s picking up the Mesa
software implementation? In any case you should probably disable that from
configure or remove the dev headers for OpenGL as it’s useless in this case.
I don’t think it matters if a driver would be installed or not, it
will always pick up the headers and libraries if they’re installed.
Was just curious if it would build successfully.
I guess I could try to remove it, but I bet there’s something that has
a dependency on it. I’ll just disable OpenGL/X the next time I build
SDL for it.
Also testgles (when ran from outside X) worked fine for me without changes.
That’s interesting. Why would it fail on me? Does testgles create a
OpenGL ES 1 context for you?
When cross compiling, which configure switches did you use?
–host=arm-raspberry-linux-gnueabihf --target=arm-raspberry-linux-gnueabihf
Plus some include and lib paths to the headers and libraries that I
copied over. The configure script sees the raspberry-linux in the host
and sets up the SDL_VIDEO_DRIVER_RPI.
Is there a way to tell the configure script to force the Raspberry Pi
settings in case the host would not match?
FYI, on a fresh Raspbian install, I needed to add the following packages to
build SDL:
libasound2-dev, libudev-dev, libdbus-1-devOn Wed, Aug 7, 2013 at 7:16 PM, Gabriel Jacobo wrote:
Hey guys, if you have a Raspberry Pi with Raspbian and want to help adding
support for it to SDL2, feel free to try the patch attached here:
http://bugzilla.libsdl.org/show_bug.cgi?id=2005Feedback is very welcome! Thanks!
–
Gabriel.
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Thanks, I’m ading libdbus-1-dev to the README.
2013/10/3 Sam Lantinga
FYI, on a fresh Raspbian install, I needed to add the following packages
to build SDL:
libasound2-dev, libudev-dev, libdbus-1-dev
Thanks, I’m ading libdbus-1-dev to the README.
Hi gabomdq et all,
I’ve been struggling for the last days to compile a working version with console based from Mercurial sources, without success.
The binaries you posted here https://www.dropbox.com/s/9fndtw6zs16ptgg/SDL2-raspberrypi.tar.gz seem to work, however.
My building process is pretty simple: I just clone the Mercurial sources, then ./configure --disable-video-x11,
then make and then sudo make install. Nothing special.
No errors, raspberrypi seems to be detected by the configure script, the resulting Makefile can be viewed here:
http://paste.ubuntu.com/6211376/
However, resulting SDL2.0 installation won’t run any of the test programs with graphics.
Code:
pi at raspberrypi ~/src/SDL/test $ ./testdraw2
Window requested size 640x480, got 1360x768
Couldn’t create renderer: Couldn’t find matching render driver
pi at raspberrypi ~/src/SDL/test $ ./testoverlay2
ERROR: Couldn’t set create renderer: Couldn’t find matching render driver
pi at raspberrypi ~/src/SDL/test $ ./testgles
ERROR: No OpenGL ES support on this system
pi at raspberrypi ~/src/SDL/test $ ./testsprite2
Couldn’t create renderer: Couldn’t find matching render driver
What am I doing wrong here?
I’m on Raspbian Wheezy, just updated (apt-get update && apt-get upgrade) a few days ago.
The config.h would be more useful than the Makefile. Makefiles
generated by autoconf/libtool are not exactly meant for human
consumption.
I can confirm that OpenGL ES support in the test/ dir is gonna be
broken on the Pi. We’ve been discussing that problem in another
thread in that what the test folder does to determine whether or not
it can compile OpenGL ES or not is fundamentally broken. Haven’t
got any particularly brilliant fixes for you yet on that one.
Actually, I just went and installed an Ubuntu in VMWare. The
configure script in test fails utterly to find my OpenGL or OpenGL ES
and will build neither. That script is quite broken, it seems.
As for anything else on the Pi, I haven’t got one here to test.
JosephOn Tue, Oct 08, 2013 at 10:28:02PM +0000, vanfanel wrote:
Hi gabomdq et all,
I’ve been struggling for the last days to compile a working version with console based from Mercurial sources, without success.
The binaries you posted here https://www.dropbox.com/s/9fndtw6zs16ptgg/SDL2-raspberrypi.tar.gz seem to work, however.My building process is pretty simple: I just clone the Mercurial sources, then ./configure --disable-video-x11,
then make and then sudo make install. Nothing special.
No errors, raspberrypi seems to be detected by the configure script, the resulting Makefile can be viewed here:http://paste.ubuntu.com/6211376/
However, resulting SDL2.0 installation won’t run any of the test programs with graphics.
Code:
pi at raspberrypi ~/src/SDL/test $ ./testdraw2
Window requested size 640x480, got 1360x768
Couldn’t create renderer: Couldn’t find matching render driverpi at raspberrypi ~/src/SDL/test $ ./testoverlay2
ERROR: Couldn’t set create renderer: Couldn’t find matching render driverpi at raspberrypi ~/src/SDL/test $ ./testgles
ERROR: No OpenGL ES support on this systempi at raspberrypi ~/src/SDL/test $ ./testsprite2
Couldn’t create renderer: Couldn’t find matching render driverWhat am I doing wrong here?
I’m on Raspbian Wheezy, just updated (apt-get update && apt-get upgrade) a few days ago.
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
vanfanel wrote:
Hi gabomdq et all,
I’ve been struggling for the last days to compile a working version with console based from Mercurial sources, without success.
The binaries you posted here https://www.dropbox.com/s/9fndtw6zs16ptgg/SDL2-raspberrypi.tar.gz seem to work, however.My building process is pretty simple: I just clone the Mercurial sources, then ./configure --disable-video-x11,
then make and then sudo make install. Nothing special.
No errors, raspberrypi seems to be detected by the configure script, the resulting Makefile can be viewed here:What am I doing wrong here?
I’m on Raspbian Wheezy, just updated (apt-get update && apt-get upgrade) a few days ago.
I assume you read the README 
so it’s fair to say that you have the required build packages installed…
Can you post your config.log and the generated SDL_config.h ?
You can also run testrendercopyex --info all (from the test directory) and it’ll tell you most of the relevant bits that got included in the graphic part of SDL.------------------------
Gabriel Jacobo
mdqinc.com
Just in case you doubt:
Code:
pi at raspberrypi ~/src/SDL $ sudo apt-get install libudev-dev libasound2-dev libdbus-1-dev
Reading package lists… Done
Building dependency tree
Reading state information… Done
libasound2-dev is already the newest version.
libdbus-1-dev is already the newest version.
libudev-dev is already the newest version.
The following packages were automatically installed and are no longer required:
libportmidi0 libsdl-ttf2.0-0 libsmpeg0 python-numpy python-support
Use ‘apt-get autoremove’ to remove them.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
pi at raspberrypi ~/src/SDL $ sudo apt-get install libraspberrypi0 libraspberrypi-bin libraspberrypi-dev
Reading package lists… Done
Building dependency tree
Reading state information… Done
libraspberrypi-bin is already the newest version.
libraspberrypi-dev is already the newest version.
libraspberrypi0 is already the newest version.
The following packages were automatically installed and are no longer required:
libportmidi0 libsdl-ttf2.0-0 libsmpeg0 python-numpy python-support
Use ‘apt-get autoremove’ to remove them.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Here’s my config.log:
http://paste.ubuntu.com/6215714/
And here’s the generated SDL_config.h:
http://paste.ubuntu.com/6215730/
This is what testrendercopyex --info all says:
Code:
Built-in video drivers: RPI, dummy
Video driver: RPI
Number of displays: 1
Display 0: 0
Bounds: 1360x768 at 0,0
Current mode: 1360x768 at 60Hz, 32 bits-per-pixel (SDL_PIXELFORMAT_ABGR8888)
Red Mask = 0x000000ff
Green Mask = 0x0000ff00
Blue Mask = 0x00ff0000
Alpha Mask = 0xff000000
Fullscreen video modes:
Mode 0: 1360x768 at 60Hz, 32 bits-per-pixel (SDL_PIXELFORMAT_ABGR8888)
Red Mask = 0x000000ff
Green Mask = 0x0000ff00
Blue Mask = 0x00ff0000
Alpha Mask = 0xff000000
Built-in render drivers:
Renderer opengl:
Flags: 0x0000000E (Accelerated | PresentVSync | 0x00000008)
Texture formats (1): ARGB8888
Renderer opengles2:
Flags: 0x0000000E (Accelerated | PresentVSync | 0x00000008)
Texture formats (4): ABGR8888, ARGB8888, RGB888, BGR888
Renderer opengles:
Flags: 0x00000006 (Accelerated | PresentVSync)
Texture formats (1): ABGR8888
Renderer software:
Flags: 0x00000009 (0x00000001 | 0x00000008)
Texture formats (8): RGB555, RGB565, RGB888, BGR888, ARGB8888, RGBA8888, ABGR8888, BGRA8888
Window requested size 640x480, got 1360x768
Couldn’t create renderer: Couldn’t find matching render driver
As you can see, it has the same error as the other test apps at the end 
vanfanel wrote:
Couldn’t create renderer: Couldn’t find matching render driver
The issue with thestgles not finding OpenGL ES was solved by Gabriel
Jacobo a few hours ago with changeset 7995e0920bf9.
You might also want to use --disable-video-opengl for now on the
Raspberrry Pi because that is untested and apparently has issues. It
seems that once an attempt is made to load the GL library, the loading
of the GL ES libraries fails. Alternatively, you can set the
environment variable SDL_RENDER_DRIVER to opengles or opengles2 to do
a manual selection.
The only difference I can spot is that you have the OpenGL headers
installed, and somehow that can be causing problems (not sure why, because
the Raspberry Pi video driver is hardcoded to use EGL)…so, that would be
the first thing to try out, disable OpenGL as others have suggested.
2013/10/9 vanfanel > **
Just in case you doubt:
Code:
pi at raspberrypi ~/src/SDL $ sudo apt-get install libudev-dev
libasound2-dev libdbus-1-dev
Reading package lists… Done
Building dependency tree
Reading state information… Done
libasound2-dev is already the newest version.
libdbus-1-dev is already the newest version.
libudev-dev is already the newest version.
The following packages were automatically installed and are no longer
required:
libportmidi0 libsdl-ttf2.0-0 libsmpeg0 python-numpy python-support
Use ‘apt-get autoremove’ to remove them.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
pi at raspberrypi ~/src/SDL $ sudo apt-get install libraspberrypi0
libraspberrypi-bin libraspberrypi-dev
Reading package lists… Done
Building dependency tree
Reading state information… Done
libraspberrypi-bin is already the newest version.
libraspberrypi-dev is already the newest version.
libraspberrypi0 is already the newest version.
The following packages were automatically installed and are no longer
required:
libportmidi0 libsdl-ttf2.0-0 libsmpeg0 python-numpy python-support
Use ‘apt-get autoremove’ to remove them.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.Here’s my config.log:
http://paste.ubuntu.com/6215714/
And here’s the generated SDL_config.h:
http://paste.ubuntu.com/6215730/
This is what testrendercopyex --info all says:
Code:
Built-in video drivers: RPI, dummy
Video driver: RPI
Number of displays: 1
Display 0: 0
Bounds: 1360x768 at 0,0
Current mode: 1360x768 at 60Hz, 32 bits-per-pixel
(SDL_PIXELFORMAT_ABGR8888)
Red Mask = 0x000000ff
Green Mask = 0x0000ff00
Blue Mask = 0x00ff0000
Alpha Mask = 0xff000000
Fullscreen video modes:
Mode 0: 1360x768 at 60Hz, 32 bits-per-pixel (SDL_PIXELFORMAT_ABGR8888)
Red Mask = 0x000000ff
Green Mask = 0x0000ff00
Blue Mask = 0x00ff0000
Alpha Mask = 0xff000000
Built-in render drivers:
Renderer opengl:
Flags: 0x0000000E (Accelerated | PresentVSync | 0x00000008)
Texture formats (1): ARGB8888
Renderer opengles2:
Flags: 0x0000000E (Accelerated | PresentVSync | 0x00000008)
Texture formats (4): ABGR8888, ARGB8888, RGB888, BGR888
Renderer opengles:
Flags: 0x00000006 (Accelerated | PresentVSync)
Texture formats (1): ABGR8888
Renderer software:
Flags: 0x00000009 (0x00000001 | 0x00000008)
Texture formats (8): RGB555, RGB565, RGB888, BGR888, ARGB8888,
RGBA8888, ABGR8888, BGRA8888
Window requested size 640x480, got 1360x768
Couldn’t create renderer: Couldn’t find matching render driverAs you can see, it has the same error as the other test apps at the end [image:
Sad]
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
–
Gabriel.
Ok, configuring with
Code:
./configure --disable-video-x11 --disable-video-opengl
and re-building seems to have done the trick. I also tried to omit “–disable-video-opengl” but the resulting libSDL2 needs to have the SDL_RENDER_DRIVER set to opengles or opengles2 to work.
I think this info should be included in the README-raspberrypi file, too.
It’s my understanding that, even if I use --disable-video-opengl, I still get the opengles and opengles2 anyway, and “desktop” GL (OpenGL) is a software-only implementation on the Pi, so maybe it should be disabled if the Pi is detected in the configure script.
Thanks for your responses, now I’m a happy SDL2 user on the Pi
You should?OpenGL and OpenGL ES are considered different as far as
SDL is concerned. Which is interesting since SDL kind of treats them
the same internally.
JosephOn Thu, Oct 10, 2013 at 09:34:29AM +0000, vanfanel wrote:
Ok, configuring with
Code:
./configure --disable-video-x11 --disable-video-opengland re-building seems to have done the trick. I also tried to omit “–disable-video-opengl” but the resulting libSDL2 needs to have the SDL_RENDER_DRIVER set to opengles or opengles2 to work.
I think this info should be included in the README-raspberrypi file, too.
It’s my understanding that, even if I use --disable-video-opengl, I still get the opengles and opengles2 anyway, and “desktop” GL (OpenGL) is a software-only implementation on the Pi, so maybe it should be disabled if the Pi is detected in the configure script.
Thanks for your responses, now I’m a happy SDL2 user on the Pi
Even if some SDL2.0 games are now building and working fine on my RaspberryPi, some are giving me linking errors. For example, Commander Genius (
Code:
) compiles without problems, but it has undefined references in the SDL2.0 libraries upon linking:
Code:
[100%] [100%] Building CXX object CMakeFiles/CommanderGenius.dir/src/ConfigHandler.cpp.o
Building CXX object CMakeFiles/CommanderGenius.dir/src/misc.cpp.o
Linking CXX executable …/Build/LINUX/CommanderGenius
/usr/local/lib/libSDL2.so: undefined reference to vc_dispmanx_resource_delete' /usr/local/lib/libSDL2.so: undefined reference tovc_dispmanx_update_submit’
/usr/local/lib/libSDL2.so: undefined reference to vc_dispmanx_element_change_attributes' /usr/local/lib/libSDL2.so: undefined reference tovc_dispmanx_resource_write_data’
/usr/local/lib/libSDL2.so: undefined reference to vc_dispmanx_display_open' /usr/local/lib/libSDL2.so: undefined reference tovc_dispmanx_update_submit_sync’
/usr/local/lib/libSDL2.so: undefined reference to bcm_host_init' /usr/local/lib/libSDL2.so: undefined reference tovc_dispmanx_resource_create’
/usr/local/lib/libSDL2.so: undefined reference to graphics_get_display_size' /usr/local/lib/libSDL2.so: undefined reference tovc_dispmanx_update_start’
/usr/local/lib/libSDL2.so: undefined reference to vc_dispmanx_element_remove' /usr/local/lib/libSDL2.so: undefined reference tovc_dispmanx_rect_set’
/usr/local/lib/libSDL2.so: undefined reference to `vc_dispmanx_element_add’
collect2: ld returned 1 exit status
distcc[1403] ERROR: compile (null) on localhost failed
make[2]: *** […/Build/LINUX/CommanderGenius] Error 1
make[1]: *** [CMakeFiles/CommanderGenius.dir/all] Error 2
make: *** [all] Error 2
I tried the binary SDL2.0 too, and I get the same error, so it’s not my SDL2.0 build. Maybe libSDL2.0 is looking for Video Core support libs in the wrong location? On latest Raspbian, these are in /opt/vc/libs, with corresponding includes in /opt/vc/include.
Any hint on how to fix these linking problems?