ARM - Building Multimedia Devices with ARM and ARM Partners Solutions

週二參加了這個活動
簡單的說, 這是 ARM 推廣自己的 Mali 系列相關 IP 的活動
儘管有其他像是 MontaVista, Ittiam, Aplix 等廠商的簡報,
然而水準上不若於 ARM 一般重視
而另一個可惜的是與會者做的功課不夠, 常可聽到缺乏sense的問題

著名的日商 Aplix 的簡報算是不錯, 然而定位上比較與活動主題無關
Ittiam 有如照本宣科的簡報
加上最後的 MontaVista 的簡報在內容與問答上有相當的錯謬

Mali GPU:
從 Mali 55 到 Mali 200/400
而自sigle frag. processor, vertex + frag. processor
到 vertex + 4 frag processor (with internal cache)
看得出 ARM 在這個領域上的架構與軟體支援日趨成熟
而對於之後的規劃與規格以很明確 - Vithar & Thor
甚至未來在規劃上有打算支援 OpenCL
回想當時, 應該詢問對於競爭者 Imagination, Vivante 的看法 與 Mali GPU 相較的優勢為何

Mali VE:
這技術源自於 ARM 所收購的 Logipard
在Mali GPU 簡報中強調可以將 VE 的輸出直接作為 GPU 的 texture
DM上可以看出 VE 俱備了 Memory, ME, MC, Transform, Control, Parser, Output 等7個部份
由於具有彈性支援各式video format的特性
因此每個部份都具有相當的programmable flexibility
這樣的做法應該相當接近 configurable video codec 理想

buildroot - Enable setjmp/longjmp exceptions?

這週花了大部分的時間在處理這件事上

繼先前share buildroot toolchain with others之後
接著近日又被詢問了 c++ compiler 的環境
當下看了看buildroot configuration 中 Toolchain 項目有著一行

[] Build/install c++ compiler and libstdc++?

心想著這應該不過 30 分鍾就可以搞定了
接著就是一連串疑問的開始

編譯過程中, 編譯 libsupc++ 時錯誤發生了

/tmp/ccxY0pxQ.s: Assembler messages:
/tmp/ccxY0pxQ.s:423: Error: duplicate .personality directive
/tmp/ccxY0pxQ.s:580: Error: duplicate .personality directive
/tmp/ccxY0pxQ.s:581: Error: duplicate .handlerdata directive
/tmp/ccxY0pxQ.s:948: Error: duplicate .personality directive
/tmp/ccxY0pxQ.s:949: Error: duplicate .handlerdata directive
make[5]: *** [eh_alloc.lo] Error 1

而即便以相似設定以 crosstool-ng 編譯也會在相同點出問題

以buildroot和錯誤訊息作為關鍵字搜索, 可以看到一些資訊, 然而無有效線索
只好嘗試往 source code 找尋蛛絲馬跡
最後找到的是處理 exceptions 相關的部份
於是檢視一下buildroot有關exception的設定, 同在 Toolchain 內有著另外一行

[*] Enable setjmp/longjmp exceptions?

該項目主要是在編譯 gcc 時增加了一個設定項目
--enable-sjlj-exceptions

簡單地說, 是以呼叫 setjmp/longjmp 的方式來作exception handling
而事實上 libsupc++ 亦是C++中處理exception的部份
雖然沒有繼續trace, 然而應該是該部份與 C library 的部份有衝突
所以這問題應該與 uClibc 是有相關的

另外, 如果不使用 setjmp/longjmp 的 exception handling model
則採用的是 call frame unwinding 的方式

這兩者間的差異和優缺就不多說了

Firefox on Netbook

經調整後的Firefox 視窗顯示


儘管Google Chrome 推出了Linux版本, 有著快速的Javascrip Engine - V8
然而對Browsing 除了performance 外, user experience 也是很重要
firefox 3.5 之後將有新的 javascript engine - TraceMonkey
雖比不上 V8, 然而卻也沒有到顯著的懸殊差異
再加上Firefox 的擴充套件, 在使用便利性上Firefox還是較為方便
(長期倚賴, stylish, adblock plus, 新同文堂 與 forecastfox)
但是chrome的外觀讓我瞭解一件事, titlebar 對於 browser的多餘
當然, 很多時候, 多餘的就不只是titlebar

