LCD 螢幕小整理

本來這個禮拜要把手邊的幾本書都讀完, 不過昨天發生一個悲劇 – 我的電腦螢幕壞了, 只好花時間研究一下 LCD 螢幕怎麼買?這個三隻小鳥牌的螢幕在臨終之前, 常常有不能從休眠中喚醒的症狀. 近來它被喚醒的難度愈來愈高, 終至昨天為了一時想省電而把它 power off, 哪知它再也醒不來了.  

正好現在資訊月開跑, 3C 產品的價位應該會比較便宜吧!上網查了一下, 我原來那台螢幕的價錢已經可以買到 27 吋了. 既然科技日新月異, 我也要先惡補相關資訊, 以免買錯.

首先, 應該要買 LED 背光的產品, 取代傳統的冷陰極螢光燈 (CCFL) 背光. 基本上廠商自己會進版, LED 具備省電, 壽命長等諸多優點, 我們非買不可.

其次是 LCD 技術, 大致上它分為 TN, VA, 和 IPS 三大類. TN (Twisted Nematic) 是最舊的技術, 不過現在很多螢幕還是走 TN, 包括定位較高階的 27" 產品, 原因是 TN 技術的價格低廉. VA (Vertical Alignment) 是比 TN 優秀的技術, 特色是對比明顯加大, 亮點機率降低, 但可能會有暗點. VA 有很多衍生的技術, 像是富士的 MVA (Multi-domain Vertical Alignment), 友達的 AMVA  (Advanced MVA), 奇美的SMVA (Super MVA). 最昂貴的一種技術則是 IPS (In Plane Switching).

傳統的 TN 在無電壓的時候, 液晶略微平躺, 此時是亮的; 有電壓時, 液晶會慢慢站起來, 此時是暗的. 因此沒吃到電的壞液晶會變成亮點, 短路是暗點. 反之, VA 在沒電壓的站著, 有電壓是倒下去, 故壞的液晶多數是暗點.  當液晶都還站著的時候, 只要把偏光板設為全黑, 光線就一點也不能通過. 這使得 VA 的對比好過 TN 與 IPS, 勇奪第一.

初期 VA 的可視角不好, 但在 MVA 發明之後就解決了這個問題, 甚至超越的 TN + film (薄膜). 最好的可視角要算是 IPS 技術. IPS 的特點是不讓液晶站了又倒, 倒了又站. 大家一直都平躺的, 只是在原地打轉. 由於 IPS 液晶轉圈的速度比不上站起或是倒下, 因此它的反應速度最慢, 耗電又最多.不過就像 VA 之後有了 MVA, IPS 也有了 S-IPS (Super IPS), AH-IPS(Advanced High Performance IPS) 等等的改進方法, 雖然對比不行, 但是反應速度/透光度或是耗電都有了改善. 它的最大優勢在於可視角在 170 度以上, VA 頂多就是做到 170 度.

在反應速度上, 通常標示為灰階或是 G2G (graylevel to graylevel)  而非全黑到全白. 目前 IPS 的反應速度可以寫到 6ms (acer S275HL). VA大約是 4ms (BenQ GW2750HM), TN 是 2 ms (Samsung S27B350H). 所以 TN 的螢幕都會強調 "激速". 上面的數據看似 VA 比 IPS 更快, 但 VA 正常的速度應該是 12ms (Envision H2776MHA, Philips 273P3QPYEB), BenQ 比較快是因為開了獨家的 AMA (Advanced Motion Accelerator Technology) mode 讓液晶加速翻身. 

附帶一提, 如果大家去百度查資料的話, 大家都說 IPS 比 VA 快, 在理論上這是不正確的. 如果拿同一代的技術相比, VA 應該不會輸給 IPS. 我想這就是 acer 號稱 6ms, LG (LG IPS277L-BN) 號稱 5ms, 而 BenQ 號稱 4 ms 的原因. 

