2010年7月22日 星期四

Office 軟體的新選擇 - IBM Lotus Symphony 3

Linux 桌面使用者對於 OpenOffice 都不陌生
OpenOffice 的確也逐漸成熟了, 儘管功能性上已經很充足
然而在易用與便利性上的確還有許多改善空間

近日安裝 Xubuntu 想安裝 OpenOffice 時忽然想起沈寂已久的 Lotus Symphony
IBM 在三年前推出 OpenOffice 1.x 為基礎的 Lotus Symphony 1.x 後
很可惜的是當年OpenOffice 以進展至 2.x 相容性與速度上都領先不少

跑去IBM Lotus Symphony官網看了之後, 大為驚人
Lotus Symphony 竟然悄悄推出 Symphony 3 beta 而且已經進展到 beta 3
官方的說明是 Lotus Symphony 是建構在 OpenOffice 3 上
搜尋了一下, 繁中網頁竟然少有資訊, 也沒有任何介紹(或許得拜台灣教育與盜版成功吧..)
除了有 Ubuntu 版本外還有 Windows, Mac OS X 與 RedHat 版本, 下載安裝後, 除了一開始一堆問號似乎是 License 的資訊

下圖為啟動程式後, 映入眼中的第一個畫面, 安裝後語言套件後即有中文


網路上隨便找個 DOC 檔來開看看, 介面的配置看來很適合寬螢幕
UI 的配色與格式看來有再設計過, 1.x 版的顯得比較擁擠


再開個 XLS 檔來看看, 這時有特別的感覺了, 維持了一貫的分頁設計
但是 Lotus Symphony 3 有做小 icon 的區別, 1.x 都是 Symphony icon


接著開個 ODP 簡報檔, 在製作時, 我覺得頗為 Smart, 當你做不同屬性的編輯時
右側的頁面會自動切換於不同個功能頁面, 下圖為開啟預設介面


選取方塊物件, 右方立刻可以編輯顏色, 外框等資訊


選擇編輯文字方塊, 旁邊便是字型選擇, 大小, 顏色
甚至是行距的調整


試用幾天後, 個人覺得雖然記憶體消耗較高些
然而 Lotus Symphony 3 的便利性相當令人滿意
如果看膩了 OOo 較為單調的介面, 不妨試試看新的 Lotus Symphony 3

2010年7月21日 星期三

淺談 OpenCore execution model

由於新工作與 OpenCore 有關, 前輩考量到未來對效能調整, 希望我能了解 OpenCore 架構
為此而稍微細看OpenCore, 感到非常"新奇", "有趣"

在此先不細談 OpenCore 整體 Object Model, 而這部份網路上的談論也不少
大致上即是分為 Engine - PVMF Node - Component 三層

這裡談 OpenCore 中的執行運作模式
或許是OpenCore 受到 Symbian Active Object Framework 諸多影響(文件上也有諸多Symbian字眼)
基本上, 對於Symbian 個人認知不深
然而對於OpenCore這樣注重 realtime 特性的 Multimedia Framework 採用這樣的方式感到"新奇"


上圖為運作的圖解
OpenCore 內基本執行單位為 PVActiveBase
而衍生出的 class 為 OsclActiveObject(AO) 與 OsclTimerObject(TO)
實作中需要被執行的元件繼承 AO or TO
而每個繼承AO/TO的類別需要個別實作其要不斷被執行的 Run() 介面

OpenCore 執行模式為 single thread
在 OsclScheduler::BlockLoopL() 這個無線迴圈當中
透過 WaitForActiveObject() 來取得下一個需要被執行的AO/TO
接著呼叫 CallRunExec() 來執行 AO/TO 的 Run()

對於規劃中需要被執行的AO/TO物件
只要沒腦地執行 PVActiveBase::AddToScheduler() 即可
接著便會依序被執行該AO/TO所實作的 Run()

