20:00 <@jserv> 19:59
20:00 <@frid> gogogo
20:00 <@jserv> 20:00
20:00 <@jserv> ....... buffering .........
20:01 <@jesse_> 時間到囉 :)
20:01  * jesse_ 拍手~
20:01 <@moto_> yoyoyo
20:01 <@frid> clap
20:01  * moto_ 拍手
20:01 < Vela> :)
20:02  * AceLan 啪啪啪
20:02 <@jserv> ..... starts ....
20:02 <@jserv> 各位好，在下是 Jim Huang <jserv @ kaffe.org>，有幸能在這裡與各位朋友
20:02 <@jserv> 分享一些經驗。當然，小弟只是與各位分享，並不是什麼權威，所以很可能無
20:02 <@jserv> 法招架，但沒關係，請多討論，說不定在眾人腦力激盪、合力找資料與分析下
20:02 <@jserv> ，說不定很快就可以釐清問題。
20:02 <@jserv> 本次 IRC Conference 基本上是 FreeDesktop.org 與 X.org 嶄新發展介紹的
20:02 <@jserv> 續集，這裡假設與會的朋友已有上一場的經驗與認知，如果沒有，可以自行參
20:02 <@jserv> 閱過去的 IRC log：
20:02 <@jserv>   http://ircconf.debian.org.tw/
20:02 <@jserv> 感謝各位朋友抽空共襄盛舉，再來要感謝神奇的網路把物理距離遙遠的我們，
20:02 <@jserv> 能夠透過 IRC 作即時的交流，有任何問題或建言，請踴躍提出，謝謝！
20:02 <@jserv> ---------------------------------------------------------------------
20:02 <@jserv>   Copright (c) 2004 Jim Huang and Debian@Taiwan IRC Conference 
20:02 <@jserv>                     Attendants. All rights reserved.
20:02 <@jserv>   Permitted to redistribute the following IRC log content with
20:02 <@jserv>   authors' information (nickname, date, or something identified)
20:02 <@jserv>   without modifications.
20:02 <@jserv>   For advanced usage (such as COMMERCIAL purpose and publish),
20:03 <@jserv>   you MUST contact the original author(s).
20:03 <@jserv> ---------------------------------------------------------------------
20:03 <@jserv> 本次 IRC Conference 大致分兩個部分，前半部討論嶄新的 X Extensions，而
20:03 <@jserv> 後半部則是簡單介紹一些非 FreeDesktop.org 直接相關，但是頗值得一書的項
20:03 <@jserv> 目，當然也包含筆者近來進行的一些計畫與實驗。關於嶄新的 X Extensions，
20:03 <@jserv> 筆者規劃了以下流程：
20:03 <@jserv>     GL --> DRI/DRM --> X Render Extension --> Font (Xft / Fontconfig)
20:03 <@jserv>       \
20:03 <@jserv>        \__
20:03 <@jserv>           \--- Cairo --> Glitz
20:03 <@jserv>                                                                                 
20:03 <@jserv>     XDamage + XFixes --> XComposite
20:03 <@jserv>                                                                                 
20:03 <@jserv>     Sun Looking Glass --> XEvIE
20:04 <@jserv>     XInput Hotplug
20:04 <@jserv> 有鑑於許多朋友反應上次 IRC Conference 的節奏過快，所以本次偏向較少的文
20:04 <@jserv> 字與較多的討論，還請各位朋友踴躍提問。
20:04 <@jserv> ---------------------------------------------------------------------
20:04 -!- _benny_ [~benny@218-175-26-94.dynamic.hinet.net] has joined #debian.tw
20:05 <@jserv> DRI -- Direct Rendering Infrastructure
20:05 <@jserv> DRI 是 XFree86 相當重要的嶄新設計，這在許多層面已經跳脫傳統 Client /
20:05 <@jserv> Server 的架構了。Client / Server 架構下使用相當緩慢的 transport 機制
20:05 <@jserv> ，從 Client 端將 rendering 指令，送到 Server 端，這在普通的應用來說，
20:05 <@jserv> 已經足夠了，但是對於 3D Graphics 顯然是很大的效能瓶頸 -- 耗費太多時間
20:05 <@jserv> 在 round-trip (繪圖指令的往返) 通信上 [按1]。於是，能否提供更為直覺、
20:05 <@jserv> 簡單的設計，讓 client 可以直接與 Graphics Hardward 對話呢？
20:05 <@jserv>   [按1] X Window System 的 Transport 瓶頸可以從其架構得知 --
20:05 <@jserv>         http://gallery.debian.org.tw/2004-10-21/x_arch_comparison ]
20:05 <@jserv> 在探討 DRI 之前，筆者要強調 DRI 對於 XFree86 / XOrg 的重要性。較早接
20:05 <@jserv> 觸 Linux 或 FreeBSD 的朋友都經歷過 XFree86 3.x 系列必須選用特定顯示卡
20:05 <@jserv> X server 的年代，當時的設計還是僅依循 DDX (Device-Dependent X) 與 DIX
20:05 <@jserv> (Device-Independent X) 的劃分，其硬體加速能力也是有相當的限制。
20:06 -!- yungyuc [~yyc@220-134-24-5.HINET-IP.hinet.net] has joined #Debian.tw
20:06 <@jserv> 而在 March 8, 2000 的 XFree86 4.0 版釋出後，有了完全的改觀，一來是整合
20:06 <@jserv> MetroLink (一家相當著名的商業 X Server 製造商 [按2]) 貢獻的模組化程式
20:06 <@jserv> 碼，二來就是 DRI 架構的落實，給予更大的彈性與更好的表現。這段發展歷史
20:06 <@jserv> 變遷，筆者整理成以下的表格：
20:06 <@jserv> 日期       |      重大事件
20:06 <@jserv> (年/月/日) |
20:06 <@jserv> ----------- ----------------------------------------------------------
20:06 <@jserv> 1998/8     | 展開 DRI High Level 設計 (評估階段)
20:06 <@jserv> 1998/12    | 展開 DRI Low Level 設計
20:06 <@jserv> 1999/1     | DRI 實作計畫展開，與 MESA (Free/Open Source Open GL 實作)
20:06 <@jserv>            | 計畫整合發展
20:06 <@jserv> 1999/2/1   | MESA 3.1 採 XFree86 / BSD / MIT 型態授權
20:06 <@jserv> 1999/2/16  | SGI 將其 GLX (GL Extension) 實作以 open source 授權釋出
20:06 <@jserv> 1999/5/12  | DRI Low Level 設計文件上線
20:06 <@jserv> 1999/6     | DRI 1.0 實作釋出
20:06 <@jserv> 2000/3/8   | XFree86 version 4.0 版釋出
20:06 <@jserv> 2000/6     | SGI 捐出 GLX 與字型處理技術給 XFree86
20:06 <@jserv> 2000/10/27 | X Render Extension 首度現身於 XFree86 4.0.1d
20:06 <@jserv>   [按2] 筆者已經找不到 MetroLink 公司的網頁了
20:06 <@jserv> ---------------------------------------------------------------------
20:06 <@jserv> Questions?
20:07 <@jserv> [工商服務時間]
20:07 < _benny_> LOL
20:07 <@frid> ha
20:07 <@AceLan> yo
20:07 <@jserv> 新酷音的發展網頁已經上線，請多加支持： http://chewing.csie.net/
20:08 <@jserv> 謝謝！
20:08 <@jserv> ---------------------------------------------------------------------
20:08 <@AceLan> KDE@Taiwan 聚會 04/01/23 請參考網頁 http://kde.linux.org.tw/ 
20:08 <@AceLan> 謝謝
20:08 <@jserv> 直接與硬體溝通的 Graphics Toolkits / Window System 相繼被提出，也有不
20:08 <@jserv> 錯的效能表現，但是在 X Window System 的設計原則，是希望透過層層的架構
20:08 <@jserv> ，讓硬體能夠抽象化，是否意味著我們將無法處理 3D Graphics 呢？這是個相
20:08 <@jserv> 當大的挑戰，一方面要能處理硬體，另一方面要依循 X Window System 的設計
20:08 <@jserv> 原則，於是 XFree86 Developer 提出 DRI (Direct Rendering Infrastructure)
20:08  * AceLan 笑得倒在地上打滾。
20:08 < _benny_> 啊
20:08 <@jserv> 的機制。
20:08 <@jserv> 不同於過去使用 Xlib 來傳遞 rendering request 給 X server 的方式，DRI
20:08 < _benny_> 來不及
20:08 <@jserv> 引入一個捷徑，重點在於事先部署好能夠直接與硬體溝通的 Kernel Driver，然
20:08 <@jserv> 後 DRI 直接將 rendering commands/data 傳遞給該 driver，X Client 在此機
20:08 <@jserv> 制下，仍是與其他 2D 或 3D X Client 共享 X Resources。那麼，究竟是哪個環
20:08 -!- descent [~descent@219-84-137-217-adsl-tpe.static.so-net.net.tw] has quit [EOF From client]
20:08 <@jserv> 節特別了呢？
20:08 <@jserv> X Resources 的處理還是透過 X server 原有的機制，但是真實的 rendering，
20:08 <@jserv> 或者明確來說，對螢幕/輸出裝置的顯示，是直接透過 Kernel-level driver 來
20:09 <@jserv> 實現的。這意味著，透過 DRI，Graphics driver 的開發者可以將過去開發的 DDX
20:09 <@jserv> driver 移轉到 DRI Kernel Driver、Client DRI Driver library，或者是 X 
20:09 <@jserv> server 中，這樣一來，除了效能的優勢，再來是安全性的考量，理論上，User
20:09 <@jserv> ---------------------------------------------------------------------
20:09 <@jserv> Questions?
20:09 < _benny_> nope
20:09  * jserv 納悶：「這麼枯燥的文字大家怎麼都看得懂？」
20:09 <@frid> 看不懂才沒問題..Orz
20:09 < _benny_> 請問
20:09 <@jserv> 稍微補充一下
20:10 < _benny_> xfree-drm
20:10 < _benny_> 是否沒有支援 2.6 kernel?
20:10  * AceLan 在等下次的工商時間 XD
20:10 <@jserv> _benny_: 有的
20:10 < _benny_> AceLan: 讓人家先啦6
20:10 <@AceLan> _benny_: 一起阿
20:10 <@jserv> _benny_: 但是 Kernel 2.6 的 DRM 明顯比 2.4 series 少許多
20:11 -!- Sinsun [HydraIRC@219-84-86-97-adsl-tpe.static.so-net.net.tw] has joined #debian.tw
20:11 < _benny_> jserv: 啊。。那請問 kernel 內的跟自己弄成 module 的插在那裡
20:11 <@jserv> _benny_: 因為 Linux Kernel 2.6 採用新的 MMIO 機制
20:11 <@jserv> _benny_: 好問題，稍後會介紹
20:11 < _benny_> ok
20:11 < _benny_> 請繼續
20:11 <@jserv> ---------------------------------------------------------------------
20:11 <@jserv> 有了以上的概念，咱們先理解以下關鍵字： 
20:11 <@jserv>   . RM --> Resource Management
20:11 <@jserv>   . 2D --> 2D Commands and Data
20:11 <@jserv>   . 3D --> 3D Commands and Data
20:11 <@jserv>   . SAREA --> DRM Shared Memory
20:12 <@jserv> 接著就要進入重頭戲 -- XFree86 4.x DRI 運作示意圖：
20:12 <@jserv>   http://gallery.debian.org.tw/2004-12-02/dri_gram
20:12 <@jserv> 是的，DRI 的引入後，整個軟體架構變得相當複雜，讓我們抽絲剝繭，揭開這一切
20:12 <@jserv> 神秘的面紗。
20:12 <@jserv> ---------------------------------------------------------------------
20:12 <@jserv> 這裡，我們將停頓片刻，讓各位看清楚這複雜的 DRI 架構
20:13 <@jserv> 呼應上一場 IRC Conference 裡頭的重點：
20:13 <@jserv>   「X Window System 的精髓在於 X Protocol」
20:13 <@jserv> 由上往下看，在 Xlib 之下的就是 Protocol Engine，為數眾多的 command/data 
20:13 <@jserv> 組合將透過網路 (廣義的說法) 派送到 Server，而 X server 處理 X Protocol 則
20:13 <@jserv> 有對應的 Protocol Decoder，這個部分並沒有涉入多少 Grapghics，就抽象來說，
20:13 <@jserv> 可以視為 Data bus，於是我們稱為 X Transport，這是無法避免的成本，儘管已經
20:13 <@jserv> 有許多改良的途徑相繼提出，比方說透過 POSIX Shared Memory。
20:13 <@jserv> 圖-1 中央的流程便是我們熟知的模式，而一旦導入 X11/OpenGL 後，情勢就有很大
20:13 <@jserv> 的轉變。
20:13 <@jserv> ---------------------------------------------------------------------
20:13 -!- descent [descent2@219-84-137-217-adsl-tpe.static.so-net.net.tw] has joined #debian.tw
20:14 <@jserv> 再度補充，Transport 的實作幾乎都是商業 X server 的賣點
20:14 <@jserv> 以 Sun 的 X Window System 來說，其 X11 Transport 的設計就領先同業有相當大的距離
20:15 <@jserv> 這一方面是針對 Sparc 作了最佳化，另一方面是獲得 Solaris 作業系統的整合
20:15 <@jserv> 但無論如何，我們可以發現另一個瓶頸
20:15 <@jserv> 就是 Rendering 的處理
20:16 <@jserv> 我們的重點將置放於 X11/OpenGL 的展現
20:16 <@jserv> Direct rendering program (3D):
20:16 <@jserv> Direct rendering (3D data) -> 3D data -> Graphics Hardware
20:16 <@jserv> Direct rendering program (2D):
20:16 <@jserv>   X Protocol Encode -> Protocol Decode -> DIX -> 
20:16 <@jserv>   XAA -> DDX Driver -> Graphics Hardware
20:16 <@jserv>  
20:16 <@jserv> Indirect rendering program (2D):
20:16 <@jserv>   X Protocol Encode -> Protocol Decode -> DIX -> 
20:16 <@jserv>   XAA -> DDX Driver -> Graphics Hardware
20:16 <@jserv> Indirect rendering program (3D):
20:16 <@jserv>   X Protocol Decode -> GLX -> Mesa (including SW rasterizer) -> 
20:16 <@jserv>   DDX Driver -> Graphics Hardware 
20:16 <@jserv> ---------------------------------------------------------------------
20:17 <@jserv> Questions
20:17 <@jserv> 回應剛剛 _benny_ 提到的問題
20:17 -!- SchizShia [C@61-230-80-229.dynamic.hinet.net] has joined #debian.tw
20:18 < _benny_> 有點難懂
20:18 < _benny_> XD
20:18 <@jserv> 在過去 XFree86 3.x 系列的實作，DDX driver 有很多部分是處理底層 device routines
20:18 <@jserv> 我們都知道作業系統在做 content switching 是無法避免的成本消耗
20:19 < _benny_> 嗯
20:19 <@jserv> DDX driver 都帶有許多 magic 成分在
20:19 <@frid> magic
20:20 <@jserv> 除了 XFree86 4.x 的 DRI 之外，有個稱為 Utah GLX 的架構
20:20 <@jserv> 在觀念上是相當接近的，但是實作的技術有很大的落差
20:21 <@jserv> DRI 特別之處是需要 Kernel Level 的整合
20:21 -!- how [~how@59-104-242-123.adsl.dynamic.seed.net.tw] has joined #debian.tw
20:21 <@jserv> 現在的問題在於能否降低非必要的 latency
20:21 < _benny_> true
20:21 <@jserv> [工商服務時間]
20:21 <@AceLan> Qt Quarterly 中文翻譯計畫 歡迎大家一起參與 - http://kde.linux.org.tw/index.php?Qt%20Quarterly%28Traditional%20Chinese%29
20:21 < SchizShia> ...
20:22 <@frid> ha
20:22 -!- tedyu [~tedyu@79-208.dorm.ncu.edu.tw] has joined #debian.tw
20:22  * AceLan 貪婪地舔了舔 _benny_ 的臉。
20:22 <@jserv> 請支持 Qt Quarterly 中文翻譯計畫  :-)
20:22 < _benny_> 歡迎各位參加 GOT 的聚會 http://wiki.gentoo.org.tw/index.php/GentooUserParty2004-1 也有 jserv 的演講喔!!
20:22 < _benny_> 可惡， AceLan 打好再那邊等
20:22  * AceLan 笑得倒在地上打滾。
20:22 < _benny_> 聚會日期是 1/15
20:22 <@jserv> 對了，有個好消息
20:22 <@frid> trigger
20:22 <@jserv> 感謝 courage 兄的貢獻，現在成果已經進駐 svn.csie.net，請見：
20:22 <@jserv>     http://sdl-im.csie.net/
20:22 <@jserv> 這個專案的目標就是希望能夠提供 SDL 下的輸入法解決方案，目前 MS-IME
20:22 <@jserv> 與 XIM 都已經初步支援了，希望最後這些成果可以整合到 SDL 官方 release
20:22 <@jserv> 有興趣參與者，請聯絡 courage 兄或我，謝謝！
20:23 <@jserv> 以往 SDL 的遊戲無法使用輸入法的窘境已經克服了！
20:23 <@frid> cool
20:23 < _benny_> 廣告打完了
20:23 <@jserv> back
20:23 <@jserv> ---------------------------------------------------------------------
20:23  * _benny_ 趁機非踢 AceLan 
20:23 <@jserv> 再回到上圖
20:24 <@jserv> 使用 MMIO： (Memory-mapped I/O)
20:24 <@jserv>   . OpenGL Renderer --> Graphics Hardware  
20:24 <@jserv>   . DDX Driver --> Graphics Hardware
20:24 <@jserv> 使用 SHM： (Shared Memory IPC)
20:24 <@jserv>   . DRM Library --> SAREA
20:24 <@jserv> 使用 DMA：
20:24 <@jserv>   . DRM Driver --> Graphics Hardware
20:24 <@jserv> 這裡是非常難懂的一段落，必須有足夠的 H/W Graphics Devices 知識才能徹底理解
20:24 <@jserv> 我試著用很簡單的話帶過
20:25 <@jserv> 為何要分如此多層次？
20:25 <@jserv> 我們都知道 C/S 架構下的衝擊非常的大，DRI 架構的提出，就是提供許多緩衝的設計
20:27 <@jserv> 讓 SHM / MMIO / DMA 等基礎建立一系列 Hardware Acceleration 的可能性
20:27 <@jserv> ---------------------------------------------------------------------
20:27 <@jserv> Questions?
20:27  * jserv 的網路卡住了 :(
20:27 <@frid> !!
20:28 < kanru> orz
20:28 < SchizShia> ．．．
20:28 <@jserv> 各位，小弟要換個 AP 
20:28 <@jserv> 造成不便請多見諒
20:28 <@frid> cheer jserv
20:28 <@jserv> [工商服務時間]
20:28 < _benny_> 歡迎各位參加 GOT 的聚會 http://wiki.gentoo.org.tw/index.php/GentooUserParty2004-1 也有 jserv 的演講喔!!
20:28 < _benny_> 歡迎各位參加 GOT 的聚會 http://wiki.gentoo.org.tw/index.php/GentooUserParty2004-1 也有 jserv 的演講喔!!
20:28 < _benny_> 歡迎各位參加 GOT 的聚會 http://wiki.gentoo.org.tw/index.php/GentooUserParty2004-1 也有 jserv 的演講喔!!
20:28 < _benny_> 哈哈哈
20:28 < SchizShia> cheer jserv XD
20:28 < _benny_> 要被踢了
20:28 < kanru> XD
20:28 <@frid> 哈哈
20:29 <@frid> 鬧場
20:29 <@AceLan> @_@
20:29 <@AceLan> KDE@Taiwan 聚會 04/01/23 請參考網頁 http://kde.linux.org.tw/ 
20:29 <@AceLan> KDE@Taiwan 聚會 04/01/23 請參考網頁 http://kde.linux.org.tw/ 
20:29 <@AceLan> KDE@Taiwan 聚會 04/01/23 請參考網頁 http://kde.linux.org.tw/ 
20:29 < _benny_> 哈哈哈
20:29 <@AceLan> 也有 jserv 的演講喔!!
20:29 <@frid> 哈
20:29  * _benny_ 飛舔 AceLan 
20:29 <@frid> jserv 變成日本av 女優了
20:29 <@frid> 有他才有人潮
20:29 <@AceLan> jserv 超搶手的
20:29 < _benny_> AceLan: 看在你也是 sony sucker 的份上，我就饒了你 :p
20:30  * AceLan 「嘿嘿嘿....」地奸笑了幾聲。
20:30 <@jserv> useless :(
20:30 <@jserv> 好吧，繼續
20:30 <@frid> @_@
20:30  * AceLan 狠狠的咬了 _benny_ 一口，把他咬的哇哇大叫...真爽 真爽
20:30  * kanru hold jserv 
20:30 < _benny_> 咬拆開變成 口交...
20:30  * AceLan 趁機偷咬 _benny_  :p
20:30 < _benny_> 原來。。。
20:31 < _benny_> jserv: 繼續吧:p
20:31 <@frid> 把他口交的哇哇大叫...真爽 真爽
20:31 <@jserv> 先跳過 DRI/DRM 複雜的設計，我們來探討 XInput Hotplug
20:31  * AceLan 撲通地跌了一跤。
20:31 <@jserv> ---------------------------------------------------------------------
20:31 <@Tyson> ....
20:31 <@jserv> XInput Hotplug 是個相當複雜的議題，但是對 Desktop 需求又是
20:31 <@jserv> 相當重要。試想，當我們將 USB 介面的手寫版插入時，X Window
20:31 <@jserv> 可否自動偵測該 device，並且驅動其功能？Linux Kernel 可以提
20:31 <@jserv> 供 HAL 資訊，但是目前的 XFree86-based 實作在 XInput Hotplug
20:31 <@jserv> 的不完善導致相當多問題。
20:31 <@jserv>                                                                                 
20:31 <@jserv> XOrg hacker 著手處理這議題，整理各方意見放在 wiki page 中：
20:32 <@jserv>                                                                                 
20:32 <@jserv>     http://xorg.freedesktop.org/wiki/XInputHotplug
20:32 <@jserv> 就目前的設計來說，X server (XOrg) 並不支援 input devices 的 Hotplug，這
20:32 <@jserv> 表示說，你無法在不更動設定檔以及重新啟動 X server 的前提下，動態的新增或
20:32 <@jserv> 移除任何 input devices。然而，在 Linux Kernel 2.4 以來，Hotplug 的實作已
20:32 <@jserv> 經有相當卓越的設計，並且提出抽象化 (abstraction) 的途徑，可以很容易加入
20:32 <@jserv> input devices 的 hotplugging，包含鍵盤、滑鼠、搖桿，甚至是其他特殊的裝置。
20:32 <@jserv> XInputHotplug 的目標就是希望能夠銜接 Linux Kernel 或是底層 Kernel 提供的
20:32 <@jserv> Hotplug 機制，做到真正不需要更改設定檔，而能動態處理任何 input devices 的
20:32 <@jserv> 支援。
20:33 <@jserv> ---------------------------------------------------------------------
20:33 <@jserv> Questions?
20:33  * jserv 繼續卡 :(
20:33 <@frid> 所以在純文字下有hotplug 在X 夏不行.Orz
20:34 <@jserv> frid: 這是好問題，XInput Hotplug 要實現必須很多方面配合
20:34 <@frid> jserv : 這後面會提到嗎?
20:34 <@jserv> frid: Linux Kernel 2.4 系列以後，許多 character devices 的架構也獨立為 input device
20:35 < descent> jserv, ex os kernel ??
20:35 <@jserv> frid: XOrg 也是朝這個方向前進
20:35 <@frid> jserv : nod!
20:35 <@jserv> descent: 嗯
20:35 <@jserv> frid: 詳細的資訊與實作方式，在該 wiki 有介紹到
20:35 -!- alecc [~alecc@218-163-2-216.dynamic.hinet.net] has joined #debian.tw
20:36 <@jserv> ---------------------------------------------------------------------
20:37 <@jserv> ..
20:37 <@jserv> 敗 :(
20:37 < _benny_> :(
20:37 <@frid> 無言.? Orz
20:37 <@jserv> 網路又卡住了，真抱歉 :(
20:37  * frid 幫jserv 槌搥背
20:38 < descent> 改用有線如何
20:39 <@jserv> 接著，我們來看 XRender extension
20:39 <@jserv> 就目前來說，Xft / Fontconfig / Xrender 這三者已經密切的整合在一起
20:40 < _benny_> 酷
20:40 <@jserv> 但是，Xrender 對 Graphics Design 確有其意義在
20:40 < _benny_> 重點來了 XD
20:40 <@jserv> 引述我之前的筆記：
20:40 <@jserv> <%
20:40 <@jserv>                    OSD 在 X11 下的實現
20:40 <@jserv>                                          Jim Huang <jserv@kaffe.org>
20:40 <@jserv>                                               最後更新：Dec 12, 2004
20:40 <@jserv> [動機]
20:40 <@jserv> 因為需要發展一套全功能的 Media Player，目前採用的 codebase 是 Xine，在
20:40 <@jserv> xine-ui 設計了一套 xitk，能夠處理 OSD (On-Screen Display)，但是這不適合
20:40 <@jserv> 通用性處理，所以筆者試著參考 XOSD[1] 這套實作，在追蹤後，發現很難在視覺
20:40 <@jserv> 效果與效能上有所突破，是此依循分析結果，紀錄 OSD 在 X11 下的實作心得，
20:40 <@jserv> 以及效能衝擊的瓶頸。
20:40 <@jserv> [現有的問題]
20:40 <@jserv> X Window System 是個 Client-Server 的架構，在此架構下的效能衝擊因素之一
20:40 <@jserv> 就是大量的資料傳輸，當然，多數的情況下，只是少量資料的傳遞，比方說將某個
20:41 <@jserv> 視窗 Window 移動到座標軸 [x,y] 之處一類的操作，然而，只要圖片或
20:41 <@jserv> 影像涉入後，效能的衝擊就相當明顯。
20:41 <@jserv> 有許多途徑相繼被提出，比方說透過 shared memory (亦即 SHM extension)，
20:41 <@jserv> 但是為了一般性，或者在不依賴 extension 的前提下，我們應該儘可能避免資料
20:41 <@jserv> 傳遞。
20:41 -!- hat1 [~hata@210-85-125-2.cm.dynamic.apol.com.tw] has joined #debian.tw
20:41 <@jserv> X 有兩種互補的型態：Pixmap 與 Image。就 X client 的觀點，Pixmap 就是個整
20:41 <@jserv> 數型態的 handle，而 Image 則是一個巨大的 struct，事實上，Pixmap 是存在於
20:41 <@jserv> X server 端的圖形資料，而 Image 是存在於 X client 的資料。這兩者可以轉換
20:41 <@jserv> ，但是效能成本就相當不小了，在半透明 (translucent) 視窗的實現中，這是很
20:41 <@jserv> 嚴重的效能衝擊，而另外一個議題就是，我們無法在不對 Screen 作 polling 的
20:41 <@jserv> 前提下，得知 Window 下資料是否更動過，甚至就算當我們發現 Screen 已經被更
20:41 <@jserv> 動了，Window 本身卻對我們想取得的 Screen 資料一無所知。是此，過去 X11 許
20:41 <@jserv> 多半透明實作來說，意味著效能上的衝擊，因為必須訴諸許多 polling 與大量資
20:41 <@jserv> 料傳輸。
20:42 <@jserv> 在未引入 XFree86 4.x 提出的 Xrender extension 之前，半透明 效果是透過這
20:42 <@jserv> 樣的方式實作的：先捕捉我們 Window 所在的 Screen 的 snapshot，然後在 X
20:42 <@jserv> client 端施加 Alpha composition，以達到我們想要的效果。這樣會有兩個效能
20:42 <@jserv> 疑慮：
20:42 <@jserv>   (1) snapshot 需要取得 X client 的圖形資料 (緩慢的資料傳輸)
20:42 -!- asho [~asho@220-135-210-115.HINET-IP.hinet.net] has joined #debian.tw
20:42 -!- mode/#debian.tw [+o asho] by AceLan
20:42 <@jserv>   (2) 在 Alpha composition 後，圖形資料必須被傳回 (再度緩慢的資料傳輸)
20:42 <@jserv> --------------------------------------
20:42 <@jserv> 先提到這，大家可以想見周旋在 Client<-->Server 之間的資料傳輸量是何等的大
20:43 < _benny_> 所以這就是現階段的透明的問題囉？
20:43 <@jserv> 在筆者初期設計 Media Player 的 OSD 支援時，並沒有考慮到這些議題
20:43 <@jserv> 往往造成效能的落差
20:43 <@jserv> _benny_: Got it
20:44 <@jserv> _benny_: 這也是「真透明」與「假透明」的分野！
20:44 < _benny_> 真透明在 xorg 還是太慢了 :(
20:44 < descent> jserv, 為何是 假透明
20:44 <@frid> agree
20:44 <@jserv> _benny_: no, it's resulted from improper driver
20:44 < _benny_> 假透明就是 xchat/*term 那種只看的到背景的
20:45 < _benny_> 而無法看看到在背後app
20:45 <@jserv> descent: 假的透明度是用上述的作法，慢慢畫出來得
20:45 <@jserv> 好，回到 Xrender，看看怎麼解決問題
20:45 <@jserv> ---------------------------------------------------------
20:45 <@jserv> [改善的方式]
20:45 <@jserv> Xrender 一開始被提出的訴求是為了支援 anti-aliased 字型。在字體邊框的
20:45 <@jserv> pixel rendering 相當類似 composition，簡單來說，這類的狀況就是我們的繪
20:45 <@jserv> 圖呈現跟背景有關，所以 Xrender 還提供一些與 Glyphs 有關的資料型態，這
20:45 <@jserv> 是通用性的 composition 處理。而上述半透明效果實作遇到的問題，可以透過
20:45 <@jserv> 很明顯的解法處理，就是將 composition 轉交給 X server 處理，這基本上就
20:45 <@jserv> 是 Xrender extension 所作的項目，Xrender 提供另一個資料型態：Picture，
20:45 <@jserv> 類似 Pixmap 的整數型態 handle，但是具備 Alpha channel。
20:45 <@jserv> ---------------------------------------------------------
20:46 <@jserv> glyph：字或字體，是指字的實體圖像
20:46 <@jserv> character --> 字的抽象描述
20:47 <@jserv> ---------------------------------------------------------
20:47 <@jserv> Xrender 在 X server 端繪製 text，所以真正取得這些處理過的 pixel 需要
20:47 <@jserv> 透過 socket 傳輸這些特化的資料。
20:47 <@jserv> shape functions (使用 bitmask) 處理 X server 端的 bitmap，如果我們讓
20:47 <@jserv> Xrender 在一個 bitmap 上作顯示，這樣的話，所需的過程就簡化為：
20:48 <@jserv> Screen --> Image (slow)
20:48 <@jserv>            Image --> Pixmap (slow) --------+
20:48 <@jserv>                                            | Xrender
20:48 <@jserv>                     (medium) Pixmap <------+
20:48 <@jserv>                           \
20:48 <@jserv>                            \ |
20:48 <@jserv>                             \|
20:48 <@jserv>                            shape function (fast)
20:48 -!- yurenju [~yurenju@wshlab2.ee.kuas.edu.tw] has joined #debian.tw
20:48 <@jserv> ---------------------------------------------------------
20:49 <@jserv> 於是乎，我們將 two-way roundtrip 降到可接受的 one-way roundtrip
20:49 <@jserv> [實作議題]
20:49 <@jserv>                                                                                 
20:49 <@jserv> 我們可以針對 1-bit transparency 使用 Shape extension，移去所有沒有涵蓋於
20:49 <@jserv> 我們要顯示的文字以外的 Window，然後，複製桌面背景到剩餘的 Window，最後透
20:49 <@jserv> 過 Xft 來描繪字形，這有無法避免的 round-trip，需要將這些 Window 「碎片」
20:49 <@jserv> 傳遞給 X client，除非有個直接使用 Pixmap 的 XGetImage() 與 XCopyArea() 函
20:50 <@jserv> 示。這樣一來，理論上已經可以在 X client 端完成所有的 composition。
20:50 <@jserv>                                                                                 
20:50 <@jserv> [1] http://www.ignavus.net/software.html
20:50 <@jserv> ---------------------------------------------------------
20:50 <@jserv> Questions?
20:51 <@jserv> 在大家思考的同時，小弟來介紹一些有趣的新專案
20:51 <@jserv> http://jserv.sayya.org/wm/gotwm.png
20:51 <@frid> A_A
20:52 <@jserv> 這是小弟最近為 GOT (Gentoo Taiwan) 撰寫的一個 Window Manager
20:52  * _benny_ 躲在 jserv 背後得意
20:52 < yurenju> 背景是 Gentoo Taiwan 耶… ^^
20:52 <@jserv> 左上角就是所謂的 OSD (On-Screen Display)
20:52 < kanru> XD
20:52 <@jserv> GotWM 在 OSD 的實作上，並沒有用到 Xrender extension
20:53 <@jserv> 相反的，還是只用 xosd library
20:53 <@jserv> 因為其變化性太小
20:53 <@jserv> 只是跟底圖作 differing
20:53 < _benny_> 原來 xosd 是 lib，我一直以為只要下個參數就可以顯示了
20:54 <@jserv> 然而，如果是在 video player 上設計 OSD ，就會面臨 rendering 的效能衝擊
20:54 <@jserv> 這是需要留意的
20:55 <@jserv> ---------------------------------------------------------
20:55  * jserv 發現今天很冷 :(
20:56 <@frid> 我覺得昨天比較冷@_@
20:56 < descent> 我覺得明天會很冷
20:56 <@jserv> 同時，剛剛的 screenshots 的右下角
20:56 < SBT> 我回來了，Log 看完了 :p
20:57 <@jserv> 那是小弟最近開發的一個 Web Browser
20:57 <@jserv> 稱為 kBrowser
20:57 <@frid> 用qt寫的?
20:57 <@jserv> frid: 用 GTK+/DirectFB 來實作
20:57 <@jserv> . based on khtml
20:57 <@jserv>     http://developer.kde.org/documentation/library/kdeqt/kde3arch/khtml/
20:57 <@jserv> . Merged from Apple's WebCore
20:57 <@jserv>                                                                                 
20:58 <@jserv> . Toolkit： GTKlite (精簡版本的 GTK+ 2.4)
20:58 <@jserv>     - GTKlite 運作於 KDrive
20:58 <@jserv>     - KDrive 的 KAA 將會大幅改寫
20:58 <@jserv>         * 重新 profiling
20:58 <@jserv>     - Reference Implementation is scheduled in 2005 Q2.
20:58 <@jserv> GTKlite 也需要設計相容於 GTK+/DirectFB，而 Web Browser 本身設計
20:58 <@jserv> 不直接接觸到 low level drawing，在 source level 上要更換這兩個
20:58 <@jserv> 架構的衝擊可以大幅降低。
20:58 <@jserv>                                                                                 
20:58 <@jserv> Flash plugin 在 DirectFB 架構下需要 Rootless X server 作 overlay
20:58 <@jserv>                                                                                 
20:58 <@jserv>   +------------------------------+
20:58 <@jserv>   | MIME                         |\
20:58 <@jserv>   |application/x-shockwave-flash | \
20:58 <@jserv>   +------------------------------+  \
20:58 <@jserv>                                      \
20:58 <@jserv>                                 Create X session -------+
20:58 <@jserv>                                                         |
20:58 <@jserv>                                 X sandbox env ----------+
20:58 <@jserv> ---------------------------------------------------------
20:58 -!- enrico [~enrico@218-164-132-100.dynamic.hinet.net] has joined #debian.tw
20:59 <@jserv> 再者，筆者昨天整理 XOrg repostory
20:59 <@jserv> 將 Cygwin/X 透過 MinGW 移植成功，當然，這是因為有許多現成的 patch
21:00 <@jserv> 現在，這個 X server 可以 natively 的在 Win32 上面跑
21:00 <@jserv> 不需要依賴 Cygwin 的 UNIX Compatibility Layer
21:00 <@jserv> 請參考：
21:00 <@jserv>     http://jserv.sayya.org/freedesktop/xmingw-20041230.zip
21:00 <@jserv>                                                                                 
21:00 <@jserv> 字型檔也一併提供，所以只要解開後啟動 run.bat 即可。(DISPLAY=:0)
21:01 <@jserv>                                                                                 
21:01 <@jserv> ps: 這是小弟自己維護的 branch，有任何問題請不要直接回報給 XOrg
21:01 <@jserv> ---------------------------------------------------------
21:01 <@jserv>     mailing-list，Feel free to contact me.
21:02 <@jserv> 還有，筆者最近也開始維護另一個有趣的計畫
21:02 <@frid> cool
21:02 <@jserv> 稱為 Xorz :-)
21:02 <@jserv> > Xorz 是一個模組化處理的 Xorg 分支，並且整合 XDirectFB 與尚未被
21:02 <@jserv> > Xorg 採納的實驗性 patch，有很多有趣的新特徵 :-)
21:02 <@jserv> > 感謝 zonble 的 "Orz" 歌，讓我聯想 Xorz 當作 Project Name。
21:02 <@jserv>                                                                                 
21:02 <@jserv> Xorz 是 "Xorg Zazen" 的縮寫，可以視為淬練中的 Xorg branch，而為何要
21:02 <@jserv> 發展 Xorz 呢？簡單來說，有以下動機：
21:02 <@jserv>                                                                                 
21:02 <@jserv> 1. Xorg 單一 development tree 造就非常巨大難懂的 tarball 與 building
21:02 <@jserv>    process，造成許多 packaging 的困擾，version control 的工具處理如此
21:02 <@jserv>    巨大的 repository 也吃不消。(可以試著用 svk 來 mirror XOrg 看看要多
21:02 <@jserv>    久，svn diff 的時間也很令人厭倦)
21:03 <@jserv> 2. Xorg 在某些角度來說，因為必須顧及許多平台差異，所以相當保守，儘管
21:03 <@jserv>    FreeDesktop.org 上有許多卓越的 patch，至今還無法完全整合
21:03 <@jserv> 3. XOrg 並未徹底與 Linux 作最佳的整合與調整
21:03 <@jserv> 4. XOrg 在 Embedded System 應用上有許多限制
21:03 <@jserv> 從今年九月份開始，我試著 hack Xserver 與 Xlibs 實作，陸續有些心得，並
21:03 <@jserv> 且認為 XOrg 在 Embedded Linux 上必須有更好的基礎建設，於是我試著維護
21:03 <@jserv> 自己的 branch，當時是參考 keithp 的 KDrive。
21:03 <@jserv>                                                                                 
21:03 <@jserv> 後來發現 KDrive 架構並未能解決多數的狀況，比方說 XvMC 的處理就需要大幅
21:03 <@jserv> 加強，所以後來試著整合 XOrg 的設計，但是周旋於 XAA 與 KAA，著實耗費很多
21:03 <@jserv> 心力，也吃力不討好。
21:03 <@jserv>                                                                                 
21:03 <@jserv> 所以比較務實的作法是參考 Daniel Stone 的 Debrix，並且加強 Embedded Linux
21:03 <@jserv> 上 DRI 的設計，同時 UNIX 一項「美德」 -- 將所有的設定檔以純文字形式存取，
21:03 <@jserv> 卻屢屢在 Embedded Linux 或 Desktop 整合的應用來說，顯得累贅且繁複，而在
21:03 <@jserv> 拜讀 [Why Linux Needs to be Elektrified] 一文後，得到許多啟示。
21:03 <@jserv> ---------------------------------------------------------
21:03 <@jserv> http://elektra.sourceforge.net/
21:03 <@jserv> 初期的目標是：
21:03 <@jserv> 1. 整合 XDirectFB
21:03 <@jserv> 2. Elektra 化 XOrg
21:03 <@jserv> 3. 模組化
21:03 <@jserv> 4. 強化 DRI 支援
21:03 <@jserv> ---------------------------------------------------------
21:04 <@jserv> 最後這些成果都會回到 Xorg 總部的，但是筆者希望有更多的台灣朋友參與 FreeDesktop 的開發
21:04 <@jserv> :-)
21:04 <@jserv> ok. 廣告時間結束
21:05 -!- PowerOp [~PowerOp@219-84-58-7-adsl-tpe.dynamic.so-net.net.tw] has joined #debian.tw
21:05 <@jserv> 接著簡單介紹 Composite Extension
21:06 <@jserv> 相信很多朋友都看過 Sun Project Looking Glass 的成果
21:06 <@jserv> 一定對裡頭的設計有相當的好奇
21:06 <@jserv> 而 MacOS X 種種華麗的效果也不在話下
21:07 <@jserv> 而，X Window System 的設計下，有無可能達到類似的效果呢？
21:07 <@jserv> X 中的 Window Manager 是個很好的發揮題材
21:07 <@jserv> 也有所謂的 3D Workspace 套件現身
21:08 <@jserv> 但是這並未能根本的、透明化的，以及高度的通透整合起來
21:08 <@jserv> 所以，keithp 開始思考這個議題
21:08 <@jserv> Composite Extension 必須搭配另外兩個 extensions
21:09 <@jserv> Xfixes / XDamage / Composite Extension
21:09 <@jserv> Xfixes 的命名非常有意思
21:09 <@jserv> "fixes" 什麼呢？
21:09 -!- yuwei [yuwei@218-164-142-128.dynamic.hinet.net] has joined #debian.tw
21:10 <@jserv> 因為我們必須對現有的 Window 作重構的動作
21:10 <@jserv> 比方說陰影、透明化
21:10 <@jserv> 甚至扭轉的特校
21:11 <@jserv> 在 keithp 的想法中，XDamage extension 就是用以作碎片的切割
21:11 <@jserv> Programmer 可以依據特定的邏輯將該 Display / Screen 作處理
21:12 <@jserv> Xfixes 接著將這些「碎片」再給予調整，比方說作外框、Alpha blending
21:12 <@jserv> 等處理
21:12 <@jserv> 最後，Composite extension 作個最後的呈現
21:13 <@jserv> 需要注意的是，Composite extension 在 XFree86 4.3 以前就存在了，但是 Xorg X11R6.8 則是整合這三個 extensions
21:13 <@jserv> 同時，我們也可以發現當今 3D Desktop/Workspace 的趨勢已經不再是發展炫麗的特校
21:14 <@jserv> 已經有太多基礎建設很完備了
21:14 <@jserv> 問題在於「如何快速、無痛的移轉現有的操作環境？」
21:14 <@jserv> --------------------------------------------------------
21:14 <@jserv> Questions?
21:15 <@frid> 請問有Sun Project Looking Glass的url 嗎?..Orz
21:15 < SBT> 可以問 Xming 的問題嗎?
21:15 <@jserv> frid: 這裡有展示：http://jserv.sayya.org/freedesktop/lg3d-demo.mov
21:16 <@jserv> SBT: 請說 :-)
21:16 <@frid> jserv : bow
21:16 <@jserv> frid: Goolge:// Sun Project Looking Glass <-- 第一個link
21:16 <@jserv> s/Goolge/Google/
21:16 < SBT> 剛剛抓來跑了起來，想用 win32 下的 imagemagick display 作測試
21:16 -!- d2207197 [~joseph@220-135-237-215.HINET-IP.hinet.net] has joined #debian.tw
21:16 <@jserv> SBT: 嗯，遇到什麼問題呢？
21:17 < SBT> 出現 ColorIsNotKnownToServer (black) 的錯誤訊息 ...
21:18 <@jserv> SBT: 嗯，因為還沒徹底 porting 好
21:18 <@jserv> SBT: known issue
21:18 <@jserv> SBT: 但是基本的 Window 應該可以出來吧？
21:18 < SBT> imagemagick 出現這個 exception 之後就死了 :p
21:18 < SBT> 我換別支程式試試看 ...
21:19 <@jserv> 在繼續下個主題之前，我們來看看其他展示
21:19 <@jserv> http://jserv.sayya.org/embedded/eem.avi
21:19 <@jserv> 這是 Enlightenment for Embedded 的畫面
21:19 < SBT> 靠，好帥 XD
21:20 <@jserv> 實際上，也可以運作在 e17-on-DirectFB 上
21:20 <@jserv> 喔，提到這麼多次 DirectFB，這裡有之前作的簡報可參考
21:20 <@jserv> 標題：DirectFB 在 Embedded Linux 上的應用
21:20 <@jserv> 作者：Jim Huang (黃敬群) <jserv@kaffe.org>
21:20 <@jserv> 最後更新日期：Nov 22, 2004
21:20 <@jserv> 下載：
21:20 <@jserv>     http://jserv.sayya.org/embedded/directfb-intro.ppt
21:21 <@jserv>                                 (Microsoft PowerPoint 格式)
21:21 <@jserv>     http://jserv.sayya.org/embedded/directfb-intro.html
21:21 <@jserv>                                 (Shockware Flash 格式，800x600)
21:21 <@jserv> -----------------------------------------------------
21:21 <@jserv> Project Looking Glass 作為一個重要的 3D Desktop 基礎建設
21:21 <@jserv> 其必須考量的議題非常的多
21:22 <@jserv> 姑且撇開 Java3D 的整合不論
21:22 <@jserv> 很快的，開發小組就面臨許多新的挑戰，於是他們提出 XEvIE 的 extension
21:22 <@jserv> XEvie 對以下的應用是相當關鍵性的：
21:22 <@jserv>                                                                                 
21:22 <@jserv>   . 3D window systems (such as Project Looking Glass and Croquet).
21:23 <@jserv>   . handwriting recognition
21:23 <@jserv>   . multi-level event redirection.
21:23 <@jserv> 3D --> 2D 的轉換，在 rendering 方面，有發展完備的硬體 projecting
21:23 <@jserv> 但是整體的操作是否能配合呢？
21:23 <@jserv> 這是很大的問題
21:24 <@jserv> 在剛剛列出的動畫中，我們可以看到 Sun 的那位 Project Manager 神色自如的操作著夢幻的桌面
21:24 <@jserv> 儘管真實映象的環境是 2D TFT
21:25 <@jserv> 這是怎麼做到的呢？
21:25 <@jserv> 答案就是透過 XEvIE
21:25 -!- XS4-3065 [d2f40e52@webchat.xs4all.nl] has joined #debian.tw
21:25 -!- XS4-3065 [d2f40e52@webchat.xs4all.nl] has quit [Kill line active: Open Proxy found. Visit the website openrbl.org/lookup?i=210.2]
21:26 <@jserv> XEvIE 原本是附著於 Xext library 下，但是後來成為新的 extension，在 Xorg X11R6.8.1 現身
21:26 <@jserv> 這個想法就是能夠一般性的「擷取」、「攔截」 user events
21:26 <@jserv> 然後可以動態的加入自己的轉換 policy
21:27 <@jserv> 比方說 Sun Project Looking Glass 就設計了很多 Universe
21:27 -!- asho [~asho@220-135-210-115.HINET-IP.hinet.net] has quit ["Client exiting"]
21:28 <@jserv> 這些 Universe (宇宙系) 表示 3D 操作，可以讓使用者翻轉、取物、位移
21:28 <@jserv> 然後最終又對應到真實的座標上
21:28 -!- treeboy [~treeboy@140.127.113.60] has quit ["leaving"]
21:28 <@jserv> 整個設計是通透性的，所以不需要修改任何一個 X Client
21:29 -!- yurenju [~yurenju@wshlab2.ee.kuas.edu.tw] has quit ["Lost terminal"]
21:29 <@jserv> 這是很重要的革命
21:29 <@jserv> -----------------------------------------------
21:29 <@jserv> Questions?
21:30 <@jserv> [工商服務時間]
21:30 <@jserv> 因為小弟最近又回到 tty 與 framebuffer 的生活中，所以像樣的中文終端機是很重要的
21:31 <@jserv> JMCCE 的網頁在 AndrewLee 與 ycheng 兩位的協助下，終於回來了
21:31 <@jserv> 但是 JMCCE 也整整兩年沒有維護了
21:31 <@jserv> 相當可惜
21:31 <@jserv> 所以，小弟趁此機會想找些朋友繼續維護，有意者請討論，謝謝！
21:32 <@jserv> --------------------------------------------
21:32 -!- yurenju [~yurenju@wshlab2.ee.kuas.edu.tw] has joined #debian.tw
21:32 < descent> gpm 的支援
21:32 <@jserv> 嗯，時間也到尾聲了，開放發問與討論，謝謝！
21:33 -!- tedyu [~tedyu@79-208.dorm.ncu.edu.tw] has quit ["leaving"]
21:34 <@frid> 神奇!
21:34 <@jserv> 如果沒有問題，那今年度的 IRC Conference 就順利落幕了，感謝各位！
21:34 <@frid> clap!
21:34 < Ma1> 之前提到DRI現在已經和kernel層有相關的實作
21:34 < Ma1> --> 是不是現有必須將dri的module編入kernel中才能發揮dri的功能?
21:35 < Ma1> (拍拍手 ^^)
21:35 <@jserv> 驚！ gcin 也提供 GTK+ 2 的 IM Module 了！
21:35 <@jserv> Ma1: 是的
21:36 < SBT> 再問 Xming!
21:37 -!- jserv changed the topic of #debian.tw to: 2004 年度 IRC Conference 圓滿落幕，感謝各位參與
21:37 <@jserv> SBT: 請說
21:37 < SBT> 現在似乎沒辦法接受別台機器的 client 用 TCP/IP 連入?
21:38 <@jserv> SBT: 因為加了 -ac 的參數
21:38 <@lloyd_> kevinwatt: ping...
21:38 <@jserv> SBT: 請修改 run.bat
21:38 <@kevinwatt> lloyd_: pong
21:38 -!- jengwei [~jengwei@61-230-90-151.dynamic.hinet.net] has quit ["using sirc version 2.211+KSIRC/1.3.11"]
21:38 <@lloyd_> kevinwatt: 該做 log. :-)
21:38 <@jserv> SBT: 把 -ac 拿掉就可以了，但是 xhost.exe 我還沒準備好
21:38 <@kevinwatt> lloyd_: @.@;
21:38 < SBT> 了解! thx :)
21:38 <@frid> 初步log http://frid.gentoo-tw.org/ircconference.txt
21:38 <@lloyd_> jserv: 大感謝..
21:39 <@jserv> SBT: 在 Xorg X11R6.8.2 應該就可以上線了 #Native Win32 Xorg!!!
21:39 <@jserv> lloyd_: 客氣了 #這次沒什麼準備，工作太忙了 :(
21:40 <@jserv> kanru: 所以 Xorg X11R6.8.2 就可以驅動你的 nVidia 顯示卡了 :p
21:40 -!- how [~how@59-104-242-123.adsl.dynamic.seed.net.tw] has quit ["離開"]
21:40 <@jserv> kanru: 光靠 nv driver 就行了
21:40 -!- yuwei is now known as yuwei_awa
21:41 -!- yungyuc [~yyc@220-134-24-5.HINET-IP.hinet.net] has quit [""]
21:42 < kanru> jserv: ya.. 效能超棒 :D
21:42  * jserv 檢討：Xft/Fontconfig 沒有講、Xrender 說不清楚、DRI/DRM 需要更多解釋、XEvIE 需要圖表、Composite extension 太快帶過
21:42  * jserv 考慮 IRC Conference 2005 :p
21:43 <@kevinwatt> jserv: 上吧~
21:43 < d2207197> jserv: Go Go Go
21:43 <@jserv> kevinwatt: hmmm... 不過打字實在好累 :(
21:43  * kevinwatt 叭~~
21:44 < descent> GentooUserParty2004-1再補充也可以
21:44 <@jserv> ccc