X11 eglCreateImageKHR implementation

Hi,

While working with gnome-shell (X11, cogl & mutter doing window compositing) we see a strange issue when eglCreateImageKHR() is used to get an OpenGLESv2 texture of an X11 window pixmap.

We are working with Mali-400 driver r3p2-01rel0 on Exynos4412, running gnome-shell under Linux/X11.

base: BUILD=RELEASE ARCH=arch_011_udd PLATFORM=default_7a TRACE=0 THREAD= GEOM= CORES=MALI400 USING_MALI400=1 TARGET_CORE_REVISION=0x0101 TOPLEVEL_REPO_URL=Linux-r3p2-01rel0 REVISION=Linux-r3p2-01rel0 CHANGED_REVISION=Linux-r3p2-01rel0 REPO_URL=Linux-r3p2-01rel0 BUILD_DATE=Fri Jan 11 14:58:31 UTC 2013 CHANGE_DATE=Linux-r3p2-01rel0 TARGET_TOOLCHAIN=gcc HOST_TOOLCHAIN=gcc TARGET_TOOLCHAIN_VERSION=gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)  HOST_TOOLCHAIN_VERSION=gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)  TARGET_SYSTEM=gcc-arm-linux-gnueabihf HOST_SYSTEM=gcc-arm-linux-gnueabihf CPPFLAGS= CUSTOMER=internal VARIANT=mali400-r3p2-gles11-gles20-linux-ump-x11 HOSTLIB=direct INSTRUMENTED=FALSE USING_MRI=FALSE MALI_TEST_API= UDD_OS=linux

For windows that XGetGeometry reports as 32-bit color depth (i.e. some transparent regions), Mali's EGL returns a well-behaving texture. However, for windows that are 24-bit color depth (i.e. no transparency), we get strange behaviour. It is hard to classify exactly what is 'odd' with the resultant textures, but it is as if they have a bad alpha channel. We'd expect all alpha values to be 1 (opaque) but when blending with other textures under certain situations, the window textures act as if they have corrupt alpha values, so we see some of the desktop poking through in "random" pixels of the window.

1. Can a mali dev explain how eglCreateImageKHR() is implemented internally? How does it locate pixmap data and create a texture from it? I figure that it must interact with X somehow here, and as X is open source, maybe we can hack something in on the X side which sanitizes the alpha channel before Mali picks it up. (OTOH, we don't have Mali DDK to be able to attempt some fix on the Mali side...)

2. Would it be possible to get this fixed in Mali? Even if that happens I'm interested in the above explanation, because it seems unlikely we'd get a new libMali from someone with the DDK for some time...