Linuxの窓はどこから来たのかリンクをコピーしました

古い映画やドラマで「コンピューターに詳しい人物」を登場させる方法は、だいたい決まっている。

部屋の照明を落とす。黒い画面に緑色の文字を流す。本人には早口で何やら独り言を言わせ、できればフードもかぶせる。これで天才ハッカーか、少なくとも捜査対象になりそうな人物が完成する。

Linuxは長い間、この演出と相性がよかった。サーバー、研究、開発の現場で広く使われる一方、家電量販店で目にするPCの大半はWindowsかMacだったからだ。Linuxを紹介する記事でも、端末へコマンドを打つ場面が前に出やすかった。

現実の端末作業は、映像作品ほど物騒ではない。設定ファイルの綴りを一文字間違え、ログを読み、直したつもりで別の箇所を壊す。忠実に撮れば、犯罪映画というより少々手際の悪い事務作業になる。

現在のLinuxデスクトップは、そんな古い印象からかなり離れている。ログイン画面があり、ブラウザーやファイルマネージャーを窓で開き、無線LANやBluetoothを設定し、通知を受け取る。高解像度ディスプレイの拡大率、タッチパッドのジェスチャー、明暗を広く表現するHDR、画面の更新頻度を動きに合わせる機能まで扱う環境もある。

窓、アイコン、メニュー、ポインターという操作の文法は、いまやOSをまたいで共有されている。ただし、その文法を画面へ実現する仕組みは同じではない。AppleはハードウェアとOSを一体で設計し、Microsoftは多様なPCへ共通の操作環境を広げた。UnixというOSの系統では、計算する機械と画面を置く機械をネットワーク越しに分けられるよう、X Window Systemが育った。

Linuxは、このUnix由来のX11を受け継いだ。やがてPCで動かすための実装、日常の道具を揃えたデスクトップ環境、画像処理を担うGPUによる画面合成が加わる。現在は、X11が担ってきた役割をWaylandという新しい通信規約へ移す途中にある。

今回の主役は、デスクトップの見た目そのものではない。アプリが描いた内容と、キーボードやマウスからの入力を、誰がどのように画面へつなぐのかというウィンドウシステムの歴史である。

LinuxがGUIを一から発明したわけでも、Waylandがある日突然X11を追い払ったわけでもない。その間には、互換性を守りながら役割分担を組み替えてきた四十年ほどの積み重ねがある。

画面は一枚に見えるが、その裏側まで一枚岩ではない。最初に、似ているようで役割の違う四つの言葉を整理しておく。名前を暗記する必要はなく、読み進めてわからなくなったときに戻ってくればよい。

たとえるなら、GUIは画面を使うという考え方、デスクトップ環境は机の上に揃った道具一式、ウィンドウシステムは道具と画面をつなぐ取り決めである。ウィンドウマネージャーやコンポジターは、その上で窓を並べ、最後に見える画面を組み立てる。実際には一つのプログラムが複数の役を兼ねることもあるため、境界は必要なところで少しずつ細かく見ていく。

現在のWaylandデスクトップで端末からディスプレイに関する設定項目を確認すると、環境によっては次のように二つの時代の名前が同時に現れる。

.console
コピー
$ echo "$XDG_SESSION_TYPE"
wayland
$ echo "$WAYLAND_DISPLAY"
wayland-0
$ echo "$DISPLAY"
:0

一行目は、デスクトップ全体がWaylandで動いていることを示す。それなのに三行目には、X11で接続先の画面を表すDISPLAYも残っている。これは設定の残骸でも、移行の失敗でもない。四十年ほどの仕組みを一度に捨てず、異なる時代のアプリを同じ画面へ載せるための結果である。

なぜ二つが同居できるのか。その答えへ向かうには、Linuxより古い時代まで戻る必要がある。まず、GUIが研究室の実験だった頃から、必要な助走だけ取ろう。

GUIが生まれるまでリンクをコピーしました

GUIの歴史はLinuxより三十年ほど古い。画面に絵を出せるようになっただけでなく、コンピューターへの命令の与え方そのものが変わったところから始まる。

GUIは操作を見えるものにしたリンクをコピーしました

GUIはGraphical User Interfaceの略である。かつて主流だった文字だけの画面に絵を足したもの、という理解は本質的ではない。変わったのは、情報の見せ方だけでなく操作の組み立て方だった。

コマンドラインでは、命令の名前と書式を知っている必要がある。

terminal.log
コピー
$ mv report.txt archive/

GUIなら、report.txtのアイコンを選び、archiveフォルダーへ動かす。対象と操作候補が画面に見えているため、利用者は命令を暗記しなくても試せる。

コマンドラインは正確な指定、反復、自動化に向く。GUIは対象を見つけ、その場で操作する作業に向く。現代のOSが両方を残しているのは、片方が未完成だからではなく、操作によって向いている道具が違うからだ。

画面上の対象を直接扱う発想は、1960年代にはすでに現れていた。

1963年、MITのIvan Sutherlandは博士論文としてSketchpadを発表した。利用者はライトペンで画面を指し、線を引き、図形を移動・複製できた。「この線は水平」「この二辺は同じ長さ」といった制約も設定できる。命令文を入力する代わりに、画面上の対象を直接操作する考え方が、ここにはっきり現れている。^GUIの前史

1968年12月9日には、Douglas Engelbartらが約90分の公開実演を行った。後にThe Mother of All Demosと呼ばれるこの実演には、マウス、複数の窓、ハイパーテキスト、共同編集、文書共有、ビデオ会議が登場する。現在では見慣れた機能ばかりだが、当時は大型コンピューターを専門家が使う時代だった。

Engelbartの特許に「マウス」という語は出てこない。名称は「表示システム用X-Y位置指示器」である。開発チームでは、コードが尻尾のように伸びた木製の試作機をいつしかマウスと呼ぶようになった。誰が言い始めたのかは、本人たちにも分からなかったという。^{マウスの名前}

The Mother of All Demos(1968) 入力デバイスの実演からポップアップウィンドウで表示中です埋め込みを読み込み中...

SketchpadとEngelbartの実演に共通するのは、コンピューターの能力そのものより、その能力へ人間がどう触れるかを問題にした点である。

研究所の画面に「机」が置かれたリンクをコピーしました

1973年、Xerox PARCで研究用コンピューターAltoが作られた。

Altoは、画面上の小さな点を一つずつ制御できるビットマップディスプレイとマウスを備えていた。さらにネットワーク、電子メール、複数書体の文書編集、画面表示と印刷結果を近づけるWYSIWYGを一台へまとめている。WYSIWYGは「見たものが、そのまま得られる（What you see is what you get）」という意味で、画面上の文書を印刷結果に近い姿で編集する考え方である。現在のPCに通じる要素が数多く揃っていたが、一般家庭へ売る商品ではなかった。^AltoとStar