看似簡單的行為, 然而直覺操作上卻讓人毫無頭緒
是的, 介面上無需透過具體的 scheduler instance, 從何來, 哪裡去就像黑盒子般
這點一時間讓我有點難以接受
細看實作上透過 macro 的方式取得 current thread 的 scheduler
只能說如此的 execution model 機制顯得不太clean
這樣的 model 基本上如果是為了 single thread/co-operative multitasking 的考量
也算說得過去, 只能說真的不是很優雅與直覺

再來, 其中最有趣的一點便在於 OsclTimer 與 PVMFMediaClock 這兩個 timer 類別
實作中AO/TO通常向此兩者註冊callback function 希望通知特定 time event 的發生
OsclTimer (oscl/oscl/osclproc/src/oscl_timer.h) 仰賴著 CallbackTimer
CallbackTimer 繼承自 "OsclTimerObject" ~ Wow~
看看 PVMFMediaClock (pvmi/pvmf/include/pvmf_media_clock.h)
一堆繼承物件中, 第一個物件即為 "OsclTimerObject"
而兩者的 Constructor 都呼叫了 AddToScheduler()
其時間的資訊是去 polling 系統的 OsclTickCount 得知

這麼看來 Timer 這點可"有趣"了, Timer 的運作與通知機制也仰賴著這個 BlockLoopL
而如果某一 AO/TO Run() 稍微久一點, Timer Event 可能就失真不少

ex:
試想, 假若一個 decoder 具有硬體加速, 然而 interrupt 有問題
因此採用 polling 方式以得知硬體狀態
component 中期望 timer 能夠每 10 ms 通知一次,
方便於 check 硬體狀態來決定是否要命令硬體 decode 下一張 frame
而在此同時 audio decoder 為軟體實作, 每解一個單位需要 30ms
這麼一來 ......

是的, 如果要遷就這樣的 model, 每個 component 實作上必須特別考量到 timing
而軟體實作上可能必須是 progressive 的方式, 不要一次將全部結果解出, 減少 Run() 單一執行時間長度
以這樣的方式, 來換得 timing 的精確度

如果是為了遷就不用 thread 而使用這樣的 timer 實作呢?
那 Audio 處理與 proxy interface 中就不該大剌剌地使用 OsclThread

anyway, 很高興在 trace 期間自 jserv 那聽到 2.2 已是預設的 StageFright
雖然目前實作不若 OpenCore 完整, 然而看來就個人的理解是"正常"多了 ...

20100727 後記: 應該好好說明一下 proxy interface, 其實本文中舉的例子並不一定會出現, 這裡用這樣的例子來解釋這樣的方式的問題, 文中例子的發生與否取決於是否使用proxy interface(是的, 這是compile option, 而且意義並非網路proxy), 在OpenCORE 中 codec 以 openmax 封裝為 omx_xxx_component, 若透過 proxy interface 即 create 了各 codec 的 thread. 儘管 OpenCORE 中透過使用proxy interface如此與設計不同的方式來避開 codec 的時間問題, timer 依舊容易受到 system I/O 與 parser 之類的影響.

2010年7月20日 星期二

Xubuntu On MSI CX420

近日由於工作需要編譯 Android 環境, 原有的配有 Sempron Mobile 3800+ 筆電不敷使用
到了附近的賣場看了後, 決定了購入新的筆電 - MSI CX420
所俱備的性能與價格搭配看來是具有相當高性價比的機子

當然, 拿到手第一件事當然是想辦法安裝 Linux 環境
安裝本身並不是難事, 問題發生在安裝完成後

1. 安裝 ATI 驅動程式, 無論透過 Ubuntu 的啟動ATI專有驅動程式, 或是手動安裝ATI Driver, 安裝後重新開機都會是黑螢幕(Yap, 為此我重裝一次....).
這部份的線索是從 MSI CX420 驅動程式頁上對於 XP 需要設定 Primary Display為 PEG
是的 Linux 同 XP 不支援 SG(Switchable Graphics) 特性
需要刷新 BIOS 版本, 將 Primary Display 設為 PEG(PCI-Express Graphics)
刷新後, 原本黑濛濛的畫面就變得非常亮眼~ (無需重裝Linux, 刷新後就正常了)

