HW accelerated graphics doesn't work on Snowball Ubuntu Image

Likewise in linaro-ubuntu, included libGLESv2 and libEGL are software-rendering versions from Mesa.

Observed here as well:
https://android-build.linaro.org/builds/~linaro-android/landing-snowball-11.11-release/#build=1

Observed here as well:
https://android-build.linaro.org/builds/~linaro-android/staging-snowball-11.11-release/#build=2

Valid for ICS releases :
https://android-build.linaro.org/builds/~linaro-android/staging-snowball/#build=90 as well.

Linaro-ubuntu now has mali400 gles libraries installed. However they do not work.

1) linaro user has no permission to the device nodes needed (/dev/mali and /dev/hwmem (WTF)).

2) even with the right permissions added, no gles app works. es2_info will just fail with eglInitialize() failed, es2gears as well.

This is easy to reproduce with the included es2gears and es2_info apps.

Kalle: Can you please work with Riku to figure out if the 3D acceleration is working or not and why it is not. If it is not on Ubuntu, please file a separate bug

The mali 400 support is working for the Android Landing Snowball build in the 11.12 release

any update on the ubuntu driver front? Kalle, anything you need from us?

+Alexander Sack The HW accelerated Graphics does work on the Ubuntu track. Unfortunately the last release that was made from Linaro is still not as uptodate as the one released on IglooCommunity.

That will change from the January release and all snapshots before that. The teams are now working on one track and only one track.

This bug references the Linaro ubuntu image and not the image Movial puts out on igloocommunity.

I lived in confusion-land with this one, but here's roughly what happened (to raise awareness of these issues for the future):

The sources for the X.Org driver was taken from a wrong branch which didn't have udev and xorg.conf settings, thus making X.Org use FBDEV and be apparently ok with smoketesting. This masked the b2r2lib problem.

b2r2lib got introduced patches from ICS track that changed the kernel<>b2r2lib API in an incompatible way and these were accidentally pulled into the package on PPA by me. This made the X.Org driver fail after getting the udev and xorg.conf bits in place.

When this was discovered, I reverted the API changes but still the error persisted. After much pondering and rebuilding b2r2lib I realized that the API "checksum" (request struct size) was created in the X.Org driver rather than b2r2lib itself...

So now we have a b2r2lib with the API change reverted and a build-dep change for the X.Org driver to depend on the good b2r2lib version in the pipeline so next build should be working.

Great work Kalle. Thank you for figuring this out.

This now only works for some people. I will continue my investigations today.