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

[Manuel A. Fernandez Montecelo]

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.
-- 
Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com>