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.

藍芽Speaker，請不要斷續

前一陣子，因為demo需要，和 Jserv去光華商場買了一件藍芽Speaker回來，也開始玩了Bluetooth的a2dp。但運氣不好的是，沒有把bluetooth device 整合好，bluetooth init和開啟時沒有把baud rate設對，以致於經由bluetooth輸出到Speaker時，聲音是斷斷續續，固定間隔的出來。這的確是讓我卡了一陣，雖然解法似乎很簡單。時間差了一點，就可demo出經由a2dp輸出到藍芽Speaker。這讓我感受到資訊整理的重要。

android1.5，已支援a2dp, 經由android的mediaserver 使用 libaudioflinger，再呼叫 liba2dp的function，把解好的聲音檔 (pcm格式) 丟給bluez，做sbc encode，丟到socket，而後送到bluetooth device上。 liba2dp.so為android在bluez裡建立的plugin，這條路是android所提供的。

另一條路，則是build 出bluez 原本給 alsa-lib使用的alsa plugins, libasound_module_ctl_bluetooth.so and libasound_module_pcm_bluetooth.so,
並將其放至/system/usr/lib/alsa-lib/ , here is a quick patch for this.

Some test steps and notes are as below (on Android 1.5, 00:17:53:09:2E:E0 is the device address):
vi /system/etc/asound.conf ,
pcm.bluetooth {
type bluetooth
device 00:17:53:09:2E:E0
profile "auto"
}

test steps:
1. hcitool scan
2. passkey-agent --default --path /org/bluez/hci0 0000 00:17:53:09:2E:E0 &
3. dbus-send --system --dest=org.bluez --type=method_call --print-reply /org/bluez/hci0 org.bluez.Adapter.

CreateBonding string:00:17:53:09:2E:E0
4. dbus-send --system --dest=org.bluez --type=method_call --print-reply /org/bluez/audio org.bluez.audio.Manager.CreateDevice string:00:17:53:09:2E:E0
5. alsa_aplay -Dplug:bluetooth /horse.wav

除了a2dp, 與Android UI的整合也花了一些功夫，overview的整理一下，SystemSever起來時，會啟動BluetoothDeviceService, BluetoothA2dpService這兩個service。bluetooth 的上層java部份(framework.jar)，會透過一層JNI 呼叫 (libandroid_runtime.so)，使用dbus與hcid溝通(之後bluez 4.x版為bluetoothd), 以及呼叫libbluedroid來控制硬體。