第652回　キミはMirを憶えているか

Ubuntuは来年4月にリリースされる21.04から、ついにディスプレイサーバーの初期設定をWaylandに変更することがアナウンスされました。そこで今回は「Waylandのライバルであるもうひとつのディスプレイサーバー」だったMirの最新情報をお届けしましょう。

Mirとは何だったのか？

「Mir（みーる）」はCanonicalが開発している「次世代のディスプレイサーバー」です。

ディスプレイサーバーとは簡単に言うと「ルートウィンドウ」と呼ばれるディスプレイ全体に広がるウィンドウを描画し、アプリケーションからの要求に応じて子ウィンドウの作成やウィンドウ内部の描画を担うソフトウェアです。加えて、Linuxカーネルから届いたマウスやキーボードのイベントを適切なウィンドウへ送る処理も担当します。つまりデスクトップLinuxにおいて、ユーザーからの入力とユーザーへの出力を司るとても重要なソフトウェアなのです。

「次世代」ということは「現行世代」と呼ばれる実装もあるわけで、それがUbuntuを含むほぼすべてのメジャーなLinuxディストリビューションやUnixシステムで採用されているX Window System（以下Xと表記）です。「⁠クライアントサーバーモデル」を採用し拡張性の高いプロトコル仕様を持つXは1980年代半ばから30年以上に渡って広く採用されてきました[1]⁠。その結果、たとえばリファレンス実装でもあるX.Org Serverなどは、さまざまな機能拡張を経て、現在では巨大で複雑なソフトウェアとなっています。

Xが登場した時代に比べるとコンピューターを取り巻く状況は大きく様変わりしています。クライアントマシンのスペックはすさまじい速度で進化し、3Dグラフィックの活用も当たり前になりました。動画の再生を始めとして、クライアント側で描画すべきコンテンツやエフェクトは複雑になっています。ディスプレイも大画面化・高解像度化が進むとともに、小さな画面に高い解像度のようなスマートフォンのようなデバイスも登場し、バラエティに富んだ環境を考慮する必要が出てきました。専門家のツールだったコンピューターは一般大衆向けのインフラとなり、これまで以上にセキュリティに注意しなくてはなりません。

そのような状況で2008年に登場したのが次世代ディスプレイサーバーである「Wayland」です。Waylandは、X.Orgの開発者でもあったKristian Høgsbergが最小のディスプレイサーバーとウィンドウコンポジッターを組み合わせたものとして個人的に作成していたソフトウェアが元になっています。その後、X.Orgの開発者たちがXを置き換える次世代のディスプレイサーバーとして開発に参加するようになりました。

厳密なことを言うと、Waylandはいわゆる「ディスプレイサーバー」とイコールではありません。Waylandはディスプレイサーバーの実装に必要なプロトコル仕様を定義し、そのプロトコル仕様を満たすライブラリーを提供しています。ディスプレイサーバーおよびウィンドウマネージャーの開発者はこのライブラリーをリンクした「Waylandコンポジッター」を開発することで、Waylandプロトコルを満たすディスプレイサーバー相当の機能を提供できるのです。結果的にMutterなどの既存のウィンドウマネージャーは、ディスプレイサーバーと統合された単一プロセスのWaylandコンポジッターとなります。またWaylandプロジェクト自身も、Waylandコンポジッターの参照実装としてWestonを開発しています。

Ubuntuでも10年以上前の2010年11月に「将来的なWaylandへの移行」がアナウンスされました。これは当時採用していたデスクトップシェルであるUnityと、Unityに必要なツールキット（NuxやGTK⁠）⁠、ウィンドウマネージャー（Compiz）をWaylandに対応させるということです。しかしながら具体的な進捗はほぼないまま数年が経過します。そして2013年3月になって突如Waylandへの移行をキャンセルした上で、独自に開発した次世代ディスプレイサーバーである「Mir」の公表し、将来的なMirへの移行がアナウンスされます。

