Bug#793111: OpenGL ES2 support does not work with OpenGL support enabled

[Prof. Dr. Gundolf Kiefer]

Hello Manuel,

I understand well that splitting the package is not ideal.

> It looks to me that this is a problem that would be better solved
> upstream, not only for Debian (and derivatives).  If there's a problem
> that can be solved while having the two backends it would be ideal,
> otherwise the code on that platform(*) should disable support for the
> backends which do not work properly, and not claim to support that
> renderer.
> 
> (*) Or, perhaps it works in general in armhf, but not on that
> particular hardware.

The status as I observed is that both backends work. But on armhf,
OpenGL ES2 only works, if OpenGL (whithout 'ES2') is disabled during
compilation. My hardware (A20 SoC with Mali 400) only supports
OpenGl ES2, and this may be the case for many ARM-based systems.

Hence, disabling OpenGl (without 'ES2') for armhf may be a good
temporary solution. (I hope nobody kills me for this suggestion.)

I have not tested unreleased upstream code yet. Who would be the best
person to contact about this issue upstream?

Regards,

Gundolf Kiefer


On Wed, 21 Oct 2015 22:25:16 +0100
"Manuel A. Fernandez Montecelo" <manuel.montezelo at gmail.com> wrote:

> Hello,
> 
> 2015-09-21 11:18 GMT+01:00 Prof. Dr. Gundolf Kiefer
> <gundolf.kiefer at hs-augsburg.de>:
> > On Fri, 18 Sep 2015 20:49:21 +0100
> > "Manuel A. Fernandez Montecelo" <manuel.montezelo at gmail.com> wrote:
> >
> >> Control: tags -1 + moreinfo
> >>
> >>
> >> 2015-07-21 12:22 Prof. Dr. Gundolf Kiefer:
> >> >Package: libsdl2 (source package)
> >> >Version: 2.0.2+dfsg1-6
> >> >
> >> >It appears that in the present version (2.0.2) of libSDL2,
> >> >hardware acceleration based on OpenGL ES2 does not to work properly if
> >> >both OpenGL and OpenGL ES2 support are compiled in at the same time.
> >> >
> >> >I am using libSDL2 on an embedded Linux board (Cubietruck, A20 SoC,
> >> >Mali 400 GPU), running under Debian Jessie, architecture 'armhf'.
> >> >
> >> >With the stock Debian package, the renderer 'opengles2' is available,
> >> >i.e. reported by 'SDL_GetNumRenderDrivers'/'SDL_GetRenderDriverInfo',
> >> >but not functional on my system. When selected manually, 'SDL_CreateRenderer'
> >> >fails with the SDL error "GLX is not supported".
> >>
> >> How do you select it manually, in code or with environment variables?
> >
> > In code. The invokation is
> >
> >   sdlRenderer = SDL_CreateRenderer (sdlWindow, 1, 0);
> >
> > after
> >
> >   SDL_GetRenderDriverInfo (1, &renInfo);
> >
> > returned the string "opengles2" in the field 'SDL_RendererInfo
> > renInfo.name'.
> >
> >> Also, do you have any implementation of the relevant package installed,
> >> like "libgles2-mesa:armhf" (there are specific packages for some cards)?
> >
> > Of course. Also, I tried to enforce the loading of the correct
> > driver using LD_PRELOAD/LD_LIBRARY_PATH, without success. On the other
> > hand, after compiling the Debian package with the option
> > '--disable-video-opengl', everything worked out-of-the-box on the same
> > machine and same installation.
> >
> > (For completeness: I used the Mali 400 driver from
> > https://github.com/linux-sunxi/sunxi-mali.git, but this should not
> > matter in this case.)
> >
> > Could the issue perhaps be related to conflicting GL and GLES2 headers?
> >
> > From src/video/SDL_video.c:42:
> >
> > ...
> >
> > /* GL and GLES2 headers conflict on Linux 32 bits */
> > #if SDL_VIDEO_OPENGL_ES2 && !SDL_VIDEO_OPENGL
> > #include "SDL_opengles2.h"
> > #endif /* SDL_VIDEO_OPENGL_ES2 && !SDL_VIDEO_OPENGL */
> 
> Sorry to not come back to you earlier, but I have been and continue to
> be busy with other Debian work (and not only Debian) lately.
> 
> Also, I do not own any arm hardware to test this myself.
> 
> It looks to me that this is a problem that would be better solved
> upstream, not only for Debian (and derivatives).  If there's a problem
> that can be solved while having the two backends it would be ideal,
> otherwise the code on that platform(*) should disable support for the
> backends which do not work properly, and not claim to support that
> renderer.
> 
> (*) Or, perhaps it works in general in armhf, but not on that
> particular hardware.
> 
> I am not very keen on splitting packages, this was done in the past
> for example with sound backends, and I think that overall it was a bit
> of a pain in the packaging side and in the integration with other
> parts of Debian.
> 
> 
> Another thing is that I am not sure if they have addressed that in
> unreleased code.  There have not been any releases for years, we have
> been waiting for them to release 2.0.4 for months/years now, packaging
> random versions from VCS is problematic.  I don't know if you have
> tested if this works fine with the latest upstream VCS code?
> 
> 
> Cheers.