儘管現在液晶螢幕尺寸越來越大, 然而Notebook卻是越來越輕巧
以個人長期使用EeePC 900 瀏覽網頁來說, 網頁顯示面積相當重要
1024x600 的解析度雖稱不上不足, 然而在垂直方向的顯示就相當吃緊
加上4+1大元件: titlebar, menubar, navigation bar, statusbar 和系統的 taskbar 佔去了不少空間
真正網頁顯示面積, 扣掉上面的元件部份, 恐怕只剩下不足500 pixel的高度
雖然我利用了Compact Menu 2 套件, 省去了menubar, 在網頁顯示高度上還是略顯不足

近日看到這篇文章, 感到相見恨晚, 既不失原有的功能性, 又能儘量縮減佔用的空間
於是就把Audohide Statusbar, Hide Caption 與 Hide Tab Bar 這些擴充套件安裝了
我想圖示就是這些套件最好的說明了

ofono - open source telephony stack (revised - 2009/05/14)

在Android platform火熱的今日, Nokia同時走著不同的路
一方面以開放並且成立Symbian Foundation來強化Symbian平台
另一方面開發Maemo與收購Trolltech厚植自身Linux平台技術
再加上本篇主題的 ofono
顯見Nokia在平台佈局的規劃上,
一方面在於鞏固自身利基, 另一方面在於主導與開放

拜Nokia 之賜有著良好設計的 Maemo platform
而Qt 除了轉為 LGPL, 並且也加強與社群的互動


今日 intel 與 nokia 共同宣佈了 ofono 軟體專案
而對於ofono而言
如果說Android打破了手機軟體開發的硬體平台限制
那麼 ofono 要在長久封閉的電信服務上解放(Voice, SMS, Cell Broadcast...etc)

ofono 架構圖


ofono 採用的是 GPLv2 授權, 在API上使用D-Bus 介面 (因此GPL不會是大問題)
對於程式開發者, ofono提供使用電信服務的標準API;
而對於手機開發商, ofono提供標準plugin-in framework, 以加速開發整合產品

在官網上列出ofono API的四個原則

• consistent (一致) : Interface properties 有著一致的操作介面
  
• minimal (精簡) : 避免相同的目的有多種方式達成
  
• easy to use (易於使用) : 儘可能的簡單, 讓程式開發者專注在軟體開發本身.
  
• complete (完整) : 必須豐富且完整到足以開發功能完整的行動電話.

目前已有初期版本可以下載

ofono stack 的出現增加了許多可能性
語音通話, 簡訊就不再只是手機的專利,
而電信語音的應用上也會因為軟體創意, 將會更為多元

ofono的詳細資訊請參考linuxdevices

後記:
今日看到一則中文新聞 , 看到時差點沒當場笑出來
套句批踢踢的常見推文: 記者, 不意外
這篇是對 ofono project 相當錯誤的解讀
儘管我在文中也提到了面對Andorid, Nokia走了不同的路
然而這並不代表Nokia/Intel 推出的ofono 與 Android 是相衝突的
基本上ofono, android這是兩個層面不同的事情
更可以說在這樣的專案推出下,對 Android 是相得益彰
整合後, Android 平台也可以藉此提昇在電信服務上的應用性
所以無論是Nokia 的 Maemo, Intel 的 Moblin 與 Google Android 都能因ofono而受惠..

回到17歲 (17 Again)

面對稱不上順遂的生活, 是不是會想要重新作選擇?
學生時代的精彩, 是不是讓你難以忘懷

周日晚跟老婆看了這部電影
事實上, 光看電影"回到17歲"的劇情簡介, 可以感覺題材並非新穎, 更可以說是老掉牙
甚至觀看劇中的內容,
在"回到未來", "扭轉奇蹟", "蝴蝶效應", "辣媽辣妹", "王牌天神" ... 等, 都可以看到類似的元素
然而這樣的劇情鋪陳依舊引人入勝, 帶來亮眼票房

