Since few weeks we were struggling to get camera working on beagleboard-xm. At start we felt it should be easy to migrate from froyo to gingerbread with respect to HAL. But..!!! got stuck in white display problem and dead lock while capture.
We would like to put our understanding which might help somebody who works with camera port on Android.
Camera Preview is only white screen on gingerbread
We have seen couple of issues reported related to this ; either with simulator or with h/w. Some applications which were accessing a camera in froyo have failed to preview correctly in gingerbread. In gingerbread there is a change in camera service – added support for multiple camera access – and surface flinger – OpenGL ES textures.
Error: D/CameraHardware( 1952): Preview Heap
I/ActivityManager( 954): Displayed com.android.camera/.Camera: +2s393ms (total +16s148ms)
W/OrientationEventListener( 1995): Cannot detect sensors. Not enabled
E/SurfaceFlinger( 954): texture=1984777172, using format 17, which is not supported by the GL
D/dalvikvm( 1995): GC_CONCURRENT freed 469K, 54% free 2690K/5831K, external 901K/1038K, paused 2ms+19ms
W/AudioPolicyManagerALSA( 1952): AudioPolicyManagerALSA::getStrategyForStream() Stub Called…
Camera application use default surface holder for preview and that is RGB565 by default at surface flinger.
We could see some display format has been removed. It might be the case with specific vendor as well. With respect to beagleboard-xm and TI SGX; we need to change display to RGB565 in underline file. This change has enabled camera preview on gingerbread.
Filename: CameraService.cpp
Function: CameraService::Client::registerPreviewBuffers
ISurface::BufferHeap buffers(w, h, w, h,
– HAL_PIXEL_FORMAT_YCrCb_420_SP,
+ HAL_PIXEL_FORMAT_RGB_565,
mOrientation,
0,
mHardware->getPreviewHeap());
Optimization Scope: One can enable support to render directly YUV422 frame and remove conversation YUV422->RGB565 at camera HAL.
Dead lock/Hand up @image capture
After resolving we felt like we were done… But very next we pressed capture button…opps….Application just hanged up.
After looking into the code we found:
1. Camera service is acquiring a lock and calling camera HAL function
2. Camera HAL function creating a thread
3. New thread gets compressed image and call Camera service’s callback
4. Data callback again tries to check for valid message and for the same try to acquire a lock
Here:
1. If – CameraHardware:takepicture() returns to the camera service before PictureThread calls callback ; scenario will work fine.
In Other case camera service will go for a sleep. Somehow takepicture() should gets return back to free the lock. But even in sleep mode that is not happening and continuous while loop in lockIfMessageWanted kept running. This might be scenario of thread exception.
We got it fixed by removing conditional check in callback. We don’t see any side effects with this change.
Now… moving on recording part with soft codecs 🙂
===
contributed by Satish Patel Texas Instruments.
If you want to share any message, please write to sm dot khasim at gmail dot com
arowboat.wordpress.com 