另外 IPS 的面板是硬的; TN 和 VA 的面板都是軟的. 以前我很怕同事跑討論事情的時候在螢幕上指指點點的, 只要手指按下去, 整塊區域都會出現彩虹. 不管是自己的螢幕或是別人的螢幕, 感覺它都受了內傷. 想必 IPS 可以徹底解決此一問題.

IPS 面板上分布了很多電極, 他們都是住平房, 而不是住樓上下. 因此透光度比較差, 需要更多的背光燈管. 燈管一多, 除了前面提到的耗電問題之外, 黑的地方就不如 VA 黑, 對比範圍因此降低. 對比的數字有兩種, 一種是幾百千萬起跳的動態對比 (contrast ratio max); 另外一種是數字幾千的真實對比 (contrast ratio native). 在真實比對方面VA 大概寫  3000:1~5000:1, IPS 大概是 1000:1, TN 不是不寫, 就是寫動態對 2,000 萬:1. 如果 IPS 要寫動態對的話是 10, 000 萬 :1.

再來就是 LED 燈管的安排有直下式和側照式兩種. 不好的螢幕會有漏光的現象, 開到全黑畫面時, 會看到某一區是亮的. 因此也有些螢幕會標示零漏光. 至於會漏光的螢幕也不是瑕疵品, 而是規格本就如此. 網路上有一些測亮點和漏光的程式可以下載, 如果是新買的螢幕還來得及退換貨的話, 可以測試一下. 否則直接看網路評價應該就可以了.

然後是 bit 數, 有的是 6 bit, 有的是 8 bit, 10bit, 甚至 12 bit (DELL U2711). 6 bit 唯一的好處就是處理的速度比 8 bit 更快. 一般 8 bit 螢幕就會標示為 16.7M (2 (8 x 3)) 色, 只有 VA 和 IPS 可以做到每個原色完整呈現 8 bit, TN 頂多到 16.2M. 16.2M 和 16.7M 看起來差沒有多少, 但 TN 在這一關就是輸了. 

當然, 更厲害的人會關心色偏 (color shift). 這個部分我另外再研究.

至於輸入的接頭也很重要, 如果只有 HDMI 接頭而沒有 DVI 接頭, 那麼需要買 DVI 轉 HDMI 的這條線, 大概幾百塊可以搞定. 若是多一兩組 HDMI, 這又可以接播放機來看電影而不用開電腦. 最後就是有支援 PIP/PBP 的螢幕, 這樣一來價錢難免就破萬元了, 好處是它可以一面打電腦一面看電視. 然而到了這種價位, 難免會想要直接買 26" 的電視而不是 27" 的電腦螢幕. 買 PIP 螢幕, 唯一能省下的就是不用買一個支援 PIP 的電視盒, 而是一個普通的電視盒.

考慮到改為買電視的話, 少數機種還支援 MHL, 這樣就可以用手機看大螢幕而不用再幫手機充電. 螢幕的部分有 LG IPS277L-BN, AOC i2757FM, 三星 S27B970D 可選. 當然電視或是螢幕不支援 MHL 也沒關係, 只要手機或平板支援 MHL, 再買一條可以充電的 MHL + power 線, 同樣可以在螢幕上玩 APP, 看網路影片. 這條線在價格方面也是幾百元, 買到 HDMI 公的就可以直接用, 若是買到 HDMI 母的又需要多買一條 HDMI 線.

總之, VA 的性價比較好, IPS 當電視最佳. TN 也可以用, 畢竟這是桌上型電腦螢幕而不是電視, 視角小一點並沒有影響, 只要螢幕腳架可以調整高低就 OK 了. HDMI 也是愈多愈好, 有沒有 3D, USB 或是喇叭無所謂, 大概就是這樣了. 

[REF]

1. 簡述 TN、VA、IPS 液晶色彩 與 影像品質

2. LED背光液晶顯示電視

3. 薄膜電晶體液晶顯示器

4.  LCD Color: 8-Bit vs. 6-Bit

5. 螢幕面板怎麼挑?TN、MVA、IPS 各有什麼特色與優點

