KDE PlasmaのX11サポート終了へ：今のうちに準備しておくべきこと

KDE PlasmaがX11をサポートする最後のリリースに向けて準備が進んでいます。今後、Waylandへの移行が本格化するため、ユーザーや開発者は環境の変化に備える必要があります。

KDEの開発陣はWaylandを推進して、みんなが欲しがっている機能や必要な機能を新しいプロトコルとして実装するのにすごくいい仕事をしてると思う。KDEはX11で動かすよりWaylandの方が圧倒的にスムーズでレスポンスもいいし、今の時点ではほとんどのものがWaylandでちゃんと動くようにアップデートされてるから、日常的に使ってて壊れてたり機能が足りないなんて感じることはないよ。

Waylandを通す単一のコードパスに一本化することで、Plasma全体に新しいパフォーマンス向上やメモリの最適化、ワクワクするような新機能をもたらせるようになるはずだ。

このブログ記事だけど、具体的な事例をいくつか挙げて紹介してくれてたらもっと良かったのにな。

悲しいのは、何年も経ってもWaylandがX11でできていたことや持っている機能をまだ欠いていることだね。セキュリティに過敏すぎるせいで、意図的に実装してない機能もある。例えば、Chromeの「ピクチャー・イン・ピクチャー」ウィンドウは、他の場所をクリックすると最前面に居続けられないんだ。Waylandがウィンドウを最前面に固定することを許可していないから。時間があれば、Waylandがいかに多くのアプリをぶち壊しているかリストアップしたいくらいだよ。

X11が壊れてなくて置き換えるべきじゃないと言いたいわけじゃないけど、Waylandの決定の多くはX11以上にユーザー体験を損なっているよ。

気持ちは分かるけど、Waylandベースのデスクトップを試すたびに、基本的な使い勝手で変なバグやコーナーケースにぶち当たって、結局X11に戻っちゃうんだよね。

6.8になっても同じ状況だったら、別のDEを探さないといけなくなるから悲しいな。

自分はもう12年Kubuntuを使ってるけど、X関連の問題は一度もないし、今でもXを必要とする作業をバリバリやってる。そろそろ別のDEに変える時期かもしれないな。

Waylandを通す単一のコードパスに一本化することで、Plasma全体に新しいパフォーマンス向上やメモリの最適化、ワクワクするような新機能をもたらせるようになるはずだ。

その「新機能」って具体的に何なのか、いくつかリストアップしてほしかったね。

昨日この記事を読んで、ぜひ知っておいてほしいと思ったからシェアするよ - https://nocoffei.com/?p=451

LinuxのアクセシビリティソフトウェアがX11からWaylandへ移行する際の回帰問題について書かれている。残念ながら、プロトコルの採用ペースから見ると、解決策が出るまでまだ何年もかかると思う。

一番目立つ問題はTalonが動かないことだね。これは音声入力システムで、音声を使ってテキスト入力したり、ウィンドウを操作したり、スクリプトを実行したりできるもの。Windows、MacOS、X11では動くけど、Waylandではダメなんだ。

残念だけど、今このソフトウェアが必要なら、できるだけX11に留まるのが一番の得策だと思う。i3みたいな環境なら、おそらく今後数十年間はメンテナンスされるだろうし。あるいは、特定のWaylandスタック上で独自ソリューションを作るのもありかもしれない。TalonでできることをKDEプラグインやSwayのIPC経由で再実装するとかね。実現可能そうには見えるけど、信じられないほど大変な作業になるはず。

これを必要とする人たちが、PCを使うためにわざわざ開発者になって自前でツールを作らなきゃいけないなんて……そんなLinuxの未来にはあんまりワクワクしないよ。アクセシビリティソフトが必要な人を置き去りにしたくないし、セキュリティ上の理由で彼らをサポートできないなんていうのは、本当の障壁だとは思えない。これは調整の問題なんだ。技術的な問題というより、Talonのようなソフトがエコシステム全体で動くようにプロトコルを合意させることの問題だよ。