Xeroxは1981年、これらの研究を取り入れたStarを商用化する。Starは単体の家庭用PCというより、文書、プリンター、ファイルサーバーをネットワークで結ぶオフィスシステムだった。画面には文書、フォルダー、ファイルキャビネット、受信箱と送信箱が並ぶ。コンピューター内部の構造をそのまま見せる代わりに、利用者が仕事で知っている机や書類へ置き換えた。

このデスクトップ・メタファーでは、文書をフォルダーへ入れる、不要なものをゴミ箱へ捨てる、といった操作の結果を予想しやすい。ただし、最初から誰にとっても自明だったわけではない。Starの資料はマウスそのものを説明する必要があった。いま「クリックしてください」で済むのは、何十年も同じ作法を教え続けた成果でもある。

画面上の物を何に見立て、操作後の結果をどこまで一貫させるか。Starは、描画技術だけでなく、この操作規則を製品としてまとめようとした。

AppleはGUIを一台の製品としてまとめたリンクをコピーしました

Xerox Starは、GUIが一つのアプリの機能ではなく、文書、ファイル、印刷、ネットワークをまたぐ操作体系になり得ることを示した。ただし、サーバーやプリンターも含めて導入する高価なオフィスシステムであり、個人が机へ置くコンピューターとは距離があった。

Appleでは1978年から、Apple IIの次を担う業務向けコンピューターとしてLisaの開発が始まっていた。翌1979年、Steve JobsらがXerox PARCを訪れ、Alto上で動く研究用ソフトウェアを見る。そこで示されたマウスとGUIは、すでに進んでいたLisa計画でGUIを採用する判断を強く後押しした。Appleは研究所の試作をそのまま写すのではなく、画面上の対象を一貫した規則で操作できる製品へ仕立てていった。

1983年のLisaは、文書中心のGUI、画面上端のメニューバー、ゴミ箱などを備えた先進的な製品だったが、9,995ドルという価格もあって広くは普及しなかった。^AppleとGUI

翌1984年のMacintoshは、Lisaより機能とハードウェアを絞り、価格を約4分の1へ下げた。マウスのボタンも一つだけである。これは単なる節約ではなく、初めて触る人に「どのボタンを押すか」を選ばせないための設計判断だった。MacPaintやMacWriteでは、選択、切り取り、コピー、貼り付けといった操作が揃えられた。利用者はアプリごとに別の作法を覚えるのではなく、同じ操作を別の仕事へ持ち込めるようになった。

1984年のMacintosh公開デモ MacPaintの実演シーンからポップアップウィンドウで表示中です埋め込みを読み込み中...

Appleはコンピューター本体、OS、入力機器、標準アプリを同じ会社で設計できた。操作を揃えやすい反面、そのGUIはAppleの機械と一体だった。1980年代のPC市場では、これとは別の条件を抱えた陣営が急速に大きくなっていた。

Microsoftは、増え続けるPCへ共通の画面を載せたリンクをコピーしました

1981年にIBM PCが登場した。IBMはMicrosoftからライセンスした、当時は文字による操作が中心だったDOSをPC DOSとして採用した。同系統のOSは、他社のPC向けにMS-DOSとして広がる。IBM PCの成功後は互換機を作るメーカーが相次ぎ、CPU、ビデオカード、ディスプレイの組み合わせも増えていった。Appleのように一社で機械全体を決めるのではなく、さまざまなPCで動く共通のソフトウェア環境が必要になった。^{IBM-PCとWindows}

もっとも、その役目をWindowsが担うと最初から決まっていたわけではない。複数の会社が、PCへグラフィカルな操作環境を載せようと競っていた。Windowsも、当初はその中の一候補だった。^{Windows初期}

Microsoftは1983年5月、IBM PCとMS-DOS機向けのMicrosoft Mouseを発売し、同年11月にWindowsを発表した。Windowsは新しいコンピューターそのものではなく、MS-DOSを拡張するグラフィカルな操作環境として構想された。既存のPCとソフトウェアを残したまま、その上へ窓、マウス操作、アプリ間のデータ交換を加える計画だった。

製品版のWindows 1.0が出荷されたのは1985年11月である。複数のアプリを同時に表示できたが、窓は原則として重ならず、画面をタイルのように分け合った。現在のWindowsへ一直線に完成したというより、MS-DOSの制約と多様なPCハードウェアの上でGUIを成立させる最初の試みだった。

流れを変えたのが1990年のWindows 3.0である。メモリ管理とグラフィックスが改良され、Microsoft以外の会社が作るアプリも増えた。1995年のWindows 95では、デスクトップ、タスクバー、スタートメニューが一つの操作環境としてまとまり、GUIがMS-DOSの上に載せる補助環境から、PCを使い始める入口へ変わった。^{Windowsの普及}

「スタート」というボタンは、現代のWindowsユーザーには馴染み深いものだろう。開発途中の画面には複数の入口があったが、利用者テストでは起動後に何を押せばよいか分からず、画面の前で止まる人がいた。入口を一つへまとめてStartと書いたところ、次の操作が見つけやすくなったという経緯がある。GUIの仕事は機能を並べることだけでなく、最初の一歩を画面上で示すことでもある。^{WindowsのStart}

MacintoshとWindowsは似た道具を画面に並べたが、成り立ちは異なる。AppleはハードウェアとOSを一体で作り、操作の一貫性を製品全体で保った。Microsoftは既存のDOS資産と多様なPCを引き受け、互換性を保ちながら共通のGUIを広げた。

大学や研究所では、個人用PCとは違う事情から、別のウィンドウシステムが育っていた。

MacintoshとWindowsのGUI史が「一台のコンピューターに使いやすい机を作る話」だったとすれば、UnixのXは「机と計算機を別々の場所へ置く話」だった。

X11がLinuxへ来るまでリンクをコピーしました

大学や研究所では、高価な計算機を複数人で使い、利用者の前にある端末とは別の機械でアプリを動かすことがある。当時は、個人の机で使う高性能なコンピューターをワークステーションと呼んだ。Unix向けのウィンドウシステムは、こうした機械と離れた計算機をつなぐ方向へ発展した。

Unixの窓は、ネットワーク越しに開いたリンクをコピーしました

1980年代前半、MITでは教育用コンピューティング計画Project Athenaが進められていた。大学内にはメーカーも性能も異なるワークステーションがあり、学生はどの端末からでも教材や計算資源を使いたい。

計算を行う機械と、画面やキーボードを置く機械が同じである必要はない。重い処理は研究室の計算機で行い、窓と入力だけを目の前の端末へ運べばよい。