このビッグニュースはUbuntuコミュニティの内外に大きな波紋を広げました。特に「Mirを採用する理由」がWayland開発者から見るとツッコミどころが多かったため、Wayland開発者とUbuntu開発者も交えた「Wayland vs. Mir」な論争に発展します。複数のプロジェクトで異なる次世代ディスプレイサーバーを開発することによる、「開発コミュニティの分断」にも懸念があがっていました。当時GNOME Shellの代わりに採用されていたUnityが、移行当時の品質の問題などを記憶しているユーザーからの評価が低かったことも、「⁠Ubuntuの独自実装」に対する反対意見を誘引していたようです。

Canonicalとしては、同時期に発表されたUbuntu Phoneやコンバージド構想（デスクトップからタブレット、スマートフォン、TVに至るまで「Unity」インターフェースで統一する構想）を今後のUbuntuの要として進めていました。そのような状況から、ある程度の反発は覚悟の上で自分たちでディスプレイサーバーを実装する必要があったのかもしれません。

しかしながらMirは2017年4月に大きな転換点を迎えます。CloudとIoTに注力するために、Mir開発の契機となったUbuntu Phoneとコンバージド構想に対するCanonicalとしての投資の終了が発表されたのです。Ubuntu Phoneについては一応実機が販売されたものの思ったほどは振るわず、開発自体も停滞気味でした。またデスクトップ側のUnity 8/Mirへの移行はさらに遅れている状況でしたし、他のデバイスも登場しなかったので終了そのものはある程度予想はされていたのです。この発表をもってデスクトップ側で採用されていたUnityも開発を終了し、GNOME Shellへと移行するとアナウンスされました。結果的にGNOME ShellがサポートするWaylandが、Ubuntuでも次世代のディスプレイサーバーとして採用されることになります。そしてそのWayland移行の目処がようやくたったのが、2021年時点での状況というわけです。

この終了アナウンスのポイントのひとつは「Mirそのものについては言及されていない」点です。その後の開発者などのコメントにより「MirはIoT向けに開発を継続する」と判明します。つまりMirはまだ生きているわけです。むしろ終了前よりも開発速度はあがっており、2018年9月にはとうとう1.0が、2020年7月には2.0がリリースされるに至りました。今回は最新の2.2.0を元に解説します[2]⁠。

最近までのMirの変遷

2017年4月のUnity終了のアナウンスから2020年11月の2.2のリリースまで、Mirはさまざまな変更が加えられています。そこで、当時から最近までの大きな変更点をいくつか紹介しましょう。

MirはWaylandコンポジッターになりました

まず最初にあげるべき大きな変更点は「MirがWaylandコンポジッターになった」ことです。「⁠えっ？」って思いました？思いましたよね？筆者は思いました。

MirのWaylandに対する最大の弱点はFLOSSコミュニティにあまり受け入れられていないことでした。つまりツールキットやコンポジッターがMirに対応しない以上、Mirの上で動くGUIアプリケーションが増えないのです。それに対する解決策として「MirがWaylandプロトコルをサポートすれば、Waylandプロトコルに対応したソフトウェアがMir上で動くじゃん！」となったわけです。「⁠Wayland vs. Mir」や「開発コミュニティの分断」とは一体なんだったのか。

前述したようにWaylandはプロトコルを定義するとともに、そのプロトコルに沿った実装となるライブラリを提供しています。コンポジッターやGUIアプリケーションはこのライブラリをリンクして適切にAPIを呼び出せば、Waylandをサポートできます。Xの頃は、まずディスプレイサーバーとしてXサーバーが存在し、アプリケーションはXクライアントとして動いていました。さらに「ディスプレイサーバー上で重なり合うXクライアントをどのように表示するか」をウィンドウマネージャーと呼ばれるソフトウェアが管理していました。GNOMEだとMutter、KDEだとKWinがウィンドウマネージャーとしての役割を担います。

Waylandではウィンドウマネージャーとディスプレイサーバーの役割がほぼ統合して「コンポジッター」になっています。GNOMEもKDEも、ウィンドウマネージャーがそのままlibwayland-serverをリンクして、Waylandコンポジッターになりました。GUIアプリケーション側は大抵の場合、アプリケーションが直接Waylandプロトコルに対応するのではなく、ツールキット（GTKやQt）がlibwayland-clientをリンクして対応しています。