2. Ralink 1T1R 802.11bgn 無線網路裝置無法驅動
從 Windows 上可以看到為 USB 裝置, 也可以看到所在的 Port & Hub 位置
於 Linux 上 lsusb 可以得到下列訊息:
Bus 002 Device 002: ID 8087:0020
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 0db0:3870 Micro Star International
Bus 001 Device 002: ID 8087:0020
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

喔!? 竟然顯示微星 (lsusb -v 的 verbose mode 也只能看出是 Ralink裝置, 就省略了)
搜尋 device id 0db0:3870 可以看到 rt2800 的訊息
加上看到MSI官網上的驅動程式, 解開後閱讀 inf, 標明為 rt2870, 第一時間我就以為是Ralink RT2870
跑到 Ralink 的Linux驅動程式頁面下載RT2870USB 驅動程式
還自作聰明地將device id 加入來偵測, 結果是裝置驅動了, 然而無法scan ap 與連線
不能 work 的 driver 等於沒有, 於是回到了原點

接著想找社群的 open source 方案
由於 google 0DB0 3870第一時間會看到這個頁面
這表示 rt2800usb 還是與 CX420 上的裝置有關
頁面聯結的 rt2800usb.c 原始碼可以看到 裝置歸類於 RT2800USB_UNKNOWN
然而這檔案看來也不是最新的, 當然立刻看 git.kernel.org 上最新的 rt2800usb.c
ok, 這裝置在 rt2800usb driver 中被歸類為 RT2800USB_RT30XX
於是, 這時恍然大悟, 被搞錯的型號也呼之欲出
0x0db0:0x3870 的 Ralink USB 裝置應該為 RT3070
重新去網頁下載RT3070USB驅動程式, WIFI 速度非常!

到此終於解決了 Video 與 Wifi 兩大問題.
WebCam 後來測試是ok的, bluetooth 我沒在用也就無從測起了..^^

2010年7月10日 星期六

無意取悅小螢幕裝置的 Ubuntu Unity 介面


近日注意到Ubuntu 新的Distribution - Ubuntu Light
其 UI 系統稱之為 Unity

由於是屬於 Ubuntu Netbook Edition 的系列 UI
於是就裝到 EeePC 701 上測試
對於視覺呈現上並不滿意

常用的 Web Browsing 應用即能顯示出 Unity 在 800x480 解析度上的不便
首先, 螢幕上方的 toolbar 並無任何設定選項
由於高度不夠, gcin icon 就被截去了一段
側邊的 toolbar 很華麗, 整合了快速啟動與程式切換的功能
於是, 高度就在上方的 toolbar 與 視窗 titlebar 雙重的浪費下, 垂直顯示範圍縮小不少
不若原有UI 在使用顯示面積上來得有效率

當然, 現今Netbook 提升至 10" 以上, 解析度上也高了一到兩階
誰還在乎EeePC 701的 800x480?
但是手持裝置的 MID(ex: SmartQ5/Q7), 中小型Tablet 這樣的解析度也是常有

然而以定位看來 Unity 目標與適用範圍在於解析度夠高的 Netbook 與 iPad 等級的 Tablet
這樣的結果看來也是無可厚非

Chisel 學習筆記 - Scala 與 Chisel 基礎語法

標題為筆記, 但這篇比較屬於心得 延續 上一篇 的環境建立, 這次計劃藉由 Jserv 最新的 課程安排 來學習 Chisel, 當然個人目標是能夠按照 Jserv 的課程規劃在 期限之內 完成 Lab 3, 由於個人並非 digital designer (現在這年紀也算老貓學...