The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.

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.

On Thu, Sep 26, 2013 at 11:02:06AM -0300, Gabriel Jacobo wrote:

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 2 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*

Joseph


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

On Fri, Sep 27, 2013 at 2:25 AM, T. Joseph Carter
wrote:

Nice!


This stuck me as well, the current setup makes future expansion
cumbersome, I'd prefer a prefix macro as proposed here.
Vittorio
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

2013/10/1 Norfanin


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.

Gabriel Jacobo wrote:

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?
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Norfanin wrote:

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 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.


That's interesting. Why would it fail on me? Does testgles create a
OpenGL ES 1 context for you?


--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?
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

FYI, on a fresh Raspbian install, I needed to add the following packages to build SDL:libasound2-dev, libudev-dev, libdbus-1-dev




On Wed, Aug 7, 2013 at 7:16 PM, Gabriel Jacobo wrote:

Thanks, I'm ading libdbus-1-dev to the README.

2013/10/3 Sam Lantinga


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.



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.

Joseph


On Tue, Oct 08, 2013 at 10:28:02PM +0000, vanfanel wrote:


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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.

Just in case you doubt:



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:



As you can see, it has the same error as the other test apps at the end

vanfanel wrote:

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.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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




--
Gabriel.

Ok, configuring with



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. :)

Joseph


On Thu, Oct 10, 2013 at 09:34:29AM +0000, vanfanel wrote:

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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 (https://github.com/gerstrong/Commander-Genius.git) compiles without problems, but it has undefined references in the SDL2.0 libraries upon linking:



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?

2013/10/10 vanfanel


Not sure how the build process works for this game, make sure that it's using the output of sdl2-config --libs to set up the linker properly (also verify that sdl2-config --libs includes -L/opt/vc/lib -lbcm_host) 



--
Gabriel.

I got to compile and link the game after configuring the linker, as you told me. (It has some problems the author seems to be fixing, but it will eventually work).
I've also updated to the latest mercurial libSDL2.

However, I'm trying to compile it with GLES support, and I've come to another problem:
I uninstalled OpenGL packages (MESA stuff) on my Pi, since it was causing trouble with many other apps detecting GL/gl.h, wich is useless on the Pi, but even if I configure libSDL2 with:



...I still get "/usr/local/include/SDL2/SDL_opengl.h" installed on my system, wich in turn includes "GL/gl.h", wich is plain wrong.

I got to compile and link the game after configuring the linker, as you told me. (It has some problems the author seems to be fixing, but it will eventually work).
I've also updated to the latest mercurial libSDL2.

However, I'm trying to compile it with GLES support, and I've come to another problem:
I uninstalled OpenGL packages (MESA stuff) on my Pi, since it was causing trouble with many other apps detecting GL/gl.h, wich is useless on the Pi, but even if I configure libSDL2 with:



...I still get "/usr/local/include/SDL2/SDL_opengl.h" installed on my system, wich in turn includes "GL/gl.h", wich is plain wrong, as some apps will try to include it.
Maybe it's not SDL2's fault but the apps fault, since they assume desktop GL instead of GLES, so SDL2_opengl.h must be present anyway, even if there's no GL/gl.h in the system?