BitBlt in Froyo

[Guest Tom G]

I had a quick play with video playback in CM6 last night. It failed, but for a totally different reason.

I think the CM6 problem may be easy to fix. The initial problem was an omx library missing (which isn't included in my froyo builds). When I added the missing library it failed with a linking error, which I suspect will be another missing library. I need to recompile with debugging turned on in the linker and then hopefully I can figure out what it needs. I'll let you know how it goes.

[Guest gusthy]

I had a quick play with video playback in CM6 last night. It failed, but for a totally different reason.

I think the CM6 problem may be easy to fix. The initial problem was an omx library missing (which isn't included in my froyo builds). When I added the missing library it failed with a linking error, which I suspect will be another missing library. I need to recompile with debugging turned on in the linker and then hopefully I can figure out what it needs. I'll let you know how it goes.

Tom, do you want to drop the CodeAurora track? Because in this case I will not spend time with fixing this.

[Guest Tom G]

Tom, do you want to drop the CodeAurora track? Because in this case I will not spend time with fixing this.

I don't know. I don't like the mess we have now with bits of codeaurora and bits of aosp. It wasn't well planned, and I'm not surprised things don't work.

I think I will probably run into problems with audio in CM6 the same as I did with aosp. That was why we ended up with the codeaurora bits.

See how far the CM6 port comes in the next few days. If some of the problems we currently have in froyo are fixed in CM6 then at least we know where to look for answers.

[Guest Simon O]

I don't know. I don't like the mess we have now with bits of codeaurora and bits of aosp. It wasn't well planned, and I'm not surprised things don't work.

I think I will probably run into problems with audio in CM6 the same as I did with aosp. That was why we ended up with the codeaurora bits.

See how far the CM6 port comes in the next few days. If some of the problems we currently have in froyo are fixed in CM6 then at least we know where to look for answers.

CM6 supports a lot of devices with the same hardware as the Pulse so I think it'll be easy to fix issues, as long as our device config is up to scratch. Of course there might be some differences but they would be easier to fix than with AOSP.

[Guest gusthy]

CM6 supports a lot of devices with the same hardware as the Pulse so I think it'll be easy to fix issues, as long as our device config is up to scratch. Of course there might be some differences but they would be easier to fix than with AOSP.

Be you right :lol:

Edit:

Meanwhile I went a bit further and it seems, that there is no problem with PMEM, it uses happily. So this is not the case when gralloc reverts to ashmem because it is out of pmem.

Looking at gralloc code it is strange, it defaults to ashmem if client doesnt WANT 2D acceleration.

This could be rewritten, my only problem that I never built the whole CodeAurora stuff. Is there a quick and easy way to compile gralloc.msm7k.so easily?

Edit2: the default gralloc is even worse, it allocates to ashmem by default.

It is easy for G1 guys, G1 doesn't use ashmem.

Edited September 28, 2010 by gusthy

[Guest AdamBaker]

I had a quick play with video playback in CM6 last night. It failed, but for a totally different reason.

I think the CM6 problem may be easy to fix. The initial problem was an omx library missing (which isn't included in my froyo builds). When I added the missing library it failed with a linking error, which I suspect will be another missing library. I need to recompile with debugging turned on in the linker and then hopefully I can figure out what it needs. I'll let you know how it goes.

The complete list of dependencies including dynamicx loaded libs of the omx libs is

libandroid_runtime.so

libbinder.so

libc.so

libcutils.so

libdl.so

libdrm1.so

libhardware.so

libicuuc.so

liblog.so

libmedia.so

libmm-omxcore.so

libm.so

libomx_aacdec_sharedlibrary.so

libomx_aacenc_sharedlibrary.so

libomx_amrdec_sharedlibrary.so

libomx_amrenc_sharedlibrary.so

libomx_avcdec_sharedlibrary.so

libomx_avcenc_sharedlibrary.so

libomx_m4vdec_sharedlibrary.so

libomx_m4venc_sharedlibrary.so

libomx_mp3dec_sharedlibrary.so

libomx_sharedlibrary.so

libomx_wmadec_sharedlibrary.so

libomx_wmvdec_sharedlibrary.so

libopencore_common.so

libskia.so

libsonivox.so

libstagefright_color_conversion.so

libstagefrighthw.so

libstagefright_omx.so

libstdc++.so

libui.so

libutils.so

libvorbisidec.so

[/codebox]

The list of ones actually provided in FLB 1.5 is

[codebox]/system/lib/libandroid_runtime.so
/system/lib/libbinder.so
/system/lib/libc.so
/system/lib/libcutils.so
/system/lib/libdl.so
/system/lib/libdrm1.so
/system/lib/libhardware.so
/system/lib/libicuuc.so
/system/lib/liblog.so
/system/lib/libmedia.so
/system/lib/libmm-omxcore.so
/system/lib/libm.so
/system/lib/libomx_aacdec_sharedlibrary.so
/system/lib/libomx_amrdec_sharedlibrary.so
/system/lib/libomx_amrenc_sharedlibrary.so
/system/lib/libomx_avcdec_sharedlibrary.so
/system/lib/libomx_m4vdec_sharedlibrary.so
/system/lib/libomx_mp3dec_sharedlibrary.so
/system/lib/libomx_sharedlibrary.so
/system/lib/libopencore_common.so
/system/lib/libskia.so
/system/lib/libsonivox.so
/system/lib/libstagefright_omx.so
/system/lib/libstdc++.so
/system/lib/libui.so
/system/lib/libutils.so
/system/lib/libvorbisidec.so

Which seems to amount to no encoding support except AMR, no WMA/V support and no libstagefright_color_conversion.so or libstagefrighthw.so so I guess at least that lot are dynamic loaded.

To generate the second list I put the first list in /tmp/x then did for x in `cat /tmp/x`; do adb shell find /system -name $x -print; done

Unfortunately doing the same test on 2.2 indicates that the only difference is that 2.2 includes libstagefright_color_conversion.so which doesn't introduce any more dependencies. I've tried looking deeper at dependencies of dependencies and can't see anything wrong.

[Guest gusthy]

The complete list of dependencies including dynamicx loaded libs of the omx libs is

libandroid_runtime.so

libbinder.so

libc.so

libcutils.so

libdl.so

libdrm1.so

libhardware.so

libicuuc.so

liblog.so

libmedia.so

libmm-omxcore.so

libm.so

libomx_aacdec_sharedlibrary.so

libomx_aacenc_sharedlibrary.so

libomx_amrdec_sharedlibrary.so

libomx_amrenc_sharedlibrary.so

libomx_avcdec_sharedlibrary.so

libomx_avcenc_sharedlibrary.so

libomx_m4vdec_sharedlibrary.so

libomx_m4venc_sharedlibrary.so

libomx_mp3dec_sharedlibrary.so

libomx_sharedlibrary.so

libomx_wmadec_sharedlibrary.so

libomx_wmvdec_sharedlibrary.so

libopencore_common.so

libskia.so

libsonivox.so

libstagefright_color_conversion.so

libstagefrighthw.so

libstagefright_omx.so

libstdc++.so

libui.so

libutils.so

libvorbisidec.so

[/codebox]

The list of ones actually provided in FLB 1.5 is

[codebox]/system/lib/libandroid_runtime.so
/system/lib/libbinder.so
/system/lib/libc.so
/system/lib/libcutils.so
/system/lib/libdl.so
/system/lib/libdrm1.so
/system/lib/libhardware.so
/system/lib/libicuuc.so
/system/lib/liblog.so
/system/lib/libmedia.so
/system/lib/libmm-omxcore.so
/system/lib/libm.so
/system/lib/libomx_aacdec_sharedlibrary.so
/system/lib/libomx_amrdec_sharedlibrary.so
/system/lib/libomx_amrenc_sharedlibrary.so
/system/lib/libomx_avcdec_sharedlibrary.so
/system/lib/libomx_m4vdec_sharedlibrary.so
/system/lib/libomx_mp3dec_sharedlibrary.so
/system/lib/libomx_sharedlibrary.so
/system/lib/libopencore_common.so
/system/lib/libskia.so
/system/lib/libsonivox.so
/system/lib/libstagefright_omx.so
/system/lib/libstdc++.so
/system/lib/libui.so
/system/lib/libutils.so
/system/lib/libvorbisidec.so

Which seems to amount to no encoding support except AMR, no WMA/V support and no libstagefright_color_conversion.so or libstagefrighthw.so so I guess at least that lot are dynamic loaded.

To generate the second list I put the first list in /tmp/x then did for x in `cat /tmp/x`; do adb shell find /system -name $x -print; done

Unfortunately doing the same test on 2.2 indicates that the only difference is that 2.2 includes libstagefright_color_conversion.so which doesn't introduce any more dependencies. I've tried looking deeper at dependencies of dependencies and can't see anything wrong.

...and this .so id included in our froyo.

But we didn't see Tom's CM6 already. Probably he can get all this libs from an other CM6 for test - and later they can be compiled from source if this dependencies are all solved.

It is yet a question of course, that blit problems will be solved this way.

I think it is important to mention that I checked a lot of different .32 kernel versions - the msm7k mdp blitter is functionally the same in all of them, and they are equal to our .29 kernel, so the problem is not there.

Also, gralloc and copybits didn't change in low level - so the problem is somewhere else - this low level libraries all do the same ioctl call. I guess the problem is at a higher level API incompatibility.