Linux向けの新Xサーバー開発プロジェクト「Wayland」 66
ストーリー by GetSet
insiderman 曰く、
Red HatのKristian Hogsberg 氏が、「Wayland」と呼ばれる新たな軽量Xサーバーを開発するプロジェクトを立ち上げている（Phoronixの記事）。
Waylandは既存のXサーバーの単なる焼き直しではなく、最新のグラフィックス技術に対応しつつもコンパクトなXサーバーを目指しているとのこと。現在は開発初期の段階だが、Cで書かれたソースコードは3200行ちょっとと、実際に軽量なものとなっている模様。
XFree86やX.orgといったXサーバーは非常に重いイメージがありますが、それでもLinuxでのXサーバーのデファクトスタンダードになっているのは、ほかに良い代替物がないためかと思われます。ソースコードは現在freedesktop.orgのgitリポジトリから入手可能とのことなので、興味のある方は是非人柱になってみてはいかがでしょうか。
どうせなら (スコア:3, すばらしい洞察)
# Xプロトコルが腐れてないと思うのなら、Xの接続方向とか認証とかについて調べてみ？
※元記事は読んでない。
Re:どうせなら (スコア:4, 興味深い)
それなんてSunView [wikipedia.org]? (XLibではないけど)
歴史的には、 SunViewのようにライブラリで直接描画するのは効率が悪い [u-tokyo.ac.jp]、 ということで登場したのが、 Xその他のサーバ・クライアント方式のウィンドウ・システムですね。 Xのサーバ・クライアント方式には、 「ネットワーク・トランスペアレント」という以外にも、理由がありました。
もっとも、現代では共有ライブラリと共有メモリ、 マルチスレッディング等々が普及したこともあり、 当時湯浅先生がおっしゃっていた「最大の欠点」については、 今なら、うまく解決する方法もあるかもしれません。
しかし思い出しましょう。 アプリケーションプログラム間でグラフィックス資源の調停が面倒だった、 SunView(や、その他のライブラリ直接描画方式のシステム)の教訓を。 グラフィックスハードウェアの複雑化した現代では、 その調停は更に困難になってきているかも。 そこをライブラリに作り込んで、 アプリケーションに密結合させる手もなくはないですが、 結局それはXプロトコルと同等以上の複雑さを潜在的に備えることになるでしょう。 さらにセキュリティのことまで考えると、 問題はサーバ・クライアント方式以上に難しくなるでしょう。
なんだかんだで、ハードウェアと各アプリケーション間の調停を行なう、 描画サブシステムのレイヤーを持つのが現実的で、 そうなると、もはやそこをWindowsのように密で複雑なAPIで繋ぐか、 Xプロトコルのような明確に(だが多少行き当たりばったりに)定義された通信で結ぶかの違いはあれど、 結局はある意味でサーバ・クライアント方式と言える形に落ち着くのだと思います。
資源調停以外にも、 クライアントからの要求を再スケジューリングして、 描画ハードウェア資源の利用を最適化するなどというような、 サーバ・クライアント方式でなくては難しい最適化もあり得るので、 一概に「ライブラリ直接描画方式にしちゃえばいい」というのは短絡的に思えます。
なお、別に既存の方式だけがウィンドウシステムのあり方とは思っていないので、 過去をふまえた上で、新しい方式を考案するのは大いにやって欲しいと思います。
最近はあまり面白いウィンドウシステムが出てこないのでつまらないですね。 個人的には、1980年代ごろの、 各社がそれぞれにウィンドウシステムを開発していたころが、 ウィンドウシステムに関しては一番わくわくしていた気がします。 上でも引用したGMWとかNeWSとか出てきたころが、 ウィンドウシステム(の様々な方式)が面白かった最後でしょうか。 逆にPERQ辺りまで遡ると、さすがにリアルタイムでは体験していないですが。
Re:どうせなら (スコア:1, すばらしい洞察)
Re:どうせなら (スコア:1)
Waylandがどのような方針なのか分からないけど、
Xlibのインターフェース自体があまり好きにもなれないし、
効率的とも思えないので、gtkとqtが最低限動けばいいという
視点で作った方が良いと思う。
Re:どうせなら (スコア:2, 興味深い)
その作者は Emacs を Windows で動かしたいというのがそもそもの発端だったのだが、結局 BOW と呼べるほどほとんどのAPIを実装する羽目になった。
最低限動かすと言いつつも、必要となる実装範囲は予想以上に広いかも・・・。
Re:どうせなら (スコア:1)
↓のような問題を思いつきました。
● だれがイベントを発行するのか。
たとえば他プロセスのウィンドウが重なっているときの
マウスイベントとか EXPOSE とか。
あと、フォーカスとか。
結局サーバー的な何かが必要になる気がする。
● ウィンドウマネージャの扱いはどうするのか。
既存のXプロトコルと互換性がないと、
ウィンドウマネージャ相当品まで作成するハメになる。
● XLib を使っていない既存のアプリケーションとの協調はどうするのか。
現存するのかどうか知らないけど。
Re: (スコア:0)
X server でない別の何かをまた作らなくちゃいけなんじゃないの？
Re:どうせなら (スコア:1, フレームのもと)
>>直接描画してくれるXLib
おげ？
あと、これはユーザプロセスの話だから「グラボのドライバを叩く」は「直接」に含まれるからね。
Re: (スコア:0)
最近では「リモートホストのプレゼンテーションをローカルホストに表示する手段」としてはWebが使用されることが多いようです。
Webベースならファイアウォールやプロキシの存在など、現代的なネットワークの諸問題に対応できるメリットはありますが、 これでXプロトコルを完全に置き換えるのは仕様/性能的にまだ無理がありそうです。
(リモートホストのCPU負荷を目視確認するのなら、Webブラウザを上げるよりは、xloadで済ませたい)
ローカルホストへの描画しかしないXlibは、やはり局地戦用兵器だなぁ。
Re:どうせなら (スコア:1)
それ以前に Xlib と呼んでいいでしょうか?
Re:どうせなら (スコア:1)
Re: (スコア:0)
恥知らずなACがあまり調子こくとリアルで痛い目を見て病院で栄養食を食べる事になる
Re: (スコア:0)
本家でも突っ込まれてたけど、
元記事の内容を読む限り、これって、クライアントサイドで動かすものだよね。
それって、Xサーバって呼べるのかな？Xサーバの定義が人によって違うのかもしれないけれど。
Re: (スコア:0)
- Xサーバ：（ユーザから見た）クライアントサイドで動く、描画
- Xクライアント：（ユーザから見た）サーバサイドで動く、計算
だったような気がする。で、彼はXサーバじゃなくクライアントの方に今サーバが受け持ってる描画機能を追加してやるのがいいんじゃないか、って言ってるんだと思った
Re: (スコア:0)
> を追加してやるのがいいんじゃないか、って言ってるんだと思った
Windowsのリモートデスクトップような実装でしょうか？
感覚的なものでしかありませんが、あれは軽くてサクサク動いて好きです。
ああいうのであれば、*NIX系にも是非欲しいですね。
Re: (スコア:0)
その機能をきちんと引き出すドライバが無いと辛いところですが
やっぱりドライバのインタフェースも互換性無いですよね…？
フリー版ドライバだと悲しいぐらい性能が出ないですからね
WaylandはX(プロトコル)サーバじゃない (スコア:3, 興味深い)
Waylandでは2Dも直接描画にしているようです。
Xサーバの再実装というよりDRIマネージャとでもいうべき別物じゃないかと思います。
サーバ側で描画しないので必然的に描画コマンドを送るXプロトコルも捨てじゃないでしょうか
詳細は日記 [srad.jp]
ついに (スコア:2, おもしろおかしい)
組み込み用に使えるかな (スコア:1)
コンパクトなリソースでＸが動くならそっちを使いたい場合もあるわけで。
Re:組み込み用に使えるかな (スコア:5, 参考になる)
最低限のX11でよければそういうもの [jussieu.fr]は既に存在するようです。Gumstix [gumstix.com]とかで使われています [gumstix.net]。
# 余談ながら、X11の置き換えが難しいのは蓄積された膨大なドライバを作り直
# すのが困難だから、という一点に尽きると思います。
# 確かにX11のソースはモジュール化されドライバはサーバやライブラリ等から
# 分離されましたが、えてしてXのソースは歴史的理由からインターフェースが
# ごちゃごちゃなので、X11のドライバだけを流用して新しいウィンドウシステ
# ムを作るというのは難しいのではないでしょうか。
# 新しいXが古い古い言われながらなかなか代替の出てこなかったこれまでのX
# から学ぶことがあるとすれば、デバイスを抽象化するだけのレイヤーとXサー
#バを明確に分離し、GUIに対する時代の要求が変わってもドライバという資産
# を無駄にしなくても済むようにすることかもしれません。
Re:組み込み用に使えるかな (スコア:4, すばらしい洞察)
> # すのが困難だから、という一点に尽きると思います。
そういう点だと、「Windows 用のドライバを使えるXサーバ」なんてのが出てきてもいいんじゃないかな。
無線LANにおける NdisWrapper みたいに。
そうすれば対応ハードの多さがダントツだし、
「チップが新しすぎて対応していない」なんて心配もなくなる。
Re:組み込み用に使えるかな (スコア:2, 参考になる)
デバイスレイヤに相当するようですよ。
すでにFedora9でも、インテルチップのみですが、生コンソールとX環境がこの機構の上で
動かせるようです。
linuxカーネル本体へも2.6.29あたりで取り込まれる予定だそうなので、ドライバさえ揃ってくれば
広く使われて行くのではないでしょうか。
本当に小さい (スコア:1)
によると、こんなに小さいみたいです。
サンプルクライアント込みです。
上記のところでファイルをクリックすると
ソースも見れます。
Makefile................1268
NOTES...................6763
README..................1989
background.c............3837
compositor.c............4360
connection.c............4322
connection.h............767
egl-compositor.c........5957
event-loop.c............3029
flower.c................5294
gears.c.................5688
gears.h.................148
hash.c..................776
input.c.................3125
pointer.c...............4252
wayland-client.c........4803
wayland-client.h........1028
wayland.c...............16608
wayland.h...............3747
window.c................8829
起動の流れはこんな感じ。
./wayland &
./background &
./flower &
./flower &
./flower &
./window &
./pointer &
選択肢は (スコア:0)
車輪のry
Re:選択肢は (スコア:3, すばらしい洞察)
Re:選択肢は (スコア:1, 興味深い)
これらは全く意味合いが違います。そこで重要になるのは自らの腕を過信しているか適正に評価しているか。自らの腕を過信している人が自分のプロジェクトにいるのは困るけど、外でやってくれる分には、成果を待つだけだ。
こんだけ短くこれだけのことが実装できて動いているんだから、xorgよりかなりいいものにはなりそう、オープンソースプロジェクトで大勢がたかって作ったやつは一人の手で再実装されることで劇的に改善する可能性がある。それはいずれ再び汚されるだろうけど、どちらのプロセスも無駄なことではない。
Re: (スコア:0)
Re:選択肢は (スコア:1, すばらしい洞察)
何度も繰り返される要望として、Windowsのようにカーネルに機能を取り込めってのがありますけどね。まともに応える開発者はいないでしょうし。
Re: (スコア:0)
すいません (スコア:0)
生まれるのはエイリアンか合成人間か…
サーバ、クライアントは？ (スコア:0)
もう10年以上使っていない機能だなぁ。
昔は、他人のterminalを自分のマシーンに出して色々遊んだっけ。
Re:サーバ、クライアントは？ (スコア:1, 興味深い)
おかげ様で最近のローカルXサーバの処理の速さを見る度にびっくりします。
＃クライアントサーバシステムを排除するならxorgでいいや
Re:サーバ、クライアントは？ (スコア:1, 興味深い)
そこまでしてlinuxを使いたい用途なんてCUIな作業がほとんどだから、Xの出番は多くありませんけどね。
#俺：X server 起動！！
#Ｘ：今日も terminal たくさん開く仕事がはじまるお
Re: (スコア:0)
何かとお世話になってます。
# >昔は、他人のterminalを自分のマシーンに出して色々遊んだっけ。
# 他人のマシンで走らせている自分のプロセスを自分の端末に表示していた、というわけでなく？
# 昔、学校でNeXT使っていたとき別のマシンでMathematicaのプロセスを走らせてました。
# だって重いんですもの
Re:サーバ、クライアントは？ (スコア:1)
Display PostScript の恐怖だ
--- show mpls ldp neighbor
Re: (スコア:0)
完全にオフトピですが、Oracleはコマンドラインだけでインストール作業から
何から全てできるようにしてくれないかなあ。
中途半端にGUIが必要なので返って面倒。
＃あと、これを理由に「GUIが無いと」って言い出す人がいるので、、、、
Re:サーバ、クライアントは？ (スコア:1)
Oracle XE だと Universal Installer を使わないみたいです。Ubuntu だと、deb パッケージをダウンロードしてインストールするだけでした。
でも、ODT.NET なんかのインストールで Universal Installer が使われるのでしょんぼり。(笑)
私の場合、開発が主ですので、XE でだいたい足りますが、運用に載せるサーバーだとそうもいかないでしょうね。GUI なしインストールの方法があるなら知りたいですねぇ。
Re: (スコア:0)
Re: (スコア:0)
# 流石にSSH -X に半二重のハブでは辛い...
それよりも重要なのは… (スコア:0)
おもに赤帽さんとかですが
それでいてメモリ不足になってスワップインしまくってるサーバをいつも任される身になってほしい
(ノ ゜Д゜)ノ ==== ┻━━┻
Re: (スコア:0)
サーバ任されているなら、GDM止めちゃえばいいじゃないですか。
# ホントにそれが原因？
Re: (スコア:0)
パフォーマンスパフォーマンスとかなり言われて
厳しいのかなと実際Serverを覗いてみると
GDMやらXFS(FontServerのほう)やらCUPS系が上がってるような管理をしている会社は実際多いっすよ
しかもXまで上がっていて、実際運用されているプロダクトのServer上でXのSessionが残ってたりするw
現実的にはそれほど影響は無いけど、Web系のServer用途でRedhatで言うところのrunlevel 5でInstallし運用する会社は非常に多い
これほんと！
Re: (スコア:0)
私はテキストベースで問題無いのですが、もう一人の管理者がGUI環境しか使えない人だったので…orz
＃私自身は素のX11+twmでも全く問題無しｗ
Re: (スコア:0)
Xサーバーって本当に重い？ (スコア:0)
最近の上に載ってるものは確かに重いのだが.....
Re:Xサーバーって本当に重い？ (スコア:3, 興味深い)
100Mbps もあればネットワーク越しでも問題ないですし。
ところで、なんだか元記事に目も通してないようなとんちんかんなコメントが目立ちますが、もうXでプログラムしてる人は少ないのかな。私も XLib 直接叩いたのって10年以上前だけど。
このプロジェクトの面白いところは、最近のハードウェアを使った Composite システムを最大限に活用すれば、 オーソドックスなXプロトコルの多くの部分(ウインドウの重なり判定とか double buffer がらみとか)が不必要になるから、それらを思い切って切り捨ててしまって、Xプロトコルのサブセットを実装しよう、って話ですね。ついでに buffering をサーバ側で完全にコントロールできるから、うまくやれば描画途中の見苦しい状態がユーザに見えるのも避けられると。プログラミングも簡単になるだろうし、とてもいいアイデアと思いますよ。 進化の方向としては正しいんじゃないでしょうか？
# ただ現在の普通のXクライアントが動かない可能性が高いだけ。
# で、まずは screensaver 専用サーバから始めたい、と。
Re: (スコア:0)
ソースコードの行数が重量級、ということではないかと。
# imake使ってた時代の方が少ない気がする。ま、ドライバも機能も増えたけどさ。
Linuxの良いところみーつけた (スコア:0)
WindowsだとグラフィックAPIの仕様なんて互換性の問題が大きすぎて滅多に変えられない。
Linuxは何もかもが疎結合だから、もっといいものができる、と思えばすぐに違うものが作れる。
Re:Linuxの良いところみーつけた (スコア:1)
Xlib等のクライアントにリンクされるライブラリを変えた場合です。
Xサーバは、Xクライアントとの通信をXプロトコルにしたがって処理します。
Xプロトコルを変えない限り、
Xサーバを新規実装してもグラフィックAPIの互換性が損なわれたりしません。
Re: (スコア:0)