人生就像是不可逆的化學反應, 現況就是過往的決定所累積的結果
很有趣的是, 往往人們都想知道, 如果能夠有不同的選擇, 結果又會是甚麼
當然, 沒有人真能如此,
因此人們也樂於寄情在電影多樣的詮釋之中, 而這也是這些電影的切入點..

年輕, 總有充沛的精神與體力, 有著對於未來的憧憬與無限可能
然而, 當一段時間過後, 未達理想的現實, 工作無所發揮的消磨
當好好地檢視, 會用甚麼樣的想法和心情去面對自己與周遭?
很多時候真正的答案必須探究自己的內心...

或許因為如此的題材本身帶著嚴肅的人生哲理,
因此需要用歡樂的題材去包裝, 我想這也是為何這類電影多是喜劇

謠言紛飛的Windows 7?

今日除了Theora 修正forward DCT 的問題大幅提昇影像品質的新聞外
最吸引我的就是 Slashdot上的 Windows 7 "Not Much Faster" Than Vista
slashdot 引用了pcworld 的測試結果, 結果是Windows 7 並沒有比Vista 好到那去

測試的結論並不讓我感到訝異, 因為當微軟決定以Vista為Windows 7基礎, 改造時間又如此短暫
以Vista 龐大的新架構, 微軟只想花少少的力氣, 在短短的時間匆促上架, 如此就想改變局面!?
(想想XP 相容性問題, M$並不是以技術翻新架構來達成, 而是妄想用可笑的Virtualization砸錢方式帶過)

問題是Windows 7 就在beta 釋出後, 各種說法也紛紛出籠
速度大幅提昇, 硬體需求不高, 軟體相容性高 各方面效能直逼XP 等等的說法紛紛出籠
(甚至是與XP相比, 但是XP 模式真的是很諷刺)
如此, 很難不去聯想有操作資訊的成分存在


說真的, 可以接受可笑的XP 模式, 不如裝個Ubuntu + VirtualBox 用無縫模式吧...

Debian 全面採用 EGLIBC

今日看slashdot 看到了這則新聞
大意是Debian 將全面改用與glibc source/binary-compatible 的eglib
主要的原因可能是glibc維護者(Ulrich Drepper)與debian間的爭議
(Drepper 拒絕修正glibc一個關於 embedded的問題, 且出言不遜)
而文中的一個連結文章, 更洋洋灑灑數項採用eglibc的好處

長期使用linux的人應該對glibc相當熟悉
一直以來 glibc 在 GNU/Linux 世界中扮演著關鍵角色
或許因為世界改變得很快, glibc也面臨著考驗
除了eglibc, 還有 uClibc, newlib, dietlibc 甚至 Android的 Bionic libc
儘管如此, glibc 依舊保有重量級的地位 (至少desktop linux都是 glibc)
如今這樣的情形可能開始有變化

由於應用特性與硬體平台的多元
現今GNU/Linux不若以往那以 x86 為中心的時代
若Drepper不改變思維, 那具代表性的Debian 也只是起了個開頭
相信之後會有後續的連鎖效應

2009 台南行

安平豆花

安平古堡

德記洋行



本blog轉型為吃喝玩樂blog (大誤)

趁著勞動節連假, 趁著天氣不錯開車帶著老婆往外跑
隔了兩年又再次回到台南市的街道
開車環繞成大附近的街道, 已經又有些不同
成大成功校區的圍牆消失了, 勝利校區有了新的宿舍

下午閒晃在成大週邊, 暖洋洋的天氣讓人充滿精神
而街道上點心/飲料/冰店家讓人垂涎欲滴
而車站前依舊人來人往, 深刻感受到府城的都市活力

相對於新竹工作(音近 "辛苦工作"!?)的生活
在這裡不用費心去找美食文章, 特意避開地雷(似乎貴又不好吃成了共同心得!?)
也不用去找假日往那去, 隨時都可以開始屬於你的觀光/古跡/藝文/美食小吃之旅

或許可以考慮規劃一段時日後到台南工作定居?