1984年ごろ、Robert ScheiflerとJim Gettysらは、ネットワーク越しにも利用できるウィンドウシステムの開発を始めた。出発点の一つはStanfordで作られたWというシステムで、その次に作られたため、アルファベットを一つ進めてXと名付けられた。なお、正式には「X Windows」ではなく、X、X Window System、X11などと呼ぶ。^Xの名前

改良を重ねたXは、1987年9月15日にX Window System Version 11 Release 1、X11R1として公開された。OSの中核を担うLinuxカーネルの最初の公開は1991年なので、Linuxが登場した時点でX11はすでに実用と改良の歴史を持っていた。^X11R1

MacintoshやWindowsが、一台のPCを使いやすくする方向で発展したのに対し、Xは異なる機械とネットワークをまたいで画面を使うことを重視した。LinuxはGUIを一から作ったのではなく、Unixワークステーションで育ったX11をPCへ持ち込んだ。

画面と入力を提供する側を中心に考えた結果、X11では手元のPCが「サーバー」と呼ばれる。

手元のPCが「Xサーバー」になるリンクをコピーしました

X11で混乱を招きやすいのが、クライアントとサーバーの呼び方である。

Webでは、ブラウザーを開いている手元のPCがクライアント、Webサイトを提供する側がサーバーになる。X11では、ディスプレイ、キーボード、マウスという資源を提供する側がXサーバーであり、窓を表示してもらうアプリがXクライアントになる。

.mermaid
テキストで表示コピー
flowchart LR
  subgraph R["別の計算機"]
    A[アプリ<br>Xクライアント]
  end
  subgraph L["手元の環境"]
    direction TB
    X[Xサーバー<br>画面と入力を提供]
    U[利用者<br>ディスプレイ・キーボード・マウス]
  end
  A -->|描画を要求| X
  X -->|入力を返す| A
  X -->|表示| U
  U -->|操作| X

別の計算機で動くアプリから見ると、利用者の手元にあるXサーバーが窓を表示し、ユーザーの操作を返してくれる。サーバーとは、遠くにある大型機という意味ではなく、サービスを提供する側を指す。X11では手元の端末が画面と入力を提供するため、手元がサーバーになる。^{Xのクライアントサーバー}

ログインしてからログアウトするまで、一緒に動くデスクトップのまとまりをセッションという。X11を使うセッションでは、DISPLAY環境変数が接続先のXサーバーを示す。

.text
コピー
hostname:display.screen

たとえば:0なら、ホスト名を省略した手元のXサーバーを指す。末尾のscreenは一つのXサーバー内に複数の画面がある場合の番号だが、現在は省略されることが多い。

遠隔の計算機へ安全に接続するSSHで-Xや-Yを使うと、そこで動くX11アプリを手元の画面へ表示できる。接続先が手元でも遠隔でも、アプリから同じ規約で扱える性質をX11のネットワーク透過性という。ただし、現代のブラウザーや統合開発環境は大きな画像を頻繁に更新するため、遅延や帯域の影響を強く受ける。同じ方法で接続できることと、距離を感じずに使えることは別である。

LinuxのGUIは、一つのプログラムではないリンクをコピーしました

ここで、Linuxの画面を支える部品を大づかみに置いておこう。

アプリがボタン、メニュー、文字入力を毎回一から作るのは大変である。そこでGUIツールキットという部品集を使う。GTKやQtは、その代表例である。アプリとディスプレイの間には、まず次の順で部品が並ぶ。

アプリ
↓
GTK・Qtなど
↓
X11／Waylandの表示基盤
↓
Linuxカーネル・GPU
↓
ディスプレイ

これは簡単のために一直線へ並べた入口の見取り図である。実際には、入力を伝える経路と、アプリが描いた画像を渡す経路が並行し、X11とWaylandでも部品の境界が異なる。詳しい構造は、両者の役割分担を見た後で改めて重ね合わせる。

X11は、窓の見た目を決めなかったリンクをコピーしました

X11の中核は、窓を作り、描画を受け付け、入力イベントを渡す。タイトルバーの形、窓の重ね方、Alt+Tabの動作、パネルや時計の配置までは規定しない。

これらを担当するのがウィンドウマネージャーである。X11では、ウィンドウマネージャーもXサーバーへ接続するクライアントとして動く。^{ウィンドウマネージャー}

Xサーバーから見れば、xtermやEmacsとウィンドウマネージャーは、いずれも接続してくるXクライアントである。

.mermaid
テキストで表示コピー
flowchart TB
  subgraph C["どちらもXクライアント"]
    direction LR
    A[通常のアプリ<br>xterm・Emacsなど]
    W[ウィンドウマネージャー<br>配置と装飾を決める]
  end
  A -->|窓を作り、描く| X[Xサーバー]
  W -->|窓を配置し、飾る| X
  X --> D[ディスプレイ]

アプリだけでなく、窓を管理するプログラムも同じXサーバーへ接続する。この対等な部品構成が、ウィンドウマネージャーを自由に交換できる理由でもある。

ウィンドウマネージャーを終了すると、アプリの内容は残っていても、タイトルバーや移動・サイズ変更の手段が消えることがある。画面を表示する仕組みと、窓をどう扱うかが別々に動いているためだ。

この分離によって、同じX11アプリを使いながら、twm、fvwm、Window Maker、Enlightenment、後のi3やxmonadへ窓の管理方法を替えられた。自由度は高いが、窓を表示できるだけでは、初めて使う人向けのデスクトップにはならない。

コピーした内容は、なぜアプリと一緒に消えたのかリンクをコピーしました

X11の設計は、コピー＆ペーストにも表れている。Ctrl+Cでコピーした内容をXサーバーが直ちに保管するとは限らない。多くの場合、コピー元のアプリがselectionの所有者になり、貼り付け先から要求された時点でデータを渡す。

そのため、クリップボードマネージャーがいない古い環境では、コピー元のアプリを終了すると貼り付けられなくなることがあった。アプリが閉じれば、データの持ち主も消えるからである。X11クライアント同士が協調するための規約ICCCMは、この受け渡し方法を定めている。^{X11のselection}

.mermaid
テキストで表示コピー
sequenceDiagram
  participant C as コピー元
  participant X as Xサーバー
  participant P as 貼り付け先

  C->>X: selectionの所有者になる
  Note over X: この時点では<br>所有者だけを記録
  P->>X: 貼り付けを要求
  X->>C: 必要な形式を知らせる
  C->>X: その形式のデータを渡す
  X-->>P: データを届ける

Xサーバーが常にコピー内容を預かるのではなく、主に「どのアプリがselectionを所有しているか」を仲介する。実データが移動するのは、貼り付け先が要求した時点である。

