Thank you for your considerate reply. The information you provided was very enlightening.
With regards to OpenGL support, OpenGL ES, I have settled on OpenGL ES 2 the only API I am willing to use. It’s the only API that works across every single platform.
I will look into you suggestion to use SDL_VIDEO_EGL_DRIVER and see if I can get a single SDL2 lib working on raspberry that can create and display a window on both RPI and X11.
Thanks again.
Someone just informed me about the VC4 driver for the Raspberry Pi and I have to admit that I totally forgot about it and that I only tested with the old driver (usually found in /opt/vc). I’m sorry if I caused any confusion, should you already use the new driver.
I’m going to have a look at it and check if what I said still makes any sense.
After compiling Mesa with vc4 support (took the Raspberry Pi only a few hours) I got OpenGL working with the new driver under X11.
It looks like the vc4-(f)kms-v3d overlays disable the old, firmware-side driver and this also affects the current version of the SDL2 rpi video driver, causing it to error on initialization. The upside is that the default SDL2 package from the repository works with X11 and it’s hardware accelerated.
SDL probably needs a DRM/KMS video driver to get it working without X11 in that configuration. Although I didn’t check the if the other drivers offer a solution.
@ChliHug Thanks for looking into this. I think what I’ve settled on is just compiling a version that supports the RPI driver and supports OpenGL ES 2. The pi is already limited in it’s hardware, and I think when running possibly cpu/gpu/memory intensive SDL2 programs, it’s probably best to have as little else also running such as X11 and a DE like XFCE. In other words a pi booting straight to the command line is definitely going to result in SDL2 apps running with less trouble.
Also thanks for that shell script trick to stop key presses from potentially executing commands. I haven’t tried it out yet, but I trust in you that it will work.
Indeed, which is why I use that mode for my SDL app - it makes a huge difference to performance and it’s convenient for my users. However I haven’t succeeded in making direct OpenGL calls via SDL work, for example even the trivial program listed here doesn’t run on the Raspberry Pi with the ‘GL Driver’ enabled in raspi-config. Can you suggest why?
Richard.
I have no problems using OpenGL with vc4-kms-v3d or vc4-fkms-v3d, though I’m on Arch Linux and built Mesa myself to get vc4 support. I have not used Raspbian yet but plan to do so. Perhaps there is something specific to their packages.
How do these direct calls fail? Any error messages?
I’m guessing glxinfo does report Gallium on VC4 in the OpenGL renderer string? I can’t believe they would configure their distribution otherwise. Does the application link directly with libGL.so from Mesa?
Can’t think of anything else at this moment, but there must be a hint somewhere that will point in the direction of the issue.
@rtrussell I think you need to request OpenGL ES in order to get a window and then valid context. You also have to set your SDL GL ATTRIBUTES before you call SDL_Init(SDL_INIT_VIDEO). Finally, you need to compile SDL2 from source if you want to run without X11. The libSDL2-0.so.0 in the jessie debian repos isn’t built with the RPI video driver.
SDL_GL_SetAttribute(SDL_GL_CONTEXT_PROFILE_MASK, SDL_GL_CONTEXT_PROFILE_ES);
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 2);
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MINOR_VERSION, 0);
SDL_GL_SetAttribute(SDL_GL_RED_SIZE, 8);
SDL_GL_SetAttribute(SDL_GL_GREEN_SIZE, 8);
SDL_GL_SetAttribute(SDL_GL_BLUE_SIZE, 8);
SDL_GL_SetAttribute(SDL_GL_ALPHA_SIZE, 8);
SDL_GL_SetAttribute(SDL_GL_ACCELERATED_VISUAL, 1);
SDL_Init(SDL_INIT_VIDEO);
then later
SDL_CreateWindow(…)
SDL_CreateContext(…)
[quote=“Anthony_Walter, post:16, topic:22621”]
I think you need to request OpenGL ES in order to get a window and then valid context. You also have to set your SDL GL ATTRIBUTES before you call SDL_Init(SDL_INIT_VIDEO). Finally, you need to compile SDL2 from source if you want to run without X11.[/quote]
But, as I’ve said, I don’t want to run without X11! My app runs perfectly well with the repo version of SDL2 and the (VC4) GL Driver enabled in raspi-config, which is what I want. But code that accesses OpenGL functions via SDL (which works perfectly in Windows, Ubuntu, Mac OS-X and Android) does not work on the Raspberry Pi.
glxinfo reports “Gallium 0.4 on VC4 V3D 2.1”
I’m not linking with anything except SDL2 and SDL2_ttf:
-L/usr/lib/ -lSDL2 -lSDL2main -lSDL2_ttf -ldl -lm
I should add that I’m getting this message in the console: “libGL error: MESA-LOADER: failed to retrieve device information”. I’ve assumed it’s not relevant because I get the same message from glxinfo and glxgears (which works), but maybe it is.
(Just hopping in here to say it’s definitely possible to build an SDL that supports both X11 and the non-X11 targets on a RPi in one library, and it should do that by default, and it should dynamically load the appropriate one…if Xlib isn’t available, or it is but there’s no X server running, SDL should move on to the next possible video target. It’s possible to misbuild the library because system headers are missing so you don’t get a target that you should, but there’s no scenario where you should ever need to build two different copies of SDL to support this.)
Note that setting of GL attributes has to happen after SDL_Init because driver initialization will reset them to the defaults.
Yeah, I don’t think the error is a problem. Seems to be a info parsing error in the DRM part and if glxgears works it should not affect SDL.
So you’re loading all GL functions with SDL_GL_GetProcAddress then? It could be that this pulls functions from the wrong library or for the wrong driver, but I have no idea how that could happen. There’s just one library around, I think.
I’m trying to get the VC4 driver to run on Raspbian and do some tests, but it’s going to take a while. Have to build Mesa again because of my old Raspberry Pi.
@ChliHug Also I should note that SDL2 on osx is the only version I have which returns a nil pointer when calling SDL_GL_GetProcAddress with a bad or unsupported name.
Pretty sure. I can’t see why it would fail on OS X, but that platform is completely foreign to me. Perhaps your settings conflict somehow with the defaults?
@ChliHug I did another test and it seems like you are right. SDL_GL_ATTTRIB* should be after SDL_Init(SDL_INIT_VIDEO)
That’s good to know, thanks, although I am puzzled that it contradicts the comments earlier in the thread. Checking ChliHug’s link I am quite concerned that the README at Mercurial implies that the latest RPi version “Works without X11” and uses “Hardware accelerated OpenGL ES 2.x”. If the Raspbian Jessie repo were to be updated to this, my app would stop working and I would have a bunch of unhappy users!
I have never understood how the ‘repository’ versions of SDL get built and maintained. The official download page says “Please contact your distribution maintainer for updates” but how? If I want to ensure that future repo updates for the RPi maintain support for X11/OpenGL(VC4) - as the current 2.0.2 does and my application requires - to whom should I make representations?
Oh, compiling them together is no problem. It’s just that there are some conflicts when using them. Just to be clear which driver supports what:
The rpi SDL video driver was written back in 2013 for the old firmware-side driver. It will only ever be relevant for that driver and I’m sure the readme will be updated eventually to reflect that. X11 was never really a thing here. The libsdl2 package in the Raspbian repository was compiled without it.
The new driver can be accessed with the x11 SDL video driver, both of which you seem to be already using… or trying to use. Still working on the issue with your OpenGL calls. 
I don’t think that the new SDL version will cause any issues for you. The new Debian Stable version “Stretch” that was just released apparently has SDL 2.0.5 in it. If you think the package should be handled differently, you would have to contact the maintainer of the package and explain the issue. This being Debian, I doubt you could convince them to change anything now unless there’s some huge issue with the software. No idea when Raspbian will switch to Stretch, though.
That’s good to know. I don’t mind adding a hint or two, if it proves to be necessary. Currently all I have is:
SDL_SetHint (SDL_HINT_RENDER_DRIVER, “opengl”) ;
which is primarily there for Windows. So long as the Raspbian repository version of SDL2 continues to work with X11 and the OpenGL VC4 driver, I’m happy.
I was able to test this with a Raspberry Pi 3, the latest Raspbian packages, and vc4-kms-v3d. OpenGL seems to work correctly for me.
Did you manage to fix it? I’m still guessing possible link or function loading issues. Does anything significant show up if you execute ldd sdl2app?
I haven’t got back to it I’m afraid, it will probably be a project for the cooler/darker months!
As far as the ldd command is concerned I don’t really know what I should be looking for. The only entry containing ‘gl’ is this:
libwayland-egl.so.1 => /usr/lib/arm-linux-gnueabihf/libwayland-egl.so.1 (0x76a11000)
Richard.
Just to tie up loose ends, I’m pretty sure that my problem with getting OpenGL code to run on the Raspberry Pi is an ABI mismatch. My code assumes the same ABI as Android, which passes floating-point values in integer registers (‘soft float’ ABI); Raspbian, however, passes floats in the VFP registers (‘hard float’ ABI).
Debian uses the ‘soft float’ ABI so it may well be that my code would work unmodified on that OS, although I haven’t tried it.