Wayland/Westonについて
最近、WaylandとかWestonとかよく見聞きします。(主にPhoronixとかで...)
で、何故か興味を持ってしまったので、近頃はWaylandがどんなものか見極めんと色々やっとったわけです。
Waylandがなぜ必要なのか、X11とWaylandの歴史を追いながら比較している素晴らしい発表がLinux.conf.au 2013にあったのでまず紹介したいと思います。
もしくは
上記を見てもらえればWaylandができた理由とその意義が大体お分かり頂けるのではないかと思います。
発表の中でもありましたが、Waylandの開発者はXの開発者でもあります。複雑怪奇になったXを改善するためテーマやフォントの描画の処理をどんどんクライアント側に移していきます。
Window Managementをするのが難しくなってきたのでX serverとは別にWindow Manager(WM)にすべて描画させます。
ではWMとクライアント側にどんどん処理を移動させた結果、X serverは現在何をしているのでしょうか。
実はほとんど何もしていなくて、WMとクライアントの間でデータを受け渡ししているだけになってしまったのです。
間にいるX serverいらんやん?となってしまいます。発表ではreally bad IPCと揶揄されています。
Waylandではクライアントが「これを表示してくれ」といったら、サーバ (Waylandコンポジタ)が表示する。これで完了です。
Waylandはプロトコルの名前で、ライブラリとしては非同期のオブジェクト指向型のライブラリlibwayland-clientとlibwayland-serverから成ります。
ライブラリとしてのWaylandはWaylandクライアントとWaylandコンポジタとの通信(IPC)が主な仕事です。
実際に画面に表示する内容はクライアント側で描画します。ですからクライアントはどのように描画しても構いません。
描画したあとは、その内容を表示するよう要請します。クライアント側に委ねられるのは描画だけでは無く、リサイズやキー入力等も非同期で飛んで来るので、全て自分で処理します。
Waylandコンポジタはそれぞれのクライアントが描画した内容を処理して、正しく画面に表示します。
WestonはWaylandコンポジタのリファレンス実装です。元来、KMSやOpenGL ESのような現代的な環境で動くことを目標にしていますが、コンポジタがどのように画面に表示するかはコンポジタ次第なので、例えばフレームバッファ(fbdev)や、X11、Remote Desktop Protocol (RDP)の上で動くバックエンドも用意されています。
最近はGTKやQt、EFL(Enlightenment Foundation Library)、SDL、Clutter等がWayland対応を完了、もしくは進めています。
純粋に、Xに依存したライブラリを利用していない、GTKやEFLクライアントは既にWestonの上で動作します。またGNOMEのmutterもWaylandで動作し、GNOME 3.10から実験的なWaylandサポートが実装され、先日リリースされたGNOME 3.12ではより改善されています。
最近のGNOMEのWayland対応についてはWayland in 3.12, and beyond - Clean Rinseあたりが詳しいかと。
次はWaylandプログラミングについて書くかもしれません。