現在のMirはコンポジッターとしてlibwayland-serverをリンクしています。つまりMirが動いている環境で、libwayland-clientとリンクしたGUIアプリケーション（Waylandクライアント）を動かせるようになったのです。それに合わせて、GUIアプリケーションやツールキットがネイティブにMirをサポートするためのクライアント向けAPIは徐々に廃止されていきます[3]⁠。

ちなみにMirがWaylandコンポジッターとして正しくWaylandプロトコルをサポートしているかを確認するために「Wayland Conformance Test Suite」という検証ツールも作成しました。Mirには依存しない作りになっているため、もし新規にWaylandコンポジッターを作る必要が出てきたときにも役に立つことでしょう。

MirはWaylandクライアントになりました

さらに2019年末の1.6.0のリリースから、「MirはWaylandクライアントとしても動く」ようになりました。要はMutterなどWaylandコンポジッターが動いている環境で、Mirのルートウィンドウをただのクライアントとして表示し、その中で別のGUIアプリケーションを動かせるようになったのです。

もともとWaylanにはXWaylandと呼ばれる機能が存在しました。GTKなど主要なGUIツールキットを利用しているアプリケーションは、そのツールキットがWaylandをサポートすることで、自動的にWaylandに対応できています。ただし純粋なXアプリケーションのように、ツールキットを使っていないアプリケーションはこの限りではありません。つまりそれらのアプリケーションは直接libwayland-clientをリンクするなどして、Waylandプロトコルをサポートする必要があるのです。

XからWaylandへの移行に伴って段階的に利用者が減っていくであろうXアプリケーションを修正するのはコストが高いため、「⁠WaylandクライアントとしてXサーバーを起動し、その中でXアプリケーションを動かす」という仕組みが考えられました。それがXWaylandです。

Mirの対応は、このXWaylandと同じようにMirそのものをWaylandクライアントとして動くようにしたものです。前項で説明したとおり、Mirアプリケーションは将来的にWaylandアプリケーションに統一される予定であったこと、そもそも純粋なMirアプリケーションはほとんど存在しないことから、XWaylandのような必要性はほとんどありません。ではなぜこのようなツールができたかというと、数少ない純粋なMirアプリケーションのひとつが、Ubuntu Touch関連のソフトウェアだったためです。

特にUbuntu Touchはセッション管理のために、Mirの上でMirを動かす「Mir-on-Mir」を利用していました。これはMirの古いクライアントAPIやMesaへのUbuntu独自パッチを利用しているため新しいMirでは動きません。そこで新しいMirでもMir-on-Mirを実現できるように、Waylandコンポジッターとしてだけでなく、Waylandクライアントとしても動くようにしたというわけです。

結果的にMirは単体のディスプレイサーバーとして動くだけでなく、任意のWaylandコンポジッターのクライアントとしても、X Window Systemで動くXクライアントとしても動作できるようになりました。これは組み込み機器向けのGUIアプリケーションを、ローカルPCで開発・テストする上で便利な機能となっていきます。

他のプラットフォームによるMirのサポート

Fedora 26からFedoraの公式パッケージリポジトリにMirが取り込まれました。FedoraユーザーならDNFを利用してMir関連のほぼ最新のパッケージのインストールが可能です。また最近はArchでも簡単にインストールできます。

実はこの作業は上記のWayland対応と密接に関わり合っています。Mirをサポートしようとすると、これまではMesa（のEGLの実装）にUbuntu独自パッチを適用する必要がありました。しかしながらMesaはともかく、Mir関連パッチは「大人の事情」でアップストリームへの取り込みが断られるケースがありました（Ubuntu Weekly Topics 2013年10月4日号⁠）⁠。このあたりがMirの採用にも影響していた可能性があります。

