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