X11には、通常のコピーで使うCLIPBOARDのほか、マウスで選択した文字を保持するPRIMARYがある。端末で文字を選び、中ボタンで貼り付けられるのは、この別系統のselectionによる。WindowsやmacOSからLinuxに来た利用者には、ショートカットにもトラップにも見える。

この仕組みには、コピー元と貼り付け先が別の計算機で動く可能性まで考えたX11の事情がある。双方が同じファイルを読めるとは限らないため、必要になった時点でデータそのものを変換して渡していたのだ。

XFree86でX11がPCへ広がったリンクをコピーしました

初期のLinuxでGUIを使うには、PCのビデオカードで動くXサーバーが必要だった。

X11R5にはIntel 386系Unix向けのX386が含まれていた。David Dawesらはこれを改良し、1992年にXFree86と名付けた。X、自由に再配布できるFree、主な対象だったIntel互換PCの86を組み合わせた名前である。^XFree86

XFree86は多くのビデオカードへ対応し、LinuxでX11環境を作る中心になった。ただし、導入は現在ほど自動化されていない。解像度、同期周波数、ビデオカード、マウスなどを設定ファイルへ書き、値を誤れば画面が出ない。GUIを使うために、まず文字だけの画面で設定を詰める必要があった。

XFree86によって、安価なPCでもUnixワークステーションに近い環境を動かせるようになった。次に必要になったのは、窓を出す仕組みではなく、設定、ファイル管理、ヘルプ、アプリケーションまで揃えたデスクトップだった。

ここで名前を整理しておこう。X11は通信規約、XFree86とX.Org Serverはその実装、XwaylandはWayland上でX11アプリを動かすためのXサーバーである。名前は似ているが、同じものを四度呼び替えているわけではない。

「窓」から「デスクトップ」へリンクをコピーしました

X11とXFree86でアプリの窓は表示できた。しかし、ファイル管理、設定、ヘルプ、アプリ一覧まで一貫して使える環境は、別に組み立てる必要があった。

商用Unixには、先に「一式」があったリンクをコピーしました

統合デスクトップという発想自体は、KDEやGNOMEが最初ではない。商用Unixワークステーションでは、当時広く使われたGUIツールキットOSF/Motifや、Sun、Hewlett-Packard、IBM、Novellなどが共同でまとめた**Common Desktop Environment（CDE）**が使われていた。

CDEにはフロントパネル、ファイル管理、セッション管理、設定、ヘルプ、標準アプリが揃い、異なるUnixワークステーションへ共通の見た目と操作を持ち込もうとしていた。つまり、X11の上へ「仕事を始められる一式」を載せる答えは、すでに商用Unixの世界に存在した。^CDE

問題は、それが自由なLinuxデスクトップの共通基盤にはなりにくかったことだ。当時のCDEは高価で、Motifにもライセンス上の制約があった。安価なPCでUnixに似た環境を使えるようになっても、誰もが自由に配布し、調べ、改良できる統合デスクトップには空白が残った。

KDEとGNOMEが「Linuxデスクトップ」を形にしたリンクをコピーしました

1996年10月14日、Matthias Ettrichは新しいプロジェクトへの参加者を募った。題名はNew Project: Kool Desktop Environment (KDE)。

その文章には、当時の状況を端的に表す一文がある。

The X-Window-System is NOT a GUI.

X Window SystemはGUIではない。

これは、X11にグラフィカルな表示機能がないという意味ではない。X11はウィンドウシステムであり、ファイル管理、設定、パネル、標準アプリまで揃った一般利用者向けの統一GUIではない、という主張である。Ettrichは共通の見た目、ヘルプ、設定、アプリケーション、セッション管理を備えたデスクトップを目指した。KDEはC++のGUIツールキットQtを採用し、1998年に1.0を公開する。^KDE発表

最初の名称Kool Desktop Environmentは、CDEを踏まえた言葉遊びだった。現在のKDEはコミュニティ全体の名称で、文字ごとの意味を持つ略語ではない。^KDEの名前

当時のQtは、利用、再配布、改良の自由を重んじる自由ソフトウェアの基盤として使うには、ライセンス上の懸念があると見られていた。そこで1997年、Miguel de IcazaとFederico MenaらがGNOMEを開始する。自由ソフトウェアだけでデスクトップとアプリケーション群を作り、ツールキットには画像編集ソフトGIMPから生まれたGTKを採用した。^GNOME発表

KDEとGNOMEの競争には、見た目以外の論点があった。どの言語とツールキットを中心にするか、ライブラリをどの条件で配布するか、操作の統一と部品を選ぶ自由をどう両立するか。Qtは後に自由ソフトウェアライセンスで利用できるようになったが、その後もGNOMEとKDEはそれぞれ独自の思想と生態系を育て続けた。

ただし、この時代をライセンスとツールキットの論争だけで眺めると、Linuxデスクトップが人を引きつけた理由の半分を取り逃がす。KDEやGNOMEは、商用Unixにあった機能を自由ソフトウェアで作り直すだけでなく、毎日触れる画面へコミュニティの個性や遊び心を持ち込んだ。

それを象徴するのがWanda the Fishである。GNOMEは当初、GNU Network Object Model Environmentという堅い名前の略だったが、初期のパネルには一匹の魚が住んでいた。1998年のGNOME 0.20では、Wandaを含むパネルアプレットを、アプリの起動やシステム監視だけでなく、格言やジョークを表示するfortune tellerにも使えると紹介している。生産性を直接高める機能ではない。それでも、標準化された仕事道具を揃えるだけだった商用デスクトップから、利用者と開発者が自分たちの居場所を作るデスクトップへ移りつつあったことを、この小さな魚はよく伝えている。デスクトップの将来を巡って真剣に議論しながら、魚に占いをさせる余裕も失わなかったのだ。^{GNOMEの名前とWanda}

2000年代にはKDE 3やGNOME 2が、ファイル管理、設定、ネットワーク、通知、セッション復元などを統合し、「窓が開く環境」をログイン後すぐ仕事を始められるデスクトップへ成熟させた。その後はKDE Plasma、GNOME Shell、Unity、軽量デスクトップ、タイル型環境などへ操作思想が枝分かれしていく。^{デスクトップの成熟}

Linuxデスクトップが一つに統一されなかったため、利用者は多くの選択肢を得た。その反面、設定方法や不具合の原因は環境ごとに変わる。

外観は競い、基礎仕様は共有したリンクをコピーしました

KDEとGNOMEが別々に発展すると、アプリケーション作者は同じ問題を何度も解くことになる。メニューへの登録、アイコン名、ファイルの種類を表すMIMEタイプ、通知、クリップボード、ドラッグ＆ドロップの規則がデスクトップごとに違えば、Linux向けアプリの配布は難しくなる。

