Here's the current score card:
https://android-build.linaro.org/builds/~berolinux/landing-panda-4.0.3/#buil... - blows up, 4430 https://android-build.linaro.org/builds/~berolinux/staging-panda-4.0.3/#buil... - works, 4430 https://android-build.linaro.org/builds/~berolinux/staging-snowball-4.0.3/#b... - in testing https://android-build.linaro.org/builds/~berolinux/staging-imx53-4.0.3/#buil... - no display https://android-build.linaro.org/builds/~berolinux/staging-origen-4.0.3/#bui... - works and is accelerated https://android-build.linaro.org/builds/~berolinux/staging-snowball-4.0.3/#b... - fails no landing-snowball
-Zach
2011/12/18 Bernhard Rosenkränzer bernhard.rosenkranzer@linaro.org:
2011/12/19 Bernhard Rosenkränzer bernhard.rosenkranzer@linaro.org:
So whatever calls ProcessFlipV2() disagrees with the kernel on just what a dsscomp_setup_dispc_data structure should contain.
Just checked, the problem is that the kernel's idea of a dss2_ovl_info struct is different from bionic's. Very different, even.
The problem is the rather stupid idea of including a set of kernel headers (external/kernel-headers/original/) inside AOSP instead of getting the kernel headers from the kernel, where they ought to be. I think the best way to fix it is to put the correct kernel headers in place and add an invocation of bionic/libc/kernel/tools/update_all.py to the build process.
Will check if that's doable without too much effort.
ttyl bero