[tips] benq FP222WH + nvidia 達到原生解析度1680x1050的方法

最近辦公室的電腦換了一張nvidia 9400的顯示卡,
可是搭配上benq FP222WH ,
解析度怎麼調最大都只有640x480, (各種方法都試過了)
後來總算讓我查出是EDID的問題,
原本舊版的nvidia driver有一招是在xorg.conf設定
"IgnoreEDID" "true",
不過我新版的180.51 driver根本不適用這個方法,
後來我研究了快一天,
不過最後研究出來的解決方法倒是很簡單,
放在這提供有需要的人參考,
首先我先去抄ATI顯卡列出的EDID,
然後將它做成一個128 byte 的EDID
HEX file, 我已經做好了所以直接抓這個檔案擺在/etc/x11就可以

http://kalug.linux.org.tw/~tim/benq/benq-c.bin

然後在你的xorg.conf裡加上幾行,
(請自行比對xorg.conf的相異處)

Section "Monitor"

Identifier "Monitor0"
VendorName "Monitor Vendor"
ModelName "Monitor Model"
HorizSync 30.0 - 86.0
VertRefresh 60.0

# 1680x1050 @ 60.00 Hz (GTF) hsync: 65.22 kHz; pclk: 147.14 MHz
Modeline "1680x1050_60.00" 147.14 1680 1784 1968 2256 1050 1051 1054 1087 -HSync +Vsync

EndSection

Section "Screen"
Identifier "Screen0"
Device "Card0"
Monitor "Monitor0"

Option "ConnectedMonitor" "DFP"
Option "CustomEDID" "DFP-0:/etc/X11/benq-c.bin"
Option "UseDisplayDevice" "DFP" # DVI out

SubSection "Display"
Viewport 0 0
EndSubSection
EndSection

我的是DVI接頭,
另外一個同事用的是DSUB(VGA) 的,
他說只要DFP改成CRT也可以用,
我們一個是用debian一個是用gentoo,
在預設情形下解析度都是錯誤的,
但是透過這個方法就可以達到原生解析度1680x1050. :)

[rant] igoogle gmail gadget: The Gmail gadget does not support the "Always use https"

最近我經常使用的igoogle gmail gadget突然出現:

The Gmail gadget does not support the "Always use https" setting that you chose in full Gmail. If you would like to use https, please open full Gmail. Learn more


問題是我一直以來Always https都是用得好好的啊，怎麼突然就出問題了，
我點下Learn more之後出現了標準的廢話連篇又毫無用處的典型答非所問的問答集:


Google 說明 › Gmail 說明 › 您的帳戶 › 隱私權與安全性 › 啟用 HTTPS 設定
啟用 HTTPS 設定
-「Gmail 通知器」使用者必須下載相關修補程式，才能使用這個設定。 瞭解更多資訊
- 啟用此設定可能會使 Gmail 行動版應用程式發生錯誤。 瞭解更多資訊

透過不安全的網際網路連線 (例如公用無線網路或未加密的網路) 登入 Gmail 時，可能會讓人可輕易盜用您的 Google 帳戶。在不安全的網路中，他人很容易偽裝成您，並取得您「Google 帳戶」的完整存取權，藉以存取您帳戶中的機密資料，例如銀行帳戶資料或線上登入憑證。您使用有安全疑慮的網路時，建議您在 Gmail 中選取 [永遠使用 https] 選項。 HTTPS (亦稱「超文字安全傳輸通訊協定」) 安全通訊協定會將通訊內容加以驗證及加密。

在 Gmail 中啟用這個功能：

1. 登入 Gmail。
2. 按一下任何 Gmail 頁面頂端的 [設定]。
3. 將 [瀏覽器連線] 設定為 [永遠使用 https]。
4. 按一下 [儲存變更]。
5. 重新載入 Gmail。

請注意，選取 [永遠使用 https] 後，您將無法透過 HTTP (超文字傳輸通訊協定) 存取 Gmail， 且 Gmail 的運作速度可能會變慢。 如果您使用的網路安全無虞，可以隨時關閉這個功能。

如果您使用公用電腦查看電子郵件，請務必在要關閉 Gmail 時，按一下任何 Gmail 頁面頂端的 [登出]，並關閉所有 Gmail 瀏覽器視窗。

廢話，騙小孩唷，算了 自己搜尋一下看看是甚麼情形，看了一堆抱怨串之後找到始作俑者:

http://www.google.com/support/forum/p/Web+Search/thread?tid=41f74befcd5f3d28&hl=en&fid=41f74befcd5f3d28000468c96d31ef91

Paul
Google Employee

Hi everyone,

As several of you have noticed, we made a change in iGoogle to the way that iGoogle's Gmail gadget works. If you previously set Gmail to only access your mail using https by selecting "Always use https" in Gmail's settings, you will now see a message in iGoogle's Gmail gadget asking you to open the full version of Gmail. We made this change in iGoogle for those users who want to ensure that their Gmail is transmitted using https.

We know that many of you would like to access your mail from iGoogle with https, and we're investigating ways to provide https support for iGoogle's Gmail gadget. In the meantime, you have a couple of choices:

- If you'd prefer to access your mail with https, please visit Gmail directly at https://mail.google.com/mail.
- If you'd rather get your Gmail on iGoogle with the Gmail gadget, visit Gmail's Settings page and select "Don't always use https."