2000年前後から、デスクトップ間の共通仕様を議論する場としてfreedesktop.orgが育った。

現在も使われる.desktopファイルは、その成果の一つである。

example.desktop
コピー
[Desktop Entry]
Type=Application
Name=Example Editor
Exec=example-editor %F
Icon=example-editor
Categories=Utility;TextEditor;

GNOME、KDE Plasma、Xfceなどが同じ形式を読めれば、一つのアプリを各デスクトップのメニューへ登録できる。Desktop Entry Specificationには、KDEとGNOME双方の開発者が関わった。^freedesktop

この例では、Nameがメニューに出す名前、Execが起動するプログラム、Iconが表示するアイコンを表す。デスクトップの見た目が違っても、この共通部分は読み替えずに使える。

見た目や操作方針は各デスクトップに任せ、アプリをつなぐ基礎仕様は共有する。Linuxデスクトップは一つに統一されなかったが、無秩序のまま放置されたわけでもない。

X11は拡張を重ね、現代の画面へ対応したリンクをコピーしました

X11には、中核の通信規約を保ったまま機能を足す拡張機構がある。長く使われる間に、入力、複数画面、半透明、GPU描画などを支える仕組みが加わった。X11が「1987年の機能のまま」止まっていたわけではないのだ。

2004年には、XFree86のライセンス変更と開発体制への不満を背景に、多くの開発者とディストリビューションがX.Org Serverへ移った。ディストリビューションとは、Linuxカーネルに各種ソフトウェアを組み合わせ、インストールして使えるOSとして配布するまとまりで、UbuntuやFedoraなどが当てはまる。以後、LinuxではX.OrgがXサーバーの中心になる。^XOrg分岐

描画方法も変わった。初期のX11アプリはXサーバーへ「線を引く」「文字を描く」といった要求を送ることが多かった。やがてGUIツールキットや描画ライブラリがアプリ側で画面を描き、GPUを使って完成に近いウィンドウ画像を作るようになる。

Composite拡張では、各ウィンドウをいったん別々の画像へ描き、コンポジットマネージャーが影、半透明、アニメーションを加えて最終画面を組み立てる。

.pikchr
テキストで表示コピー
P1: box width 4.1in height 1.3in at (0,0)
text "1. 各アプリが作った別々の窓画像" big bold at 0.24in below P1.n
A1: box width 0.85in height 0.40in fill lightblue at P1.center + (-1.18in,-0.18in)
B1: box width 0.85in height 0.40in fill lightgreen at P1.center + (0,-0.18in)
C1: box width 0.85in height 0.40in fill lightyellow at P1.center + (1.18in,-0.18in)

P2: box width 4.1in height 1.9in at 2.0in below P1
text "2. コンポジターが位置・重なり・影を加える" big bold at 0.24in below P2.n

line from P2.center + (-1.05in,-0.70in) to P2.center + (0.15in,-0.40in) then to P2.center + (0.15in,-0.04in) then to P2.center + (-1.05in,-0.34in) then close fill lightblue
line from P2.center + (-0.62in,-0.43in) to P2.center + (0.58in,-0.13in) then to P2.center + (0.58in,0.23in) then to P2.center + (-0.62in,-0.07in) then close fill lightgreen
line from P2.center + (-0.07in,-0.18in) to P2.center + (1.13in,0.10in) then to P2.center + (1.13in,0.46in) then to P2.center + (-0.07in,0.18in) then close fill gray
line from P2.center + (-0.19in,-0.05in) to P2.center + (1.01in,0.23in) then to P2.center + (1.01in,0.59in) then to P2.center + (-0.19in,0.31in) then close fill lightyellow
text "窓の影" bold at P2.center + (1.23in,-0.18in)

P3: box width 4.1in height 1.75in at 2.23in below P2
text "3. 最終フレームは上から見た一枚の2D画像" big bold at 0.24in below P3.n
F: box width 3.25in height 1.0in fill 0xf7f7f7 at P3.center + (0,-0.20in)
A3: box width 1.20in height 0.42in fill lightblue at F.center + (-0.72in,-0.22in)
B3: box width 1.20in height 0.42in fill lightgreen at F.center + (-0.12in,-0.05in)
S3: box width 1.20in height 0.42in fill gray at F.center + (0.56in,0.02in)
C3: box width 1.20in height 0.42in fill lightyellow at F.center + (0.47in,0.08in)

arrow from P1.s to P2.n
arrow from P2.s to P3.n

一段目で各アプリが作るのは、自分の窓に対応する画像までである。二段目では、コンポジターがそれらを画面上の座標へ配置し、前後関係や影などの効果を加える。図では前後関係を直感的に示すため、窓画像を傾けた3Dレイヤーとして描いた。実際に利用者が見るのは、三段目のように上から見た一枚の2D画像、すなわち最終フレームである。窓を移動したり半透明にしたりしても、各アプリが背後の窓まで描き直す必要はない。

2000年代半ばのCompizは、立方体デスクトップ、半透明、雨粒、炎、ゼリーのように揺れる窓を披露した。^Compiz 実用性の乏しい効果もあったが、GPUで窓全体をリアルタイムに合成できることは一目で分かった。

窓を一枚の画像として扱えるようになったことで、同じ仕組みは滑らかなアニメーション、画面拡大、影、縮小表示にも使われた。

X11は拡張によって長期間にわたり新しいハードウェアへ対応した。しかし、現代化が進むほど、1980年代に決めた役割分担とのずれも目立つようになった。

X11の成功が、次の設計を難しくしたリンクをコピーしました

X11は古いから突然使えなくなったのではない。むしろ拡張と互換性によって、当初は想定していなかった使い方まで引き受け、驚くほど長く使えた。その成功が、根本的な役割変更を難しくした。

最終画面を作る者と、入力を配る者リンクをコピーしました

現代のX11環境では、アプリが描いた窓を重ね、最終的な画面を作るのはコンポジターである。窓を縮小・回転し、アニメーションで動かすなら、画面上の本当の位置や形を最もよく知っているのもコンポジターになる。

一方、キーボードやマウスの操作をどのアプリへ渡すかは、歴史的にXサーバーが決めてきた。

.mermaid
テキストで表示コピー
flowchart TB
  I[キーボード・マウス] --> XS[Xサーバー<br>入力先を決める]
  XS -->|入力イベント| A[アプリ]
  A -->|描画結果| XS
  XS --> C[コンポジター<br>窓を配置して合成する]
  C --> D[ディスプレイ]

Compizで窓が揺れたり回転したりしても、Xサーバーが知る窓の形は、変形前のままであることがある。つまり、画面上の最終的な姿を知る者と、入力先を決める者が分かれている。

