XDG shellがデフォルトで有効に
「Mir」の「XDG Shell V6」のサポートが改善され、デフォルトで「XDG Shell」が有効になりました。
「XDG Shell」は、「Wayland」でサーフェス管理の手法を拡張するプロトコルです。
Ubuntu 18.04と従来のMir
「Ubuntu 18.04」でグラフィックスタックがアップデートされ、「Mesa」でサポートされていた「Mir」の「EGL」サポートが無くなりました。これは「Mir」の開発者が想定していたよりも早く起きた出来事です。
これにより従来の「Mir」クライアントプロトコルを利用しているソフトウェアは、「Ubuntu 18.04」及びそれ以降のバージョンでハードウェアアクセラレーションが効かなくなります。
詳細は、以下を参照してください。
ただしこれは「Wayland」とは無関係であり、「Wayland」には影響ありません。
XWaylandのサポート方針
以前「XWayland」のサポート方針に関するアイデアを紹介しました。これらの理解を深めるため、以下でアーキテクチャーが紹介されています。
「XWayland」をうまく動作させるために、「Mir」にX11ウィンドウマネージャーを統合する何かしらの手法が必要です。
「mir-kiosk」での利用を意図していないため「XWayland」は必須ではありませんが、その場合デスクトップ向けのシェルは「Wayland」のみのサポートになるでしょう。
X11のエンドポイント
さて高レベルのインターフェースでは、「Mir」はX11のエンドポイントを提供する機能が必要になります。また「Mir」はX11のエンドポイントを監視し、クライアントがX11のエンドポイントに接続した時に「XWayland」をfork/execする必要があります。
「Mir」でX11のエンドポイントを提供する方法として、以下のようなオプションでの提供が考えられています。
$ miral-shell --x11-desktop :0
「XWayland」のfork時、「Mir」はXウィンドウマネージャー（Xwm）に接続されたソケットを提供しなければなりません。
このXウィンドウマネージャーは、「Mir」に統合されたX11ウィンドウマネージャーです。
アーキテクチャー
「XWayland」起動時、X11アプリをサポートする「Mir」のアーキテクチャーは、以下のようになります。
2種類のチャンネル
このアーキテクチャーでは、「XWayland」プロセスと通信を行う2種類のチャンネルがあります。「Wayland」チャンネルは、サーフェスと関連するバッファーをやり取りするチャンネルです。
「X11」チャンネルは、ウィンドウ管理の要求を処理するチャンネルです。
MirはすでにWaylandチャンネルを扱える
「Mir」はすでに「Wayland」チャンネルを扱うことができ、サーフェスを表示する機能を持っています。しかし効果的にウィンドウ管理を行うのに必要な情報が欠けています。
X11アプリは、ウィンドウマネージャーにどのように処理して欲しいのかを伝える情報を付加することができます。
当時「Mir」で「Xmir」を実装する時、開発チームは「Xmir」に同種の概念を導入しており、この情報が提供されているならば、サーバーで同じことを実現できます。
これは「Mir」のウィンドウ管理に対し、完全に透過的な仕組みです。
libmirserverと画面の情報
しかしX11アプリは、ウィンドウ管理をオプトアウトするために「override-redirect」フラグを設定でき、自身のサーフェスを配置することができます。この時アプリは画面の情報が必要になりますが、「Wayland」や従来の「Mir」ではこの情報をクライアントに提供していません。
従ってはXウィンドウマネージャー（Xwm）は、「Mir（Scene）」からそれらの情報を取得し、それらの情報へのアクセスを提供する必要があります。
と同時に、X11経由でそれらの機能を提供できなければなりません。
この機能を「libmirserver」に統合するとなると、以下のようなアーキテクチャーになります。
ウィンドウ管理をオプトアウトするX11サーフェスは、「Mir（Scene）」に存在していますが、「Mir」のウィンドウ管理からほとんど存在が見えなくなります。
