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

[Konstantinos Margaritis]

On 31 December 2011 11:50, Josselin Mouette <joss at debian.org> wrote:
> I object, on principle, to spend time doing specific changes to our
> packages for a platform for which only exist proprietary drivers. We
> have better things to do than serving as a supermarket on which to base
> proprietary operating systems.

Some reasons why your objection is irrelevant:

1. Crippling a platform won't help support it.
2. Binary drivers exist because the ARM ecosystem has been such that
it never needed -until now- free drivers. Things are moving in the
right direction but it will take time -still less time than it took
x86 to have working 3d drivers.
3. Even if free drivers are released/reverse-engineered they would
*still* be GLES drivers and NOT GL, so changes like that to toonloop
would still have to be made.
4. May I remind you that for many years x86 did not have *any* free 3d
drivers, but still packages were built with GL support.

In anycase, it's only a case of consistency, clutter is already built
with GLES-only support for armel/armhf.

> It looks to me that these entire platforms are a joke.

I have no time for silly arguments, sorry, keep such comments to yourself.

> Is there existing, real hardware on which the Debian armel/armhf ports
> can work out of the box? With a stock kernel? And no additional drivers
> outside of Debian for basic functionality?

We're working on that for the past year, for some platforms support is
already there in mainline (omap4), and we're working on imx5 stuff.
Dunno about the rest.

In fact, I'm personally working in getting a working efika kernel
image, based on 3.2 mainline + minimal patching to get d-i working and
able to install armhf there. As usual display is the source of
problems, but for such funcionality I only care for 2D working.

Regards

Konstantinos