1980年代にはXサーバーが担っていた仕事の一部も、別の場所へ移った。画面出力や入力機器の基本処理はLinuxカーネルへ、文字や画像を描く処理はアプリ側のライブラリへ移っていった。それでもXサーバーは両者の間に残り、入力や窓の状態を仲介していた。Waylandの設計は、この役割分担を現在の構成に合わせて見直そうとした。^{Wayland設計}

信頼できるアプリだけ、という前提も変わったリンクをコピーしました

X11では、同じXサーバーへ接続できるアプリを、同じ利用者が信頼して起動した仲間として扱う設計が基本にある。接続を許されたアプリは、ほかの窓を調べ、入力を監視し、偽の入力イベントを送ることができる。制限を加える拡張も存在するが、一般的なデスクトップでアプリ同士を強く隔離するのは難しい。^{X11セキュリティ}

研究室で、同じ利用者が選んだプログラムを動かす時代には合理的な前提だった。ところが現在の一台のPCには、Webブラウザー、ゲーム、チャットアプリ、入手元の異なるソフトウェアが同居する。Flatpakのように、アプリをほかの環境から隔離して動かす仕組みも使われる。すべてのアプリへ、画面全体と入力を読む力を自動で渡すわけにはいかなくなった。

なぜX11を直して「X12」にしなかったのかリンクをコピーしました

ここまで読むと、X11をさらに拡張するか、次の版としてX12を作ればよいように思える。

難点は互換性だった。三十年以上にわたり、アプリ、GUIツールキット、ウィンドウマネージャー、遠隔表示、業務システムがX11の挙動へ依存した。中核を大きく変えれば既存のソフトウェアが壊れ、壊さない範囲にとどめれば古い前提を残すことになる。

互換性を守って拡張できたことがX11の寿命を延ばし、同時に根本的な変更を難しくした。X.Org周辺の開発者たちは、問題を直すにはX11との互換性をいったん切り離す必要があると判断し、別の通信規約としてWaylandを作った。^X11の保守

Waylandは、X11と互換性のある「X12」ではない。現代のLinuxカーネルとGPUを前提に、表示を担う側の責任を定義し直した別の設計である。

Waylandは、役割分担を組み直したリンクをコピーしました

2008年9月30日、Kristian HøgsbergはWaylandのリポジトリへ最初のコミットを行った。コミットメッセージはInitial commit.、追加されたのは8ファイル821行だった。^{Wayland初回コミット}

Waylandという名前は、マサチューセッツ州の町に由来する。参照用コンポジターのWestonはその隣町、後のアクセシビリティ研究Newtonも近隣の地名である。新しい表示基盤の周辺に、なぜかニューイングランドの地図が広がっていった。^{Wayland周辺の名前}

Waylandは一つの画面サーバーではないリンクをコピーしました

ここでいうプロトコルは、二つのプログラムがどんなメッセージを、どの順序と形式でやり取りするかを決めた通信規約である。

Waylandは、すべてのデスクトップで共通に動く一つのプログラムの名前ではない。アプリとコンポジターが通信するためのプロトコルと、その実装を助けるライブラリを提供する。

GNOMEではMutter、KDE PlasmaではKWin、SwayではSway自身が、Waylandコンポジターとして表示、入力、窓の管理を担う。^{Waylandとは}

.mermaid
テキストで表示コピー
flowchart TB
  I[キーボード・マウス] --> C[Waylandコンポジター<br>入力先と最終画面を管理]
  C -->|入力イベント| A[アプリ]
  A -->|描画済みの画像| C
  C --> D[ディスプレイ]

X11の図と比べると、Xサーバーとコンポジターに分かれていた判断が、Waylandコンポジターへ集まっている。最終画面を知るプログラムが入力先も決めるため、窓を変形して表示しても、見えている位置と入力の位置を一致させやすい。

アプリは「完成した絵」を渡すリンクをコピーしました

Waylandでは、アプリが自分の窓の内容を描く。GTKやQtといったGUIツールキットに加え、必要ならOpenGLやVulkanのような、GPUへ描画を頼むための共通の呼び出し方を使い、ピクセルの並んだ画像を作る。この描画済み画像を入れておくメモリ領域がbufferである。

一方、surfaceは、画像を表示へ結び付ける窓口である。bufferを絵そのものとすれば、surfaceはその絵の更新範囲や拡大方法など、表示に必要な状態をまとめる。アプリはbufferをsurfaceへ関連付け、コンポジターへ「次はこの内容を表示してほしい」と知らせる。通常の窓やマウスポインターといった役割は、別のプロトコルからsurfaceへ与えられる。^{Wayland中核}

.pikchr
テキストで表示コピー
B: box width 2.65in height 1.3in at (0,0)
text "buffer = ピクセルの並んだ画像" big bold at 0.24in below B.n
P1: box width 0.42in height 0.30in fill lightblue at B.center + (-0.72in,-0.20in)
P2: box width 0.42in height 0.30in fill lightgreen at B.center + (-0.24in,-0.20in)
P3: box width 0.42in height 0.30in fill lightyellow at B.center + (0.24in,-0.20in)
P4: box width 0.42in height 0.30in fill lightgreen at B.center + (0.72in,-0.20in)

S: box width 3.8in height 1.75in at 2.1in below B
text "surface = 画像と表示状態を結ぶ窓口" big bold at 0.24in below S.n
I: box "bufferの画像" width 1.55in height 0.78in fill lightblue at S.center + (-0.85in,-0.20in)
R1: box "更新範囲" width 0.90in height 0.32in fill lightgray at S.center + (0.92in,0.14in)
R2: box "拡大・変換" width 0.90in height 0.32in fill lightgray at S.center + (0.92in,-0.24in)
R3: box "与えられた役割" width 0.90in height 0.32in fill lightgray at S.center + (0.92in,-0.62in)

arrow from B.s to S.n
text "関連付ける" at B.s + (0.55in,-0.40in)

bufferだけでは、それが通常の窓なのか、マウスポインターなのか、どのように表示を更新するのかは決まらない。surfaceへ画像と状態を結び付け、別のプロトコルから役割を与えて初めて、コンポジターが表示上の意味を判断できる。トップレベル窓を画面のどこへ置くかは、アプリではなくコンポジターが決める。

コンポジターは複数のsurfaceを並べ、前後関係や拡大率を適用し、ディスプレイへ出す最終画面を作る。Waylandへ替えれば描画が自動的に高速になるわけではない。遅延や滑らかさは、アプリ、コンポジター、GPUドライバー、フレームの同期を含む経路全体で決まる。新しい設計は魔法の高速化スイッチではなく、古い責任分担を整理する土台である。

LinuxのGUIには二つの流れがあるリンクをコピーしました

