Waylandとは
追記(2013/09/18)：
２年以上前に書いたこの記事を引用してヒトを情弱よばわり
している馬鹿がいるようです。この記事を書いた当時、
↓は正しい内容だったのですが、Waylandプロジェクト内で
その後に様々な変更(コードを含む)が行われ、現在では現状と
そぐわなくなっています。人を情弱よばわりしている馬鹿の
ほうが実は情弱でそいつにとっては昔に書かれた記事は現状に
あわせて常にアップデートされていないといけないようです。
昔書いた記事をアップデートしていない方はそいつに情弱
呼ばわりされるリスクがあります、ご注意ください。正しい内容と書いた経緯？について付け加えます。
当時、Waylandサーバの実装はまだ公開されていないか、
公開されていてもα版初期くらいの状態で評価できる状態
にはなかったのです、ディスプレイ・サーバ？実装者にも
まだ評価のしようのない？時期です。日本語でも英語でも？
詳しい情報がネット上には未だありませんでした。
そこで自分への覚え書き程度にWayland開発者から開示
されていた情報をまとめたのが↓の文章です。Wayland開発者
から開示されている情報をまとめただけで他のことは
載せていません、また、自分の解釈の微妙な？誤りもあるかも
しれません。その当時はWaylandサーバ自体が検証を行おう
と思うほどの品質にも達していなかったので、海外のサイトを
漁って無理やり動かしてレポートするほどの興味を見いだせ
ませんでした。また、同様の理由で海外のサイトを漁って↓の
内容の反証記事を探すこともしていません。1.0のマイルストーンを通過済みの現状でも試す気には
まだなれません、単純に環境を整え評価する時間が
惜しいからです。単純に試すために環境を整える手間
> Waylandサーバへの興味 だからです。
まだまだ実稼働環境に載せられる品質及びパフォーマンス
に達していないようので、しばらくは評価は専門家？に任せて
動向を追っておく程度に留めるつもりです。
今なら、Wayland(Intel) VS Mir(Canonical)の対立？が面白い
ですかね、CanonicalがWaylandのコードをペチってMirを
作っていて実装の難しい部分はIntelがやった後でCanonicalが
コピるけどMirのライセンスがアレなのでIntel側はCanonicalが
やった改善を取り入れることができない、業を煮やしたIntelは
自社の抱えるグラフィックスドライバー開発者に
XMirへの対応パッチを取り込まないように命じた？、のが
最新情報？
http://cpplover.blogspot.jp/search/label/GNU%2FLinux
これくらいの情報は情弱の言う情弱にも拾えるんですよ。
ゴシップ？ですが。
ディスプレイサーバとクライアントの通信の手順とサーバ・クライアントの
インターフェース(API)を定めた規約(プロトコル)の名称(コードネーム？)。
その規約に基づいたディスプレイサーバとクライアント用ライブラリの
リファレンス実装もWaylandのパッケージに含まれている。
そのため、Wayland＝ディスプレイサーバと誤解されることが多い。
リファレンス実装はLinuxカーネル固有の仕組み(KMS、evdev)を
利用しているため、Linux専用。
Waylandにおいては画面の合成を行うコンポジタが主役、コンポジタ
自体がカーネルとのアクセスを担当し、カーネルを介してハードウェアの
入出力を処理する。
Waylandディスプレイサーバ≒コンポジタ＋カーネルアクセス
Xサーバとの違い
XサーバがWindow Manager・Xクライアントとで三位一体、
ウィンドウの管理をクライアントから切り離しWindow Manager
が行うのに対し、Waylandはウィンドウの管理は全てクライアント
自体が行う。また、XサーバはXプロトコルによりネットワーク
透過性を有するが、Waylandはネットワーク透過性を有さない、
そのかわり、ネットワーク透過性に伴うオーバーヘッドがない
ぶんXサーバに較べて画面描画が高速となる。
WaylandとXサーバの関係
WaylandサーバはXサーバ互換ではない。既存のXクライアントを
Waylandサーバ上で動作させるためにはWaylandクライアントAPI
を用いて実装されたXサーバが必要となる。
Waylandのリファレンス実装
現状、リファレンス実装はサーバとしての動作以外にXクライアント
としての作動もサポートされている、これは実装が安定するまでの
一時措置と思われる。
また、Khronos Groupの定めたモバイル向けウィンドウシステム
仕様OpenWFのうちディスプレイとのアクセスAPIを定めた「OpenWF
Display」をサポートしている。
Waylandに向けてのGUIツールキットの対応
Linuxデスクトップ環境におけるディスプレイサーバのX11からWaylandへの移行を睨み、主要GUIツールキットは対応を進めてきている。
Qtはバックエンド依存コードを本体から切り離しプラグイン化
することによりバックエンドを抽象化し切替可能にする
研究プロジェクトLighthouseの成果を本流にマージし、Qt4.8と
してのリリースに向け開発中。
Nokia Qtラボ主体のWayland用プラグイン、コミュニティベース?の
Android用プラグインがQtバックエンドプラグインとして開発中。
GTK+は3.0からGDKの実装をX11ラッピングからCairo(2Dグラフィックスライブラリ)依存に変更することでバックエンドの動的切替を可能にしている。
UbuntuでCanonicalがUnityを選んだ理由
Unityへの移行はWaylandへの布石。
KDE、Gnome等の統合デスクトップ環境となると
バックエンドの移行は並大抵のことではない。
(KDE、GnomeはXサーバー上で動作することを前提に
設計されていて、Xサーバー前提の箇所も多い。)
Waylandは現状Linuxのみをターゲットとしているため、
Waylandのパッケージに含まれるCompositorは
Linuxカーネルのもつ仕組み(KMS等)に依存している。
つまり、当分の間WaylandはLinux限定。
Waylandに対してLinuxを含むUnix全般をターゲットに
している統合デスクトップ環境(KDE、Gnome等)の開発者が
最優先で対応するとは考えにくい。Wayland対応より他の改良
や新機能追加が優先される可能性が高い。
早期にWaylandに移行したいUbuntu開発元Canonical社は
外部の統合デスクトップ環境開発プロジェクトの中で
コンセンサスを取りながらWayland対応を進める道では
なく、自社製OSSプロダクトであるUnityで一気呵成に
Wayland対応を進める道を選んだ。
UnityはLinuxのみをターゲットにしており、そのソースコード
は統合デスクトップ環境と較べて遥かにコンパクト。
革新を推し進めたい場合には他者とコンセンサスを取りながら
の共同作業よりビジョンを共有した少人数での集中作業が
最適であることが多いので、Canonicalのこの決定は
正しい。
Wayland自体の開発がまだAlphaステージにあることを
付記しておく。Wayland対応はまだこれから。
