Phoenix - Zigでゼロから書き直された最新のXサーバー

 (git.dec05eba.com)
2 ポイント 投稿者 GN⁺ 2025-12-25 | 1件のコメント | WhatsAppで共有
  • Phoenix は既存のXorgをフォークせず、Zig言語でゼロから書かれた新しいXサーバーで、モダンな代替を目指している
  • 現在は GLX、EGL、Vulkanグラフィックスを使うシンプルなアプリケーション を既存のXサーバー内でネスト実行でき、スタンドアロン実行はまだサポートされていない
  • シンプルさ のため、過去20年以内に書かれたアプリケーションと過去15年以内のハードウェアのみをサポートし、サーバードライバーインターフェースなし で動作する
  • セキュリティ を強化し、プロトコルメッセージを自動パースし、アプリケーション間アクセスは 権限リクエストベースの分離構造 で制限する
  • HDR、VRR、マルチモニター、内蔵コンポジター などのモダンな技術をサポートし、Wayland互換性とX11プロトコル拡張も計画している

Phoenix 概要

  • Phoenix はXorgサーバーを置き換えるモダンなXサーバーで、Zig言語で完全にゼロから書かれた実装
    • Xorgのフォークではなく、よりシンプルで安全な構造 を志向
  • 現在は完全に利用可能な段階ではなく、既存のXサーバー内でのネスト実行（nested mode） のみをサポート
    • GLX、EGL、Vulkanベースの ハードウェアアクセラレーションレンダリング を実行可能

目標

シンプルさ

  • Xorgよりシンプルなサーバーとして、X11プロトコルの一部のみをサポート
    • 過去20年以内に書かれたアプリケーションに必要な機能のみを含む
  • Linux DRM と Mesa GBM をサポートする過去15年以内のハードウェアのみを対象
  • Xorgのような別個の サーバードライバーインターフェース は使用しない
    • Waylandコンポジターに似た構造

セキュリティ

  • プロトコルメッセージの自動パース により安全性を確保
    • Zigの ReleaseSafe ビルドオプションにより、配列インデックス超過などの不正動作を自動検出
  • デフォルトでアプリケーション間を 分離実行
    • 他アプリとの相互作用は GUIによる権限リクエスト または 事前権限付与 によってのみ可能
    • 例: 画面録画アプリは指定されたウィンドウのみ録画可能
  • アクセス制限時、クライアントはエラーの代わりに ダミーデータ を受信
  • グローバルショートカット は修飾キー（ctrl、shiftなど）を含む場合に動作
    • 修飾キーなしでグローバルショートカットを使う場合は明示的な権限が必要
  • オプションにより Xorgと同じ動作方式に切り替え可能

モダン技術のサポート

  • マルチモニター、異なるリフレッシュレート、VRR、HDR など最新のディスプレイ技術をサポート
  • 単一フレームバッファではなく、各ディスプレイごとに独立して処理

グラフィックス処理の改善

  • デフォルトでティアリングのないレンダリング と 内蔵コンポジター を提供
    • 外部コンポジター（picomなど）を起動すると自動で無効化
    • フルスクリーンアプリが vsync を無効にした場合は、そのアプリに合わせて調整
  • vsync およびコンポジター遅延の削減 を目標とする

新しい標準

  • モニターごとのDPI属性（randr property） を定義・文書化
    • アプリケーションがモニターごとのDPIに合わせてコンテンツをスケーリング可能

X11プロトコル拡張

  • HDRなどの新機能 が必要になれば X11 プロトコル拡張を予定

Wayland互換性

  • 一部のアプリがWayland専用である可能性を考慮
    • Phoenixが Waylandを直接サポート するか、Wayland–X11ブリッジ（例: 12to11） を通じて実行可能にする計画

ネストされたディスプレイサーバー

  • X11 または Wayland 内でハードウェアアクセラレーションによるネスト実行 が可能
    • Phoenixのデバッグおよび ウィンドウマネージャー・コンポジターのテスト に有用
    • Wayland環境では Xwaylandの代替サーバー として活用可能

非目標（Non-goals）

  • Xorgサーバーの完全な置き換え は目標ではない
    • Xorgはより多くのX11機能と古いハードウェアのサポートを維持する
  • 複数のX11スクリーン はサポートしない（マルチモニターのみサポート）
  • GrabServer 呼び出しは無効
  • エンディアンスワップのクライアント/サーバー は必要に応じて再検討
  • 間接GLX（リモートレンダリング） はサポートしない
    • 複雑性が高く、リモートストリーミングの方が効率的
    • 必要なら GLXプロキシ を介したリモートレンダリングは可能

X11プロトコルとの違い

  • フォント関連機能などX11コアプロトコルの一部は未実装
  • 文字列エンコーディングは デフォルトで UTF-8 を使用
    • ただし、プロトコルで ISO Latin-1 と明示されている場合は例外

インストールとビルド

  • インストールコマンド: 
    zig build -Doptimize=ReleaseSafe
sudo zig build install -p /usr/local -Doptimize=ReleaseSafe
  • 削除は手動で /usr/local/bin/phoenix を削除する必要がある
  • 開発用ビルド: 
    zig build
    • 出力バイナリ: ./zig-out/bin/phoenix
    • 実行とビルドを同時に行うことも可能: zig build run

X11プロトコル文書の生成

  • コマンド: zig build -Dgenerate-docs=true
    • 結果: ./zig-out/protocol/ 内に .txt ファイルを生成
    • 公式ドキュメントスタイルの自動生成文書で、現在進行中の機能