アプリから画面までを一本の配管として覚えようとすると、部品の名前が急に増えて見える。まず、入力をアプリへ届ける流れと、アプリの画像を画面へ届ける流れへ分けると分かりやすい。

入力は、利用者からアプリへ向かう。

入力機器
↓
Linuxカーネル
↓
Xサーバー／Waylandコンポジター
↓
操作を受け取るアプリ

画像は、アプリからディスプレイへ向かう。

GTK・Qtなどを使って描くアプリ
↓
描画済みの画像（buffer）
↓
Xサーバー／Waylandコンポジター
複数の画像をまとめる
↓
Linuxカーネル
↓
ディスプレイ

この並びでは途中をまとめたが、GPUを使う場合は、グラフィックス用ライブラリのMesaやGPUドライバーが画像作りを助ける。最後はLinuxカーネルがGPUと画面出力を管理する。初期のX11アプリのように、Xサーバーへ「線を引く」「文字を描く」と命令する別の経路もある。ここで大切なのは製品名をすべて覚えることではなく、入力と画像が逆向きに流れ、それぞれの途中を別の部品が担当することだ。

LinuxのグラフィックスでいうDRMはDirect Rendering Managerの略で、GPUや画面出力を扱うカーネル側の仕組みを指す。映像配信のコピー制御で使われるDigital Rights Managementとは、略称が同じだけの別物である。KMSはKernel Mode Settingで、解像度や出力先などの表示モードをカーネルが管理する仕組みだ。^DRMとKMS

役割をもう一段細かく分けると、次のようになる。この表は用語を引き直したいときの索引として使えばよい。

MutterやKWinは、X11セッションではウィンドウマネージャー兼コンポジットマネージャーとして、WaylandセッションではWaylandコンポジターとして動く。一つのプログラムが複数の役を兼ねるため注意が必要である。

画面共有は、利用者へ尋ねてからリンクをコピーしました

X11では、同じXサーバーへ接続できるアプリが画面全体を読み取ることは比較的容易だった。スクリーンショットや画面共有ツールには都合がよいが、利用者が意図していないアプリにも同じ能力を与えやすい。

Waylandでは、アプリは自分以外の窓や画面全体を自由には読めない。そこでGNOMEやKDE Plasmaなどの主要なデスクトップでは、アプリの要求を安全に仲介するXDG Desktop Portalと、映像や音声を受け渡すPipeWireを使う構成が一般的になった。

.mermaid
テキストで表示コピー
flowchart TB
  A[画面共有アプリ]
  A -->|共有を要求| P[Portal]
  P --> U[利用者が共有対象を<br>選んで許可する]
  U --> C[デスクトップの共有機能が<br>許可対象を取り出す]
  C --> W[PipeWireが映像を運ぶ]
  W -->|映像ストリーム| A

図の「デスクトップの共有機能」には、Portalからの要求をGNOMEやKDE Plasmaへ橋渡しするデスクトップ固有の実装と、コンポジターが含まれる。利用者が選んだモニターやウィンドウだけが、PipeWireの映像ストリームとしてアプリへ渡される。リモート操作では、キーボードやポインターの利用にも許可が必要になる。^Portal

この方式はX11より部品が多く、各デスクトップやアプリの対応が揃うまで不具合も起きた。代わりに、画面全体を読める権限を自動では渡さず、選んだ対象だけを共有できる。許可ダイアログは面倒を増やす飾りではなく、どこから先をアプリへ見せるかという境界そのものである。

遠隔GUIは用途ごとに分かれたリンクをコピーしました

X11は、遠隔アプリの窓を手元へ出す機能をウィンドウシステムの中核に持っていた。Waylandの中核プロトコルは、同じ方式のネットワーク透過性を目標にしていない。

現在は用途に応じて仕組みを選ぶ。

• 離れたPCのデスクトップ全体を操作するなら、Windows系で広く使われるRDPや、画面画像を転送するVNC
• 会議アプリで画面を見せるならportalとPipeWire
• Waylandアプリの窓を転送するならwaypipeなどの専用ツール
• X11アプリの窓を転送するならSSHのX11転送
• Waylandデスクトップ上でローカルのX11アプリを動かすならXwayland

Waylandデスクトップ上でSSHのX11転送を使う場合、表示先のXサーバーとしてXwaylandが経路に加わることはある。しかし、遠隔転送を行うのはSSHとX11であり、Xwaylandそのものは遠隔プロトコルではない。

X11は遠隔表示を汎用プロトコルへ組み込んだ。Waylandはローカル画面の受け渡しに範囲を絞り、遠隔デスクトップや映像転送を別の仕組みへ任せる。この違いは、機能の有無より、どこまでを中核へ含めるかという設計の差である。

Waylandは小さな中核と拡張で育つリンクをコピーしました

役割を分ける考え方は、遠隔表示だけでなく、Wayland自身が新しい機能を増やす方法にも表れている。

Waylandの中核は意図的に小さい。通常の窓として最大化できること、150%で拡大すること、HDR映像の色を正しく扱うことまで、すべてを中核へ詰め込んではいない。2026年7月時点ではWayland 1.26とwayland-protocols 1.49が公開されており、中核と拡張は別々に更新されている。^{Waylandの拡張}

デスクトップ向けの機能は、wayland-protocolsにある拡張プロトコルなどで足していく。

先ほどのsurfaceは、描画内容を置くための「面」であって、それだけでは通常のアプリ窓にならない。マウスポインター、ドラッグ中のアイコン、デスクトップの窓など、用途に応じたroleを別のプロトコルから与える。最大化やタイトル付きの通常窓として扱う規則を定めるのがxdg-shellである。

この分け方により、中核を安定させたまま新しい用途を追加できる。その代わり、仕様が書かれただけでは機能にならない。コンポジター、GTKやQt、ブラウザー、ゲームエンジン、GPUドライバーが同じ仕様を実装して、初めて利用者の手元で動く。Waylandへの移行が長引いた理由の一つは、この合意と実装を機能ごとに積み上げる必要があったためである。

移行は一度の切り替えでは終わらないリンクをコピーしました

新しい設計ができても、既存のアプリと利用者を置き去りにはできない。Waylandの普及は、互換層を用意し、既定値を変え、ときには元へ戻る段階的な移行になった。

Xwaylandが古いアプリを支えるリンクをコピーしました

Waylandへ移行するために、既存のX11アプリを一斉に作り直すことはできない。そこで使われるのがXwaylandである。

Xwaylandは単純な変換ライブラリではなく、X.Org Serverのコードを共有するX11サーバーである。物理ディスプレイや入力機器を直接管理せず、Waylandコンポジター上のクライアントとして動く。^Xwayland

.mermaid
テキストで表示コピー
flowchart TB
  W[Wayland対応アプリ] -->|Wayland| C[Waylandコンポジター]
  X[X11アプリ] -->|X11| XW[Xwayland]
  XW -->|Wayland| C
  C --> K[カーネル・GPU<br>ディスプレイ]