政府基金小檔案

我對政府操作的基金不是很感興趣, 勞保勞退甚至國民年金破產我也能想得開, 因為靠別人就不如靠自己. 不過, 搞清楚這是怎麼回事畢竟比較好, 所以花了一點時間 Google 一下, 把數字大概列出來.

這邊的數字都很大, 尤其是大家信賴的郵政儲金達到 5.6 兆元, 規模真是相當驚人. 相較於台灣今年的 GDP 大約是 15 兆左右, 若是全國國民都去把郵局的錢領出來花的話, GDP 可以成長 37%. 當然這是開玩笑的, 大家都去郵局擠兌的話, 台灣就天下大亂了, 有錢也沒地方花.

國安基金雖然和四大基金有所重疊, 不過它只動用尚未投資的部分, 總計 3 千億. 這筆錢很容易就可以從郵局取得, 來源不是問題. 另一個財源是以國庫所持有之公民營事業股票為擔保,向金融機構借款;借款最高額度為新臺幣2,000億元. 因此我們可以說國安基金護盤時, 人民出的錢比政府還多 (3,000 > 2,000).

  國安基金 四大基金 (億) 2011/10 (億)
郵儲儲金/簡易壽險基金 3,000 54,670 (未投資) 53,152 (未投資)
1,330 (已投資) 1,448 (已投資)
勞退基金 14,357 5,617 (舊制)
7,143 (新制)
公務員退撫基金 4,013 (估計) 4,866.88
勞保基金 5,346 4,452 (勞保)
1,009 (國民年金)
金融機構借款 2,000    
總值 5,000 29,000 [註 1]  

[註 1] 按照最右邊那行是去年的資料, 參考 [ref 2]. 四大基金這行的數字是今年的, 參考 [ref 3].

[ref]

1. 《國家金融安定基金設置及管理條例》,2000 PDF檔:PDFFiles/0714.pdf

2. 籌碼(一) : 何謂四大基金 (2011/10)

3. 政府四大基金績效 今年比去年好

4. 勞退、勞保基金今年彌平去年虧損 還淨賺了267億元

我讀 «不買飆股, 年均獲利 40%»

這本書名聳動的小書作者事喬伊葛林布雷 (Joel Greenblatt), 英文書名叫做 “The Big Secrete for the Samll Investor". 有 small, 有 Big, 不由得令人聯想到 ARM 在推的 big.LITTLE 架構. 不過那是另外一個話題了, 這邊講的是針對小企業的股票投資術.

如果要一針見血地進入主題, 那麼讀者可以忽略掉前 147 頁 – 裡面沒講什麼. 它不像論說文一樣有著起承轉合, 比較像是偵探小說一樣先告訴我們: 剛剛提到的都不是兇手. 那麼什麼才是投資祕笈呢? 就是價值加權指數.

我們如果買入大盤或是 ETF, 往往都以市值比例買進股票. 如此一來, 高價股就會買得更多, 而潛力股相對買得更少. 為了糾正這個缺點, 作者認為應該用企業的資金報酬率 – ROC (Return on Capital)、殖利率等等來選擇公司. 舉例來說, 公司的股價不高, 但是營收創新高. 它暫時不太可能進入台灣五十或是中型 100 的選股名單. 等到它進入名單, 其實往往已經漲多了.

作者說: 散戶沒有提供財報的壓力, 所以應該持有價值型的股票. 讓法人去追逐大型股, 這樣才能獲得優勢. 我們看到前陣子的盈正案和 “小型股禁養令" 正是如此, 法人為了避免出錯, 或者被大盤打敗, 只有拼命看好與看壞大型股, 並順勢進出. 散戶只要能堅守原則, 按照紀律長期持股, 並且只動用資金的 50~70%, 長期就能打敗大盤, 甚至短期都能勝出.

本書後面也附上一個清單, 列出台股殖利率與 ROC 較高的個股. 不過並沒有特別計算資金報酬率 ROC, 我假設 ROC 的算法是:

ROC = EPS * 現金股利 / (現金股利 + 股票股利) * 盈餘分配率

比方說每股賺 5 塊, 只分配 3 塊, 3 塊中只有 2 塊是現金, 那麼 ROC = 5/10 * 3/5 * 2/3 = 20%. 不過作者的投資組合裡面不是用比例的大小去買股票, 而是依據其絕對數字的比例. 這樣賺得多, 分得多的股票就會買得比較多, 未來它的市值上升了, 才能勝過 ETF 這種市值加權平均的選股方式.

最後, 有件好笑的事要講一下, 作者說他的第一本書 “你可以是股市天才", 本來他以為是散戶聖經. 不過他忽略了散戶沒有那麼多專業知識和時間. 後來他又以為他的第二本書 “打敗大盤的獲利公式" 才是散戶聖經, 不過這次他又錯了, 散戶並不想自己動手. 所以, 他的結論說: 這本才是真正的投資聖經! 呃…我想他還是錯了.

作者勝出的模型是基於擁有 800~1,000 檔股票 (p. 158), 這樣不但打敗 S&P 500 還能打敗羅素 1000. 但散戶絕對不可能滿足這樣的經濟規模. 如果要靠零股來達成購買 1000 檔股票的模型, 勢必有流動性的風險. 據作者說要滿足這樣的模型, 每年大約要周轉 80~100%, 光是每天要瀏覽 800 檔零股應該就足以讓人瘋掉了.

說了半天, 還是只能買基金. 據說美國市場的銳聯指數 (FTSE RAFI 1000 index) 和他有相似的理念, 買紐約證交所的 PRF (PowerShare FTSE RAFI US 1000 Portfolio) 這檔 ETF 基金就可以省去自己操作的麻煩.

或曰, 本書第 80 頁不是有個標題說: “別貪心, 固定投資幾家就好" 嗎? 其中還引用巴菲特的話, 強調 “集中持股" 的重要. 作者應該同意只持股少數幾檔才對啊? 非也, 除了極少數的人, 有誰真的只挑少數幾支股票就發大財的. 再說, 如果作者明確知道怎麼挑選少數幾支股票, 他就不需要用股海戰術和 S&P 500 或羅素 1000 PK 了. 用 800 檔股票算出來的模型, 放到 8 支股票上絕對是另外一回事.

因此, 我肯定作者的理念: ETF 追高殺低的確有一點激情, 以價值而非市值選股比較好. 至於自己建立龐大的投資組合絕對是不可行, 如果投資組合很小, 那就要靠個人功力了.

PRF 的淨值也供大家參考.

«深入淺出 – Android 系統移植與開發測試» 的補充

這本書的發行的時候, Android 的版本只是 2.2. 現在 Android 已經到 4.2 版了, 所以有些內容需要修改. 我把需要改變的地方整理如下:

0. 首先要安裝 64 bit 的 ubuntu

如果沒有光碟機, 會有點小麻煩. 因為 ubuntu 的 Windows installer 預設是安裝 32 bit 版本. 所以要先下載 64 bit (amd64) 版, 然後手動選取 iso 檔.

如果一定要用 ubuntu 32 bit 版本, 請參考這一篇 [註 0].

1. 在 ubuntu 上安裝以下的套件, 修改的地方用紅色, 並新增第四行.

sudo apt-get install git-core flex bison gperf libesd0-dev zip

sudo apt-get install libwxgtk2.8-dev zlib1g-dev build-essential libstdc++5

sudo apt-get install tofrodos  x-dev libx11-dev lib32ncurses5-dev xsltproc

sudo apt-get install gcc-multilib g++-multilib libc6-dev-i386 ia32-libs x11proto-core-dev lib32readline-gplv2-dev lib32z1-dev [註 1]

如果 apt-get 失敗, 請參考這篇 “回覆: 最近在安裝新的10.10無法更新


接下來就是 Java 了, 基本上 Java 套件會找不到. 所以要先讓 ubuntu 可以安裝過期軟體 [註 2].

