概要
前回はsystemdに関して色々まとめた何かを書きましたが今回はLinuxデスクトップでのグラフィック周りについてのお話です。これに関しては日本語の情報がほとんどなく間違ってる部分もあるかもしれません。その際は遠慮なく指摘してください。
Linuxデスクトップといっても沢山あるので、今回はAlexandriteOSやFedoraなどで標準のWayland利用のデスクトップの場合について解説します。
ここで一つ理解して置かなければならないのはWaylandはあくまでもただのプロトコルとライブラリであって、従来のXserverのようなものではないということです。要はWaylandはあくまでルールに過ぎないということです。（厳密には違いますがややこしくなるのでこの解釈でここでは問題ありません）
Waylandの構造
いきなり分かりにくい図が出てきましたが、これがAlexandriteOSやFedoraのグラフィックの仕組みの基本的な部分です。一つ一つ見ていきましょう。
この図において一番目につくのはWaylandコンポジターという部分です。このWayland CompositorはDEによって異なります。Gnomeの場合はmutter、KDEの場合はKwinがコンポジターです。
このコンポジターこそがグラフィックの中枢システムです。
- マウスが動かされたなどのイベントが発生すると、カーネルからwaylandコンポジターに伝わります。
- コンポジターはイベントを受け取ると、どのウィンドウがそのイベントを受け取るべきかを判断し、適切なクライアントに送信します。
- クライアントはコンポジターからの通知を受け取ると、EGLとMesa 3Dを使用してレンダリングを行い、更新された領域を示すリクエストをコンポジターに送ります。レンダリングはlibDRMを通してフレームバッファに行われます。
- コンポジターはレンダリングが行われたことを受信すると、先程レンダリングされたフレームバッファ内のコンテンツをテクスチャとして利用し変更された領域を合成します。KMSを通じて画面を再描画し、最終的にディスプレイの内容が更新されます。
全体像
しかしこれだけで全てが成り立っている訳ではありません。
グラフィックシステムの最終的な全体像はこうなります。
- XwaylandとはX11のみに対応しているレガシーアプリケーション（図中のX11-Client）を実行するための仕組みです。この図の通り、Wayland上でXorgを実行することで互換性を維持しています。
- ゲームなどの高パフォーマンスを要求するソフト（図中の “3D Gmae Engine”）はVulkanやOpenGLなどのAPIを利用してグラフィックメモリバッファに直接レンダリングします。クライアントとコンポジターはバンドラーを利用してこのグラフィックメモリバッファにアクセスします。この手順では間に余計なデータのコピーを挟まないため高速に描画できます。さらにコンポジターは、APIクライアントと同じハードウェアアクセラレーションAPIを使用することで、ディスプレイに表示する最終的な合成をさらに最適化することができます。
まとめ
LinuxデスクトップはWindowsなどと比べて遅れていますがWaylandやPipewireの導入などで状況が変わりつつあります。AMDの躍進でグラフィックドライバーも整備されつつありますし、Steam Deckの登場でLinuxゲーミングという分野も復活しつつあります。Gnome42でもグラフィック周りの改善が入っていますし、KDEも本格的にWaylandに対応しています。今後の動向を注視する必要がありそうです。