古い業務アプリ、ゲーム、開発ツール、X11専用GUIは、Xwaylandを通じてWaylandデスクトップ上に表示できる。デスクトップ側は新しい仕組みへ移り、アプリ側は必要なものから順に対応できる。

Xwaylandがあるため、デスクトップとアプリは別々の時期に移行できる。互換層は余分な部品でもあるが、数十年分のアプリを抱えたまま基盤を替えるには欠かせなかった。

Waylandへの移行には、何度も足踏みがあったリンクをコピーしました

Waylandの開発が始まったのは2008年だが、主要ディストリビューションの既定になるまでには長い時間がかかった。

2016年、Fedora 25 WorkstationはGNOMEの既定セッションをWaylandへ変更した。X11アプリはXwaylandで動かした。^{Fedora-Wayland}

Ubuntu 17.10も2017年にWaylandを既定にしたが、次の18.04 LTSではX.Orgへ戻した。画面共有、リモートデスクトップ、障害時の復旧など、長期サポート版に必要な機能と安定性が十分ではないと判断したためである。2021年のUbuntu 21.04でWaylandは再び既定になった。^{Ubuntuの往復}

Canonicalは別案も試した。2013年、スマートフォン、タブレット、PCを一つのUbuntuへ統合する構想のため、独自のディスプレイサーバーMirを発表する。一時はX11の次がWaylandとMirへ分かれる可能性もあった。

2017年、CanonicalはUnity 8と端末統合への投資を終了し、UbuntuデスクトップをGNOMEへ戻した。Mirは開発を続け、現在はWaylandコンポジターを構築するためのライブラリとして、組み込み用途などで使われている。^Mir

Waylandへの移行を決めるのは、通信規約の完成度だけではない。ディストリビューションの既定値、GPUとそのドライバー、GTKやQt、ブラウザー、ゲーム、リモートデスクトップ、障害のある人の操作を助ける機能が、それぞれ別の速度で対応する。一か所が「完成」を宣言しても、日常のデスクトップが一斉に切り替わるわけではなかった。

2026年7月時点の移行状況リンクをコピーしました

KDE Plasma 6は2024年にWaylandセッションを既定にした。GNOME 49は2025年に専用X11セッションを既定で無効化し、Fedora 43はそのセッションを提供するパッケージを削除した。Ubuntuの標準デスクトップであるUbuntu Desktopも25.10からWaylandのみとなり、2026年のUbuntu 26.04 LTSへ引き継がれた。これはXfceやMATEなど、Ubuntu上で選べるほかのデスクトップまでX11を使えなくなったという意味ではない。X11向けアプリも、Xwaylandを通して引き続き動かせる。^{現在のWayland移行}

KDE側では、2026年6月16日に公開されたPlasma 6.7が、ログイン用X11セッションを含む最後の機能リリースとなった。2026年10月公開予定のPlasma 6.8ではX11セッションを外し、X11アプリの実行はXwaylandへ任せる計画である。^{Plasma-X11終了}

Xが生まれ、X11が定着
1984–2007
↓
Waylandを育て、実用化
2008–2023
↓
互換層を残して主役を交代
2024–

これらは、Xwaylandで動くX11アプリまで直ちに廃止する話ではない。X11は消滅したというより、デスクトップ全体を動かす主役から、既存アプリを支える互換層へ重心を移したと捉える方が正確である。

移行は、既定の経路をWaylandへ替え、Xwaylandで既存アプリを支え、問題が減った段階でX11セッションを外す順番で進んだ。「既定になった年」と「古いセッションが外れた年」が大きく離れているのは、そのためである。

十年以上かかったのは、窓を表示するだけでは足りないからリンクをコピーしました

デスクトップを日常的に使うには、窓が開くだけでは不十分である。日本語入力、ドラッグ＆ドロップ、画面ごとの色合わせ、ペンタブレット、画面共有、リモート操作、ゲーム画面を滑らかに更新する同期、画面の内容を音声で読み上げるスクリーンリーダーまで動かなければならない。

日本語入力だけを見ても、キーイベントをアプリへ渡せば終わりではない。変換候補の窓をどこへ置くか、どのアプリが入力を受け取るか、ほかから隔離されたアプリ環境の内外をどうつなぐかまで調整する必要がある。

X11では、アプリが画面全体の座標や入力を広く知れることを前提に作られた機能が多かった。Waylandで同じ機能を再現する際は、単に禁止を解除するのではなく、誰に何を許可するかを含めて、プログラム同士の新しい受け渡し方を決める必要がある。画面共有のportalや、支援技術向けの入力処理がその例である。GNOMEでは2025年から2026年にかけても、Wayland上の支援技術、画面更新速度の自動調整、小数倍率の拡大、色管理の改良が続いた。^{Wayland移行の残課題}

移行が遅かったという批判には理由がある。それでも、実際に置き換えた範囲は二つのウィンドウシステムだけに収まらない。周辺のアプリとデバイスが利用してきた権限や通信方法まで、一つずつ設計し直す必要があった。

窓は残り、画面までの経路が変わるリンクをコピーしました

タイトルバーをつかんで窓を動かし、最大化し、複数のアプリを並べる。基本的な操作はXerox StarやMacintoshの時代から驚くほど長く残っている。現在のウィンドウシステム開発で難しいのは、窓枠を新しく見せることより、中身を異なる画面へ正しく届けることである。

現在は、密度の違う複数画面、HDRや色管理、画面共有、タッチや支援技術まで、同じ表示基盤の上で扱う必要がある。Waylandの拡張プロトコルと各コンポジターは、これらを「例外」として継ぎ足すのではなく、誰が情報と権限を仲介するかを定め直している。^{表示基盤の現在地}

ただし、WaylandにはX.Org Serverに相当する唯一の実装がない。仕様が定まっても、Mutter、KWin、コンポジター作りを助けるwlroots、GTK、Qt、ブラウザー、ゲームエンジン、GPUドライバーが対応して初めて、利用者には一つの機能として届く。歩調を揃えるのは容易ではないが、その手間こそ、画面を出すために誰が何を担うのかを明確にする作業でもある。

いまLinuxで端末を開けば、黒い背景に文字が並ぶ。その窓を動かしているのはWaylandで、隣の古いGUIアプリはXwaylandを通っているかもしれない。見た目には一枚のデスクトップでも、画面の下では、異なる時代に作られた仕組みが役割を分け合っている。

LinuxのGUI史は、黒い画面を追放した歴史ではない。黒い画面を窓の一つに収め、その窓を動かす仕組みを、時代に合わせて作り替えてきた歴史である。