依存関係

  • Zig 0.14.1
  • x11 (xcb) — X11ネストモード用 (-Dbackends=x11)
  • wayland (wayland-client, wayland-egl) — Waylandネストモード用 (-Dbackends=wayland、現時点では未サポート)
  • drm (libdrm, gbm) — スタンドアロン実行用 (-Dbackends=drm、現時点では未サポート)
  • OpenGL (libglvnd) — gl と egl を提供

関連記事

1件のコメント

 
GN⁺ 2025-12-25
Hacker Newsのコメント

  • XサーバーをWaylandスタイルで再構成しようとするアプローチが興味深い
    ディスプレイサーバーとコンポジタを基本的に統合し、アプリをデフォルトで分離し、GLXのリモート機能を削除し、古いプロトコルを大胆に捨てている点が印象的
    誰にこれが必要なのかは分からないが、この選択自体はかなり合理的に見える

    • X11をどうしても使う必要がある人にとっては、XLibreより良い選択肢に見える
    • 実際に使ってはいないが、既存機能を削ったのなら結局Waylandに近い状況になる気がする
      だとすると何が違うのか分からない。たぶん分析が不完全だったのかもしれない
    • これがもっと早く出ていたなら、多くの人がWaylandではなくこちらを好んでいた気がする
      しかもWaylandアプリも動くなら、実際にこちらを選ぶユーザーはさらに多いかもしれない

  • Phoenixという名前は使われすぎている
    ElixirフレームワークにもPhoenixがあるし、ほかのプロジェクトでも何度も見た記憶がある
    「Apollo」みたいによくある名前なので、新しいプロジェクトを作るならまず検索すべきだと思う

    • ElixirエコシステムのPhoenixは、むしろそれほど混乱しない方だ
      あちらには bandit, cowboy, thousand island, ranch, mint, finch のような独特な名前が多い
      ExThing、ThingEx、Thingx のような名前の重複もよくあって、どれが標準なのか分かりにくい
    • 昔から「灰の中から蘇るプロジェクト」という象徴としてPhoenixという名前はよく使われてきた
      1980年代にもそんなふうに新しいソフトウェアに名前を付けていた記憶がある
    • FirefoxもPhoenixという名前を使おうとして、商標問題で訴えられたことがあった
      wxPythonにもPhoenixプロジェクトがある。かっこいいが、あまりにもありふれた名前だ

  • このプロジェクトは本当にすばらしい
    Waylandは好きだが、ポータルプロトコルと拡張メカニズムには今でも不満がある
    WindowsやmacOSと比べて、生産性の面で足りない部分がある
    セキュリティを内蔵したX11のリライトとは、期待できるアプローチだ

    • Waylandの代わりに整理されたXのバージョンを作る方がよいと、ずっと思ってきた
      有用なプロジェクトに見えるし、発展してほしい
    • Waylandは生産性の面で不足があると言っていたが、具体的に何が足りないのか気になる
    • むしろWindowsやmacOSの方がウィンドウ管理すらまともにできていないと思う
      2000年代初頭はインストールすら難しく、一般ユーザーが自分で入れるのはほぼ不可能に近かった
      Linuxディストリビューションの方がはるかに導入しやすく、Windowsが遅くなったら新しいPCを買う理由もそこにあった
    • 私はむしろWaylandで生産性不足を感じたことがない
      会社でもGNOME + Waylandで問題なく仕事をしている

  • こうしたX保存プロジェクトは歓迎したい
    Waylandの方が好みではあるが、それでもなおXが必要な領域はあると思う
    新しい開発チームが負担を分担すべきだ

    • ただ、こうした選択は断片化を招くと思う
      X11はもう完全に埋葬して、1つのディスプレイサーバーに集中すべきだ

  • このプロジェクトがどれだけうまく動くかは分からないが、
    企業主導の単一化の流れ（例: Wayland、GNOME、KDEの有償開発者）に対抗して、
    競合プロジェクトが増えるのはよいことだと思う
    Xorgをモダナイズするのにどれだけの資金が必要なのかも気になる
    Waylandは2008年に登場したが、20年近くたってもユーザーの要求をすべて満たせていない
    企業が望む狭い仕様に合わせようとした結果、限界がはっきりしている

  • アプリケーション開発者はビルドスクリプトで zig build --release の形で
    リリースモードを指定できる
    ユーザーが自分で --release を渡してもよい
    Phoenixの作者はReleaseSafeモードを正式リリースとして選んだようだ
    ちなみにPhoenixは私の故郷の名前でもある

  • 同じ作者が作った gpu-screen-recorder は、
    Waylandで使った中で最高の画面録画ツールだ
    4K 60fps録画も特に設定なしですぐ動いた

  • xterm、emacs、xfig、ghostview のような既存のX11アプリが動くのか気になる

    • たいていの古いX11プログラムはX11の描画APIに依存しているので、
      きちんと動かない可能性が高いが、実装自体は簡単だ

  • マルチスクリーン対応が非目標とされているが、
    それだと仮想デスクトップに対応するウィンドウマネージャ（i3など）では使えないのか気になる

    • X11でいう「screen」には特定の意味があるので、単一スクリーン対応だけでも
      マルチモニターや仮想デスクトップの利用には問題ない
    • Xineramaのような連続マルチモニター機能は、後から簡単に追加できる構造になっている

  • XorgのようにXMLプロトコル仕様をコード生成に使わない点が興味深い