Tracking kernel 2.6.32 for OMAP3

Recently I am thinking about update kernel to 2.6.32 for 0xdroid.
Currently the kernel for 0xdroid is based on 2.6.29 tracking AOSP's kernel tree. But we see there seems some new improvement introduced for OMAP3 platform, like including Graphics, a restructured patch set of DSS2 by Tomi, and updated EHCI hcd (USB 2.0) and USB OTG.

Actually the effect of changing kernel form 2.6.29 to 2.6.32 for 0xdroid project is not huge, but we expect updated USB EHCI can get the real stability and 0xlab's kernel can be suitable for more devices. Besides this, 0xdroid's kernel should start to follow up 2.6.32 branch of AOSP's omap kernel tree as well. It looks the force of development has been migrated to 2.6.32 branch already.

Recently

Sometime I feel like I need to slow down my pace and my mind and now the time it is. Either for quiet thinking, intending to watch more or thinking about changing something. As you can see, I am a lazy blogger and not a good writer. Passion is the momentum for anything you want to do and it's the best gift.

Here are something about my work recently. Write it down here for arrangement.

It's about 0xdroid project. I have done implementing Camera HAL for usb camera. For this, I need to have some concept about V4L2 in kernel. It's related to V4L2 Video In. Though camera is more complicated cause it can be greatly performance related when it comes to embedded device. For most product design, the camera sensor module is connected with the camera interface of the SOC. Thus in this manner, most cases there will be closed library provided by the SOC vendor for doing some effect control and performance related tasks.

When doing video recording with the camera, colorspace conversion for encoding and for preview on the screen to make the acceptable frame rate is really critical, especially when the resolution is high. Better situation will be more task can be handled by hardware. For taking picture, it would be better if the hardware can do scaling and jpeg encoding, etc. For previewing and video recording, it also would be cool if we don't need to do heavy colorspace conversion in host software side by hardware conversion(YUYV to YUV420(sp) or RGB) and Overlay support.

Overlay is cooperated with V4L2 video out part. Overlay verifying and could be used by Camera HAL or multimedia video playback is important.

More ahead. Though I need to let myself know what's the value and getting prepared.

Off topic here in this post, most importantly, Glad and excited that we have a third release, beagle-donut-0x3.

Using Overlay on beagleboard

Recently I am trying to make 0xdroid use YUV Overlay in OMAP3 on beagleboard to play video. The purpose is utilizing the overlay in DSS system to accelerate by getting rid of the effort of the composition of different layers on software side and colorspace conversion to RGB.

For achieving this, we should get a libopencorehw module for opencore in Android. The implementation of libopencorehw can use the video-out driver, a V4l2 provider to interface DSS, like in TI's omapzoom tree. Unfortunately this way stuck me for a while, either there has problem in video-out driver or in TI's liboverlay.

After figuring out for a while, we met up another way for this, making libopencorehw use DSS ioctl directly. So we rewrite libopencorehw as simple as it looks and here is the new libopencorehw in 0xdroid. This way is more lightweight and easier to me. Welcome to try.