なぜウェイランド/ウェストンではないのですか？
まず明確な説明：Waylandは、クライアントアプリケーションがコンポジターコンポーネントと通信する方法を定義するプロトコル定義です。サーフェスの作成/破棄、グラフィックスバッファの割り当て/管理、入力イベントの処理、シェルコンポーネントの統合のための大まかなプロトタイプなどの領域に触れます。ただし、プロトコルの定義を評価した結果、Waylandプロトコルは要件を満たしていないことがわかりました。まず、3D入力デバイス（Leap Motionなど）のような将来の開発を考慮した、より拡張可能な入力イベント処理を目指しています。ただし、Waylandの入力イベント処理は、Xの入力イベント処理セマンティクスによって導入されたセキュリティ問題の影響を受けません（これを指摘してくれたDaniel StoneとKristianHøgsbergに感謝します）。モバイルのユースケースに関しては、インプットメソッドの処理もディスプレイサーバープロトコルに反映されるべきだと考えています。別の例として、プロトコルのシェル統合部分を特権があると見なし、クライアント側のプロトコルで定義されたシェルの動作を避けたいと思います。
ただし、クライアントとディスプレイサーバーコンポーネント間の通信を標準化しようとするWaylandの試みは非常に賢明で有用であると考えていますが、要件が異なるため、次のアーキテクチャw.r.tに進むことにしました。プロトコル統合へ：
非常に明確に定義され、十分にテストされ、移植可能なプロトコルに依存しない内部コア。ディスプレイサーバーを任意のグラフィックスタックに移植し、それを複数のプロトコルにバインドできるようにするフロントエンドファイアウォールを備えた外部シェル。
要約すると、私たちは要件を完全に満たしていないため、次世代のユーザーエクスペリエンスを提供するための基盤としてWayland/Westonを選択していません。さらに、プロトコルおよびプラットフォームに依存しないアプローチにより、プラットフォームおよびデバイスのフォームファクター全体で一貫した美しいユーザーエクスペリエンスという目標を確実に達成できます。ただし、ディスプレイサーバーにWayland固有のフロントエンド実装を提供するか、最終的にMirと通信するlibwaylandのクライアント側実装を提供することにより、Waylandサポートを追加できます。
より詳細な議論がここにあります： https://wiki.ubuntu.com/Mir/Spec?action=show&redirect=MirSpec
そして、Mirテクニカルアーキテクトから：
http://samohtv.wordpress.com/2013/03/04/mir-an-outpost-envisioned-as-a-new-home/
詳しくは：
QとAのJono Baconはこれに数回答えました。彼の最新の回答はこちらです：
http://www.youtube.com/watch?v=6Oa2psAewtg&feature=share&t=56m36s
JonoのQ＆AやLinux Unpluggedに対するPopeyのコメントから集めたものから、ポイントは次のように要約できます。
- ウェイランドはやりすぎです。ソフトウェアスタックに永続的に未使用の機能があると、ソフトウェアの設計が不十分になります。
- Waylandのチームは、十分に敬意を持って適切に対応するためにWaylandの全バージョンを提供するほど柔軟ではありません。
- MirはWaylandに、LightDMはGDM/KDMに。
- Ubuntuには非常に厳しい期限があり、電話メーカーなどと会う必要があります。プロジェクトを制御することで、追加のリソースを簡単に注入して、これらの期限を確実に満たすことができます。
- この理由は正式に正規のものから来たものではないと思いますが、それは単なる推測であり、決定が下された時点で、ウェイランドは市場に十分に早く動いているようには見えなかったし、既存のAndroidテクノロジーは、製品を発売するのにより適した基盤のように思えました。