On 31 December 2011 02:14, Josselin Mouette <[email protected]> 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. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/cabsevwvvyhfbdo2zuxoloersjerqmtvdfx6+q5u+uqjcx-b...@mail.gmail.com
