including both GL/gl.h and cogl/cogl.h fails on armel and armhf

[Konstantinos Margaritis]

On 31 December 2011 02:14, Josselin Mouette <joss at debian.org> wrote:
> It is cogl which is at fault. Being built against GLES breaks basically
> everything that depends on it.

armel/armhf only support GLES in hardware so it does make sense to
enable it for those platforms.
We should try and fix that support where broken, not disable it.

>> The cause appears to be cogl being built against GLES2 on arm* while
>> it's built against the regular GL on everything else. Am I correct in
>> thinking this is done to better support embeeded GPUs?
>
> Yes, but so far it only works with proprietary drivers.

Exactly, and until that changes we have to at least make sure that the
available GLES proprietary drivers support the platform. Eg,
clutter+cogl works almost 100% on our iMX515 GLES drivers, which we
depend on to make Gnome3 hw acceleration working.

>> Would the correct course of action be to try and patch toonloop to also
>> use GLES2 on armel and armhf?
>
> No, the best course of action is to revert the change that broke cogl on
> arm. Rico, can you revert your related commits?

Please do not suggest such things, Until a new armel/armhf system is
released that actually supports proper GL in hardware(the iMX6 is
supposed to do that, next year), suggesting reverting to GL instead of
GLES is totally wrong. So, yes, the proper fix is to try and patch
toonloop to use GLES2 on armel/armhf. Otherwise, we might as well not
build the packages for arm* at all, as software GL on those platforms
is a  joke.

Regards

Konstantinos

PS. Speaking with both armhf maintainer hat on and representing an ARM
product vendor, and we definitely want GLES working, GL is just out of
the question.