KDEとLightDMとMirの論争

KDE, LightDM and the Mir Kerfuffle | David Edmundson's Web Log

David EdmundsonがCanonicalのMir発表の影響について語っている。

KDEとLightDMとMirの論争

Canonicalの新しいディスプレイサーバーを作るという決定が、私が長年開発してきたLightDMとKDEフロントエンドにどのように影響するかという疑問が挙がっている。

難しい疑問だ。LightDMはCanonicalという大きなスポンサーを持っていた。ディスプレイサーバーはディスプレイマネージャーによってサポートされなければならない。

CanonicalとUbuntuは、Waylandを新しいディスプレイサーバーとしては受け入れず、独自開発のMirを使う決定をした。我々KDEはすでに、Waylandこそに将来性があるという決断をしており、kwinの開発も進められてきた。Waylandシステムコンポジターをサポートするディスプレイマネージャーの存在は、我々の長期戦略に欠かせないものである。

この問題について取り上げるように言われたので、ブログ記事として意見を吐こう。

背景事情

重要だが危険なクライアントのためにKDMを改造するという苦い経験から、KDMの改造の経験を元に、UIをやり直したいと思っていた。

私はUIと設定を書き直したいと思っていたので、KDMのコードに目をつけた。その頃、ちょうどRobert AncellがLightDMを発表した。新しいディスプレイマネージャーで、greeterという機能を提供している。これは2年ほど前、皆がWaylandに興奮していた頃の話で、当然Wayland対応もLightDMのロードマップに載っていた。

Greeterは、LightDMのUI実装である。つまりはログイン画面だ。LightDMは特定のツールキットに依存せず、GTK+でもQtでもGreeterを実装できるように設計されている。

これはWin Winシチュエーションのように思えた。新しいログインマネージャーを簡単に書くためのプラットフォームが手に入る上、KDEのWayland対応までもれなくついてくるのだ。

私はLightDMのためにQt Bindingや、QWidgetベースのgreeterのリファレンス実装も作った。その後、我々のレポジトリでKDE greeterの開発を始めた。

KDE greeterはversion 0.4になり、多くのディストロに取り入れられ、感想も好意的なものであった。

現在の状況

LightDMはCanonicalによって作られたものであるが、開発はコミュニティが主導し、すべてのパッチは誰でもコメントできるレビューを通過しなければならない。私はGreeter関連のパッチに口出しする立場にある。

LightDMは私のKDE greeter(いくつかのディストロで使われている)と、Xfceと、Razor Qtと、そしてもちろん、Unityで使われている。

Qtライブラリは、本来我々とRazor Qtが使っていたが、UnityもQMLに移行するようなので、つまり今後はCanonicalも私の作ったライブラリに依存することになる。私はまだQtライブラリを管理する立場にあり、すべてのレビューの最終的な判断には私も口出しする。私はCanonical社員の提出したいくつかのパッチを、書き換えが必要だとして却下したし、彼らも同様に私のパッチをいくつか却下した。まあ、実にオープンで実力主義のコミュニティであると言える。

文句

KDEでLightDMを使う利点は、ディスプレイマネージャーの作業でやたらと面倒な作業をしなくてもいいということであり、Waylandシステムコンポジター対応をしなくてもいいということである。自動的に対応されるからだ。我々はお互いに協力し合い、オープンソースは更に素早く発展する。

CanonicalがWaylandをサポートしないと事前に知っていたならば、私は果たして自分の時間をLightDMに割いただろうか。騙されたとは思わない、Canonicalだって、あの当時はやろうと思っていただろうし、なにか別のことをするのも、当然の権利だ。

Canonicalが方針転換をしたというのは問題ではない。問題は、そのことを私に言わなかったことだ（あるいは、開発者は公表を禁じられていたのだろう）。自分でやると公言していたことをやっぱりやらないと、6ヶ月前に分かっていて、それを人に言わないのは失礼にあたる。我々のスケジュールも後退したわけで、とてもいらだたしい。

今後どうなる？

LightDMの状況は、悪くなったわけではない。ただし、Wayland対応は我々が自力でやらなければならないということだ。「俺らで別のソフトウエアにもWayland対応をやらなければならないとしたら、それはやる価値があるのか」という疑問の声も挙がっている。この疑問に答えるよう要請されたので、私の意見をブログに書いてみる。そして、この問題を議論するために今週は会合がある。

我々の必要事項は、

• 早急にQt5で動くディスプレイマネージャーが必要である。
• 中期的に、Waylandをシステムコンポジターとしてサポートするディスプレイマネージャーが必要である

我々の選択肢は、

• KDMにパッチをあててXとWaylandをサポート（難易度高。このコードはXDMの上に構築されている）し、Qt5対応の修正も行う（またもや簡単ではない）
• 何か全く新しいものをスクラッチから書く。この場合、Waylandシステムコンポジターも書かなければならない。
• LightDMにパッチをあててWaylandをサポート（すでにMirとXを切り替えられるように作ってあるので、バックエンドの切り替えの仕組みがあり、Waylandパッチも半ば出来上がっている）。Qt5対応はすでに終えている。

ディスプレイマネージャーを書くのは、一見簡単そうで、実はとても難しい。詳細がやたらと多く、正しく動作するものを作るのがとても難しい。大量の環境変数をセットして、Xauthorityファイルを用意して、.dmrcファイルを管理して、あらゆるセッションフック、もちろんリモートセッションやセキュリティも。

というわけで、この問題に対する私の見方は明らかだろう。以前考えていたより作業が増えるのだ。

というわけで、今週末に関係者が集まって、将来の方向性について話しあう予定だ。

KDEは、CanonicalがLightDMをWayland対応にしてくれるだろうとあてこんでいたのが外れてしまったので、対応をどうしようか検討中らしい。Canonicalが方向転換するのは勝手だが、なんで決定した時点で、もっと早く知らせてくれなかったのかと不満だそうだ。まあ、当然だろう。つい先日まで、CanonicalはWaylandに移行すると公言していたのに、実際はWayland対応はやらず、ひそかにMirを開発していたのだから。