MirがWaylandプロトコルをサポートすることで、このMirパッチは不要になりました。つまりWaylandが動く環境であれば、Mirも原則として動作するということです。この変更を受けて、まず最初にリポジトリへのパッケージの追加を行ったのがFedoraの開発者です。今後は他のディストリビューションであってもMirをサポートすることが可能になったということでもあります。

その他の変更

最初のふたつほどインパクトは大きくありませんが、他にもいろいろな改善や機能追加が行われています。

MirALによるAPI/ABIの安定化
Mirベースのデスクトップ環境のサンプル実装である「EGMDE（Example Mir Desktop Environment⁠）⁠」の実装
MATEによるMirをコンポジッターとして利用したWayland対応
Mir用にWayland拡張機能の一部を移植
グラフィックスプラットフォームを利用した各種グラフィックデバイスのサポート

最後については、Raspberry Pi対応だと少しおもしろい状態になっています。Mirでは基本的にMesa経由でVC4を操作する方法をサポートしています。実はそれとは別にプロプライエタリなDispmanxのAPIを利用するモードも対応しているようです。これによりOMXの利用なども可能になる見込みです。このあたりの各種GPUの対応は、「⁠グラフィックスプラットフォーム」という名前でモジュール化されているため、比較的容易に他のグラフィックデバイスへのポーティングも行えるような設計になっています。

Mirを試してみる

ここからはMirを実際に試してみましょう。Mirはディスプレイサーバーですが、ディスプレイサーバーだけ動いてもあまり面白みはありません。IoT向けキオスクモードでMirサーバーを起動し、その中で組み込み向けとして移植されたWebKitベースのウェブブラウザーであるであるWPEを動かしてみましょう。

Ubuntuデスクトップならおおよそどの環境でもMirが動くはずです。今回はX Winodws Systemが動いているマシンを想定しています。他にはRasyberry Piでも同様でしょう。もちろんUbuntu Coreで動かす方法もあります。

UbuntuデスクトップへのMirのインストール方法は、公式リポジトリのパッケージを使う方法と、PPAのより新しいパッケージを使う方法、snapパッケージのデモ版を使う方法などが存在します。今回は環境を破壊せずに「とりあえずMirが動いた」という状況だけを考えて、snapパッケージ版を使います。

snap版のMirサーバーは「mir-kiosk」という名前でパッケージ化されています。これは単にMirサーバーを動かして特定のGUIアプリケーションが待ち受けるだけのパッケージです。実際にMir上に何かを表示するためには、mir-kioskに対応した他のsnapパッケージも必要です。具体的には「snap find mir-kiosk」で出てくるさまざまなパッケージが該当します。

まずはmir-kioskをインストールして起動しましょう。

$ sudo snap install --devmode mir-kiosk
$ sudo mir-kiosk

これで画面上に真っ暗な「Mir on X」なタイトルの画面が表示されるはずです。これだけでMirサーバーが起動しました。

次にmir-kiosk用のアプリケーションをインストールします。今回は「wpe-webkit-mir-kiosk」です。これは単なるWebKitベースのウェブブラウザーで、指定したURLを全画面で表示するだけのアプリケーションです。

$ sudo snap install --edge wpe-webkit-mir-kiosk
$ sudo snap connect wpe-webkit-mir-kiosk:wayland
$ sudo sudo snap restart wpe-webkit-mir-kiosk

waylandプラグに接続したら、自動的にmir-kioskのウィンドウが更新されて、WPEのウェブページが表示されます。

表示するページはwpe-webkit-mir-kioskパッケージの設定で変更可能です。

$ sudo snap set wpe-webkit-mir-kiosk url=https://en.wikipedia.org

残念ながらwpe-webkit-mir-kioskにはフォントが同梱されておらず、さらにホームディレクトリにも接続できる設定にはなっていません。このためWebフォントが設定されていない日本語ページは日本語が表示されません。wpe-webkit-mir-kioskはあくまでデモプログラムなので、必要に応じてフォークしてフォントを埋め込むなどの対応を行うと良いでしょう。

mir-kiosk向けのデモアプリは他にも存在します。一部は古いMirにしか対応していないこともありますが、ぜひ「snap find mir-kiosk」などで検索して試してみてください。