We apologize for any inconvenience this may have caused.

只是覺得很奇怪，他不會功能做好再來給我改嗎?
原本的code跑得好好的
現在突然爛了又講一堆廢話，還要自己搜尋才找的到，Orz！

===

這真是一個可以拿去給RMS當反面宣傳的例子，
為啥我們應該要拒絕使用close source的web application...　
就算是把"Don't be evil"掛在嘴邊的google也一樣...

-- 因為一個用了一兩年的功能還是可以突然停掉並且都不用事先公告的。

ref 來自gmail gadget八百五十萬使用者的抱怨串:

http://www.google.com/support/forum/p/gmail/thread?tid=41eb24edefcd7a41&hl=en
http://www.google.com/support/forum/p/Web+Search/thread?tid=41f74befcd5f3d28&hl=en
http://groups.google.com.tw/group/Google-Desktop_Something-Broken/browse_thread/thread/71dd8b27ccacc0ba

[Note] 送patch所學到的事

這個Note是一個寫patch的經驗，前陣子寫了一個讓curl即時壓縮加密FTP/HTTP/SFTP上傳時可以續傳的一個patch，patch本身倒是沒什麼特別的，反而是在送patch跟原作者的討論過程中學到了一些東西。patch歷時約一個月才commit進cvs，不過我覺得以open source的專案來說，這樣算挺快的。

似乎還是得把前因後果交代一下，
其實一開始是我有一個想法，
就是希望我上傳到遠端伺服器的檔案都能加密起來(順便壓縮更好)，
但是我覺得在local這邊先壓縮過然後再上傳的話，就會佔Local的硬碟兩份空間，所以最好的方法是realtime壓縮加密之後上傳。這樣就不會佔用local的硬碟空間，而以目前的CPU也應該都可以做到即時傳輸。
此外我希望就是能夠彈性的選擇壓縮及加密方式，不論是bz2,gzip,pkzip或是pgp及AES都要能夠自行選擇及combine。
而且最好是不需另外的伺服器程式，以目前hosting都會提供的FTP帳號就能做的方法是最好。(我需要的不是像SFTP或FTP/TLS這樣傳輸時加密或壓縮而已，我想要的是在伺服器上的最終結果也是加密及壓縮過的)

跟lloyd討論之後，他是認為lftp+namepipe的方式可行。
另外我也找到了用pipe透過curl上傳的方法。
而這兩個方法也都驗證過確實可行，不過這兩個方法都同樣有個問題，就是沒辦法續傳，而這我認為是個應該要解決的問題。

比較了兩個解決方案後，我選擇了擁有我比較喜歡的BSD license，用法也比較彈性的curl下手修改，
curl的續傳問題大概長這樣：

gzip /mnt/2311/debian-500-i386-CD-1.iso -c | curl -T - -C -
ftp://myname:mypass@192.168.23.11/debian-500-i386-CD-1.iso.gz
** Resuming transfer from byte position 46792704
% Total % Received % Xferd Average Speed Time Time Time
% Current
Dload Upload Total Spent Left
Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:--
0
curl: (31) Could not seek stream

最主要是stdin不能直接SEEK_SET，這其實不是什麼大問題，不能SEEK_SET就SEQUENCIAL READ並bypass即可，看了一下原始程式便發現其實這段code早已大部完成了，只要略為更動即可，
於是略為修改了一下curl FTP/SFTP/HTTP上傳部份的code，驗證之後便將patch送出。
原以為送出patch之後就結束了，因為作者要收不收這也不是我能控制的，不過後來curl的作者回信說，功能是沒有問題，但原本的patch會影響到ABI與目前文件的相容性，問看看我是否能提供不修改ABI的作法，我原本還無法理會作者的意思，後來繼續討論才慢慢了解，作者的意思是看能否提供完整的ABI及定義回傳值供其他使用curl library部份的程式參考，因為curl不僅僅是一個客戶端程式curl，同時也包含一套廣泛的運用在其他程式甚至內建在程式語言中的library，libcurl。即使是改動小小的部份，也有可能不經意的影響到其他重要的程式。
了解了作者的目的之後，於是我又寫一個新的patch配合這個架構，測試一下續傳上傳沒問題之後就又再次的送出，這次作者將我的多個patch檔結合後又修改了一下包括說明文件的patch就直接commit到cvs上，不過問題來了，做make test的測試到HTTP PUT該項時沒過。
仔細的研究一下，還真的是第二次更動的code造成了問題。第三次的修改並驗證之後，這次就很快的patch就被接受了，目前已經commit在curl的cvs上。

這次寫patch得到一些經驗:

1. 寫patch時應配合原程式的架構及style，會比較容易被接受。
2. 寫完patch之後應照原程式的測試方式做一遍測試，而非只是測試自己的情況。
3. 大部份時候都要仔細考慮並聆聽來自原作者的意見，畢竟他是最清楚全部情況的人。
4. 不要懶的送patch，雖然可能會多費一些時間跟功夫，但送了patch通常可以學到更多。

ref: 我和curl作者討論的過程，https://sourceforge.net/tracker/?func=detail&atid=100976&aid=2709004&group_id=976