エコシステムがWaylandに移行していること自体は嬉しいし、最終的には今より良い場所に行けると思ってる。Waylandのおかげで、自分にとって切実な問題（NvidiaでのX11の画面のティアリングやフレームペーシングの問題）が解決するしね。KDEが存在してくれていることには感謝してる、素晴らしいソフトウェアだよ。

プロダクトのクリティカルな機能をそれなりにリリースしてきた立場から言うと、この計画には少し不安を感じるね。「機能を無効化する」のと「そのコードベースを同時に削除する」のを一緒にやってうまくいくことなんてまずない。必ず誰にも予測できなかったようなユースケースが出てくるものだから。

シリアスなプロジェクト（つまり、自分のキャリアがかかっているような場合）では、もっと良い戦略があるはず。まずは通常の手段ではその機能を使えないようにしつつも、回避策を残しておく（今回のケースなら、例えばPLMでX11オプションをメニューから消しても、魔法の環境変数をセットすればX11セッションを使えるようにするとか）。そうすれば、万が一致命的な不具合が起きた時でも、みんな簡単に以前の機能に戻せる。そうやって重大な予期せぬ問題がないと確信できて初めて、コードベースを削除すべきだよ。

Plasma/Waylandで確認されている大きな問題[1]

・ネイティブWaylandウィンドウの位置を保存・復元できない
・「セッション復元」を偽装するアプリが、そのウィンドウがどの仮想デスクトップにあったかを記憶していない
・フルスクリーンのアスペクト比補正がない
・「スペアレイアウト」機能が未実装
・「アプリケーションごとのキーボードレイアウト」が機能しない
・適切なICCプロファイルを作成・入手しないと、ガンマ変更や手動での色調整ができない
・複数のタッチストリップモードを切り替えられない
・ヘッドレスRDPができない
・Konsoleでコマンドラインバイナリを使ってファイルを開いても、既存のウィンドウが最前面に来ない
・非Qtアプリでグローバルメニューがサポートされていない
・配置ポリシーを「最大化」に設定していると、一部のアプリの最大化できないウィンドウが壊れる

[1] https://community.kde.org/Plasma/Wayland_Known_Significant_Issues

最新のLTSカーネル（6.18）で古いNvidia GPUを使っている人は、Waylandではひどい目にあうことになるよ。自分はPascal GPUを積んだマシンが2台あるけど：

• NvidiaのバイナリドライバはWaylandだとクソ
• NvidiaのOSSドライバはPascal GPUをサポートしていない
• NouveauはLinux 6.19で安定性が向上したけど、それがないとWaylandが週に1回くらいのペースでクラッシュする

安定したシステムにしたければ、最新カーネル＋Nouveauを使うか、あるいは：

MESA_LOADER_DRIVER_OVERRIDE=kms_swrast

にするしかないけど、パフォーマンスはかなり絶望的だね。

KWinをタイル型ウィンドウマネージャに入れ替える機能が本当になくなったのは痛いな。今はKrohnkiteを使ってるからまあマシだけど、本物のタイル型ウィンドウマネージャを使った後だと、その違いが大きすぎて馴染めないよ。自分は物理的にマウスとキーボードの両方を可能な限り使いこなせるデスクトップが必要で、その間を切り替える回数を極限まで減らしたいんだ。X11でタイル型ウィンドウマネージャを使っていたPlasmaはまさに完璧なコンビだった。

解決策としては、PlasmaがRiver[1]みたいにコンポジットとウィンドウ管理を分離するか、他のコンポジタでもPlasmaのウィジェットを使えるようにするかのどちらかだと思う。今のままだと、Krohnkiteで我慢するか、RiverとQuickshellを使って泥沼のカスタマイズにハマるかの二択しかないね。

[1] https://isaacfreund.com/blog/river-window-management/