apt-add-repository “deb http://old-releases.ubuntu.com/ubuntu/ jaunty multiverse"
apt-add-repository “deb http://old-releases.ubuntu.com/ubuntu/ jaunty-updates multiverse"

此時在 /etc/apt/sources.list 的最後四行會看到:

deb http://old-releases.ubuntu.com/ubuntu/ jaunty multiverse
deb-src http://old-releases.ubuntu.com/ubuntu/ jaunty multiverse
deb http://old-releases.ubuntu.com/ubuntu/ jaunty-updates multiverse
deb-src http://old-releases.ubuntu.com/ubuntu/ jaunty-updates multiverse

接著就可以更新 source list.

sudo apt-get update

sudo apt-get install sun-java6-jdk


再來就可以安裝 repo.

cd ~/bin

curl https://dl-ssl.google.com/dl/googlesource/git-repo/repo > ~/bin/repo

chmod a+x ~/bin/repo

PATH=~/bin:$PATH


再來取得 Android source code.

repo init -u https://android.googlesource.com/platform/manifest.git

repo sync

經過了不知道多久….

接著做設定

lunch

畫面出現

You’re building on Linux

Lunch menu… pick a combo:
     1. full-eng
     2. full_x86-eng
     3. vbox_x86-eng
     4. full_mips-eng
     5. full_grouper-userdebug
     6. full_tilapia-userdebug
     7. mini_armv7a_neon-userdebug
     8. mini_armv7a-userdebug
     9. mini_mips-userdebug
     10. mini_x86-userdebug
     11. full_phantasm-userdebug
     12. full_mako-userdebug
     13. full_maguro-userdebug
     14. full_manta-userdebug
     15. full_toroplus-userdebug
     16. full_toro-userdebug
     17. full_panda-userdebug

Which would you like? [full-eng]

預設就是第一項 full-eng.

make

如果 64 bits 編譯工具沒弄好, 可能看到錯誤訊息:

prebuilts/tools/gcc-sdk/gcc: line 40: prebuilts/tools/gcc-sdk/../../gcc/linux-x86/host/i686-linux-glibc2.7-4.6/bin/i686-linux-gcc:

用了這招可以修好 [註 3]

cd prebuilts/tools ; git reset –hard HEAD^
cd external/qemu ; git reset –hard d4f5a3ae87a7246613188940c1667bf2880da402

如果看到

/bin/bash: prebuilt/linux-x86/sdl/bin/sdl-config: No such file or directory
/bin/bash: prebuilt/linux-x86/sdl/bin/
sdl-config: No such file or directory

可能是 repo init 時設錯. 我發現我是設錯 username, 此時用

repo init –config-name 重設一次 username 和 email address


錦上添花的設定:

1. 減少不必要的編譯.

export USE_CCACHE=1

2. 設定 USB 設備:

sudo vim /etc/udev/rules.d/51-android.rules
加入設定指令, 讓 Android user 可以直接使用 USB 設備, 忽略到 OWNER 就變成是 root 才能訪問.

