Slackware-currentのtestingに入ったXLibreを試す（AMD Radeon編）
2026年6月13日
著者: 竹洞 陽一郎
2026年6月11日付のslackware64-currentのChangeLogで、testing/packages/xlibre/以下にXLibre Xserver一式が追加されました。
Patrick Volkerding氏は以前から「1年ほど様子を見てから判断したい」と述べていましたが、ちょうどXLibreの1周年（2025年6月にフォーク）を経て、testingという形で姿を現したことになります。
今回は、このXLibreをAMD Radeon環境（RDNA4世代、Radeon RX 9070）へ導入する手順をご紹介します。
XLibreとは
XLibre（X11Libre）は、X Window System（X11）の参照実装であるX.Org Serverのフォークです。
2025年6月5日に、X.Orgの最も活発な開発者であったEnrico Weigelt氏を中心に開始されました。
Waylandへの移行を進めるX.Org陣営の方針に対し、X11を将来も使える選択肢として維持・刷新することを目的としています。
バージョン25.0以降、コンテナなど異なるセキュリティドメインのクライアントを分離するXnamespace拡張、XnestのXCBへの移植、ABIごとのドライバディレクトリ、複数のCVE修正などが導入されています。
また、画面のティアリングを防ぐTearFreeがmodesettingでデフォルト有効化されている点も特徴です。
ひとつ重要な注意点として、XLibreのサーバはX.Org Serverとは非互換であり、パッケージ名もxorg-serverとは別のxlibre-serverになっています。
そのため、単純なupgradepkgではなく、xorg-serverを削除してからxlibre-serverを入れる、という手順を踏みます。
X.Orgとの確執 ― フォークに至るまでの生々しい経緯
XLibreの誕生は、技術的な事情だけでなく、X.Org開発コミュニティ内の激しい対立を背景にしています。
この経緯はかなり生々しく、評価も真っ二つに割れているため、導入を判断するうえで知っておいて損はありません。
以下は、複数のメディア報道や当事者の声明をもとにした整理です。立場によって主張が食い違う部分が多いので、どちらの言い分かを明示しながら記します。
「最も活発な貢献者」と「品質が低い」の衝突
Weigelt氏は、2024年以降のX.Org Serverにおいて、おそらく最も活発な貢献者でした。
新機能やテストパイプラインを含め、数百件に及ぶパッチを送っていたと報じられています。
一方でX.Org側の開発者は、彼のコードは品質管理が不十分で、十分なテストを経ておらず、多数のリグレッション（退行）を招く破壊的なものだと判断し、取り込みを見送ったり差し戻したりしていました。
この「貢献量は多いが品質を巡って対立した」という構図が、すべての発端です。
翌日の「粛清」
2025年6月5日ごろ、Weigelt氏がX.Orgをフォークする計画が報じられます。
すると報道によれば、そのわずか翌日の6月6日、freedesktop.orgのGitLabインフラから彼のアカウントが凍結され、リポジトリ、チケット、そして140件を超えるマージリクエストが一斉に削除されました。
Weigelt氏自身も、6月6日の声明で「今朝凍結された」と述べており、フォーク計画の公表から実に約24時間という早さでの措置でした。
この措置はfreedesktop.orgのCode of Conduct（行動規範）委員会によるものとされていますが、具体的に何が規約違反だったのかは説明されていません。
委員会が沈黙を保ったことは外形的に印象が悪く、結果としてWeigelt氏側の「不当な排除だ」という主張に一定の説得力を与えてしまった、という指摘もあります。
Weigelt氏の主張とRed Hat / IBM
Weigelt氏は「History repeats: Redhat censored me（歴史は繰り返す、Red Hatが私を検閲した）」と題した声明を出し、X.OrgはRed Hatに「乗っ取られ」、自社製品であるWaylandの競合を排除するためにX11を意図的に殺そうとしている、と主張しました。
XLibreのREADMEでも、X.Org内部には「BigTechから送り込まれた工作員（moles）」「有害な分子（toxic elements）」がいて、プロジェクトを意図的に停滞させていると非難しています。
ここでのRed Hatは、2019年にIBMが買収した企業であり、いわゆる「IBM＝Red Hat陣営」として語られます。
ただし公平を期すと、これらの「Red Hat従業員が削除を実行した」という因果関係について、Weigelt氏は確たる証拠を示してはいない、という批判的な報道もあります。
あくまで「当事者の一方による主張」として受け止めるのが妥当でしょう。
DEI・行動規範をめぐる政治的な論争
この対立は、純粋な技術論にとどまらず、政治的・思想的な論争にも発展しています。
XLibreは、一般的な行動規範（CoC）を採用せず、「あなたの政治的立場や性的指向には関知しない」という趣旨の文言を掲げ、DEI（多様性・公平性・包摂性）と距離を置く姿勢を明確にしました。
これを「実力本位で良い」と評価する声がある一方、CoCを重視する開発者からは反発を招き、Weigelt氏個人についても極右的な思想への共感やDEIへの反対があるとの批判が向けられています。
さらに遡ると、彼は2021年にLinuxカーネルのメーリングリストでワクチン接種に反対する非科学的な主張を展開し、Linus Torvalds氏から叱責された経緯もあり、もともと論争の多い人物として知られています。
ディストリビューションの反応 ― 割れる評価
大手の反応は冷ややかです。
FedoraやDebianの開発者はXLibreへの参加を明確に拒否し、Canonical（Ubuntu）は将来のリリースでX11サポート自体を外す方向、RHELやSUSEもWayland一本化を進めています。
その一方で、Artix Linux、GhostBSD、OpenMandrivaなど11のディストリビューションがすでにXLibreをデフォルトのX11実装として採用し、35以上のディストリで有志によるサードパーティパッケージが提供されています。
そして今回、Slackware-currentがtestingという慎重な形でこれに加わったわけです。
Patrick氏が即座にmainへ入れず、1年の様子見を経てtesting止まりにしているのは、こうした政治的な火種と技術的な成熟度の双方を見極めようとする、いかにもSlackwareらしい距離の取り方だと言えます。
筆者の立場としては、思想や政治の話と、コードそのものの良し悪しは切り離して評価すべきだと考えています。
XLibreが本当にX11を延命させる技術的価値を持つのかは、最終的には実機で動かし、安定性とメンテナンスの継続性を自分の目で確かめるしかありません。
だからこそ、testingという「試せるが本番ではない」位置づけは、ちょうど良い距離感だと思います。
testingに追加されたパッケージ
ChangeLogに追加されたのは、サーバ本体4本、入力ドライバ5本、ビデオドライバ15本の計24本です。
サーバ本体は以下の4本です。
xlibre-server xlibre-server-xephyr xlibre-server-xnest xlibre-server-xvfb
入力ドライバは以下の5本です。
xf86-input-evdev xf86-input-libinput xf86-input-synaptics xf86-input-vmmouse xf86-input-wacom
ビデオドライバは、amdgpu、ati、dummy、intel、mach64、mga、neomagic、nouveau、openchrome、r128、s3virge、savage、trident、vesa、vmwareの15本が用意されています。
ただし後述の通り、新しいAMD GPUではこれらのDDXを使わずmodesettingに任せるのが推奨です。
事前準備
Slackwareはデフォルトのランレベルが3（テキストモード）で、ログイン後にstartxでXを起動して使う方が多いと思います。
この運用なら、Xを起動していないテキストコンソールの状態でパッケージを入れ替えられるため、特別な準備はほとんど要りません。
作業中はXを終了し、ランレベル3のコンソールに戻ってから以降の手順を進めます。
万一XLibreが起動しなくても、startxが失敗するだけでテキストコンソールには必ず戻れるので、復旧経路の心配はほぼ不要です。
なお、ランレベル4でディスプレイマネージャ（SDDM、xdmなど）を使って常用している場合のみ、念のためデフォルトを一時的にランレベル3へ落としておくと安全です。
その場合は/etc/inittabのid:4:initdefault:をid:3:initdefault:に変更します。
# （ランレベル4運用の場合のみ）/etc/inittab の initdefault を 4 から 3 に変更する # id:4:initdefault: -> id:3:initdefault: vi /etc/inittab
別のマシンからsshで入れる状態にしておくと、コンソールが使えない場合でも遠隔で対処できて、より安心です。
念のため、現在のXorg関連パッケージの一覧を控えておきます。元に戻す際の確認に使えます。
ls /var/log/packages/ | grep -E 'xorg-server|xf86-' > ~/xorg-pkglist.txt
パッケージの取得
testingディレクトリからXLibre一式を取得します。
ここでは国内ミラーのmirror.slackware.jpを使います。
mkdir -p ~/xlibre && cd ~/xlibre lftp -c "open https://mirror.slackware.jp/slackware/slackware64-current/testing/packages/ ; mirror xlibre ." cd xlibre
wgetで取得する場合は以下の通りです。
mkdir -p ~/xlibre && cd ~/xlibre wget -r -np -nH --cut-dirs=5 -R "index.html*" \ https://mirror.slackware.jp/slackware/slackware64-current/testing/packages/xlibre/ cd xlibre
取得後、パッケージが24本揃っているかを確認しておきます。
ls *.txz | wc -l
サーバ本体の入れ替え
前述の通り、xlibre-serverはxorg-serverと非互換のため、先にxorg-serverを削除してからインストールします。
removepkg xorg-server xorg-server-xephyr xorg-server-xnest xorg-server-xvfb installpkg xlibre-server-*.txz xlibre-server-xephyr-*.txz xlibre-server-xnest-*.txz xlibre-server-xvfb-*.txz
ドライバの導入（AMD Radeonの場合）
今回の検証環境はRadeon RX 9070、RDNA4世代のNavi 48です。
この世代のような新しいAMD GPUでは、ビデオDDX（xf86-video-amdgpuやxf86-video-ati）を入れず、カーネルのamdgpuドライバとMesaを使い、Xサーバはmodesettingに任せる構成が推奨されます。
そもそもDDXとは
DDXはDevice Dependent X（デバイス依存部）の略で、Xサーバ内部のアーキテクチャを指す用語です。
対になる概念としてDIX（Device Independent X／デバイス非依存部）があります。
DIXは、ウィンドウ管理やイベント処理、プロトコル解釈といったハードウェアに依存しない共通部分を担い、DDXは、実際の画面描画や入出力デバイスの制御といった、ハードウェアごとに異なる部分を担います。
ごく大雑把に言えば、DIXがXの「頭脳・共通ルール」、DDXが「ハードウェアとの接点」です。
実務上「DDXドライバ」と言う場合は、xf86-video-amdgpu、xf86-video-intel、xf86-video-ati、xf86-video-nouveauといった、X.Org用のビデオドライバ群を指します。
これらはXサーバ上で動くユーザー空間のドライバで、かつては2Dアクセラレーションや画面出力をハードウェア固有の方法で担っていました。
ところが、カーネル側にKMS（Kernel Mode Setting）とDRM（Direct Rendering Manager）が整備されたことで、実際のモード設定や描画の主役が、カーネルのドライバ（amdgpuカーネルモジュールなど）とMesaへ移りました。
その結果、Xサーバには汎用のmodesettingドライバが用意され、ハードウェア固有のDDXを使わなくてもKMS経由で描画できるようになっています。
このmodesettingも技術的にはDDXの一種ですが、特定ベンダー専用ではなく汎用である点が異なります。
つまり、ビデオ出力を担うDDXは、今やmodesetting一枚で足りる時代になった、というわけです。
理由は明確です。描画の実体はカーネルのamdgpuドライバとMesaが担い、Xサーバはmodesetting経由でKMSに出すだけです。
レガシーなDDXは新しいGPUに対して利点がなく、むしろ不安定要因になり得ます。
Slackware-currentはkernel 6.18系、Mesa 26.x系と、RDNA4を十分にサポートする新しさが揃っているため、modesetting単独で問題なく動きます。
そのため、ビデオドライバ（xf86-video-*）は入れず、入力ドライバだけを導入します。
upgradepkg --install-new xf86-input-libinput-*.txz upgradepkg --install-new xf86-input-evdev-*.txz
なお、かなり古いRadeon（radeonカーネルモジュール側）を使う場合はxf86-video-atiが必要になることがありますが、RX 9070のような最近のカードでは不要です。
TearFreeの設定
modesettingでは、画面のティアリングを防ぐTearFreeを有効にできます。
RX 9070のような環境では、有効にしておくと動画再生やスクロールが滑らかになります。
cat > /etc/X11/xorg.conf.d/20-amdgpu.conf <<'EOF'
Section "Device"
Identifier "AMD"
Driver "modesetting"
Option "TearFree" "true"
EndSection
EOF
起動確認
リブートはせず、テキストコンソールからstartxでXを起動して確認します。
もし起動しなくても、コンソールに戻ってログを確認すれば原因を追えます。
startx
ログを確認し、XLibreのバナーとmodesettingのロード、OpenGLのレンダラを見ます。
ログの場所は、一般ユーザーでstartxした場合は~/.local/share/xorg/Xorg.0.log、rootの場合は/var/log/Xorg.0.logです。
grep -Ei 'XLibre|modeset|amdgpu|TearFree' ~/.local/share/xorg/Xorg.0.log glxinfo | grep -E "OpenGL renderer|OpenGL version"
ログにXLibreのバナーが出て、modeset(0)がロードされ、OpenGL rendererにRadeon RX 9070（RADV経由）が表示されていれば成功です。
これで、以降は普段どおりstartxでXLibreが立ち上がるようになります。
（ランレベル4運用で事前にinittabを3へ変更していた場合は、ここで4へ戻して常用に移行します。）
元に戻すには
XLibreはあくまでtestingの試験的なパッケージであり、mainツリーへ昇格したわけではありません。
不具合があれば、いつでもX.Org Serverへ戻せます。
xlibre-serverを削除し、mainツリーのxorg-server一式を再インストールします。
removepkg xlibre-server xlibre-server-xephyr xlibre-server-xnest xlibre-server-xvfb # mainツリーの x/ から xorg-server 一式を取得して再インストール upgradepkg --reinstall --install-new xorg-server-*.txz xorg-server-xephyr-*.txz \ xorg-server-xnest-*.txz xorg-server-xvfb-*.txz
TearFree用に作成した設定ファイルも、不要であれば削除しておきます。
rm -f /etc/X11/xorg.conf.d/20-amdgpu.conf
おわりに
XLibreがtestingに入ったことで、SlackwareでもX.Orgのフォークを公式パッケージとして手軽に試せるようになりました。
今回のAMD Radeon環境では、modesettingに任せる素直な構成で、特に引っかかることなく動作します。
NvidiaのプロプライエタリドライバはABIが変わっているため別途XLibre向けのドライバが必要ですが、AMDのオープンソーススタックではその心配がいらないのも利点です。
testingの位置づけであることを踏まえつつ、X11の今後を占う意味でも、ぜひ一度お試し下さい。