# adb protocol on passion (Nexus One)
SUBSYSTEM=="usb", ATTR{idVendor}=="18d1″, ATTR{idProduct}=="4e12″, MODE="0600″, OWNER="<username>"
# fastboot protocol on passion (Nexus One)
SUBSYSTEM=="usb", ATTR{idVendor}=="0bb4″, ATTR{idProduct}=="0fff", MODE="0600″, OWNER="<username>"
# adb protocol on crespo/crespo4g (Nexus S)
SUBSYSTEM=="usb", ATTR{idVendor}=="18d1″, ATTR{idProduct}=="4e22″, MODE="0600″, OWNER="<username>"
# fastboot protocol on crespo/crespo4g (Nexus S)
SUBSYSTEM=="usb", ATTR{idVendor}=="18d1″, ATTR{idProduct}=="4e20″, MODE="0600″, OWNER="<username>"
# adb protocol on stingray/wingray (Xoom)
SUBSYSTEM=="usb", ATTR{idVendor}=="22b8″, ATTR{idProduct}=="70a9″, MODE="0600″, OWNER="<username>"
# fastboot protocol on stingray/wingray (Xoom)
SUBSYSTEM=="usb", ATTR{idVendor}=="18d1″, ATTR{idProduct}=="708c", MODE="0600″, OWNER="<username>"
# adb protocol on maguro/toro (Galaxy Nexus)
SUBSYSTEM=="usb", ATTR{idVendor}=="04e8″, ATTR{idProduct}=="6860″, MODE="0600″, OWNER="<username>"
# fastboot protocol on maguro/toro (Galaxy Nexus)
SUBSYSTEM=="usb", ATTR{idVendor}=="18d1″, ATTR{idProduct}=="4e30″, MODE="0600″, OWNER="<username>"
# adb protocol on panda (PandaBoard)
SUBSYSTEM=="usb", ATTR{idVendor}=="0451″, ATTR{idProduct}=="d101″, MODE="0600″, OWNER="<username>"
# fastboot protocol on panda (PandaBoard)
SUBSYSTEM=="usb", ATTR{idVendor}=="0451″, ATTR{idProduct}=="d022″, MODE="0600″, OWNER="<username>"
# usbboot protocol on panda (PandaBoard)
SUBSYSTEM=="usb", ATTR{idVendor}=="0451″, ATTR{idProduct}=="d010″, MODE="0600″, OWNER="<username>"

sudo chmod a+rx /etc/udev/rules.d/51-android.rules


[註 0] ubuntu 11.10(32位系统)下编译android源码

[註 1] Ubuntu 64 bit 编译 Android

[註 2] ubuntu安裝sun-java5-jdk

[註 3] wrappers for 32/64-bit using wrong path?

[註 4] [Linux]ubuntu 11.04(64 bit)抓取android4.0.4原始碼跟編譯source code/SDK/kernel

Render Script 小檔案

因為 Render Script 的重要性似乎比我原先想像地還要厲害, 故整理 Render Script 的用法如下. 主要參考 Google 的文件 [註1].

1. Off line Compile:

以 llvm-rs-cc compile 一個 render script (rs) 檔案, 產生 bit code (bc) 檔案, 例如底下的 foo.bc. 如果不是編成 bit code, 也可以和其他的 Java 檔編成 .Java. 這個過程可以使用 Java Reflection 的概念.

Java Reflection 能夠分析未知的 class, 把新 class 裡面的 name of the constructors, declared fields 和 methods 都抓出來. 換言之, 我們原先所寫的 .rs 檔透過 Java Reflection 取得正確的 Java API 資訊, 產生確實可用的 Java code. 而不會在 run time 才發生錯誤. 包括 Python 也是這類的 script, 而 C# 也支援 reflection, 但 C++ 沒有這個觀念. 

2.  On Line JIT Flow

等到 .bc 檔和 Java 檔都準備好之後, .bc 檔進入到 Android 所支持的 libbcc, 而 Java code 進入到 Android 的 Dalvik JIT, 跑在 DVM 上. 由下圖可以看得出來, 只有 .bc 可以用 GPU 或 DSP 來執行, 而 Java 不能. 這就是 render script 大有前途的地方.

特別值得提的是 llvm-rs-cc 會做很多大量的優化, 以便產生可移植的 .bc 檔. 而 libbcc 就是一個輕量級的 compiler, 目標只是針對本地平台已知的特性優化.

上次提到 HoneyComb 首先釋出 rs 的 API, 此時它還沒有用到平行處理. 在 ICS 版, 有個 rsForEach() 把每個 reflected Java helper 都叫起來.

RS 的範例如下:

從參數我們可以得知, 它在計算 luminance = 0.299 red + 0.587 green + 0.114 blue, 不愧是 C99 like.

[註 1] http://llvm.org/devmtg/2011-11/Hines_AndroidRenderscript.pdf