X11のインストールと設定（xorg.conf・xhost・xauth・Wayland）

X11の設定ファイル：xorg.conf、xorg.conf.d

Xサーバー（Xorg）の設定は、伝統的には/etc/X11/xorg.confという1つの設定ファイルに記述されていました。近年の多くのディストリビューションでは、ハードウェアの自動検出精度が向上したことで、xorg.conf自体が存在しない（あるいは空に近い）状態でも動作するようになっていますが、キーボードレイアウトの固定やグラフィックドライバの明示的な指定等、個別の調整が必要な場合には、依然としてこれらの設定ファイルを編集します。

xorg.confの主なSection

xorg.confは、複数のSection（設定の区分）で構成されます。

xorg.conf.d：設定を分割して管理する

/etc/X11/xorg.conf.d/ディレクトリには、xorg.confの内容を機能ごとに分割した、複数の小さな設定ファイル（.conf拡張子）を置くことができます。/usr/share/X11/xorg.conf.d/も設定断片の配置に使われ、実際のパスや優先順位はディストリビューションによって異なります。パッケージ管理システムが個々のドライバ用の設定を追加する際にも、この仕組みが使われます。

/etc/X11/xorg.conf.d/40-libinput.conf     # 入力デバイス関連の設定ファイルの例

キーボードレイアウトの設定

キーボードレイアウトは、xorg.conf.d内の設定断片に記述したInputClassセクションのXkbLayoutオプションで指定できます。

Section "InputClass"
    Identifier "keyboard defaults"
    MatchIsKeyboard "on"
    Option "XkbLayout" "jp"
EndSection

現在のXセッションに限り一時的にレイアウトを変更したい場合は、setxkbmapコマンドを使うこともできます。

setxkbmap jp     # 現在のXセッションのキーボードレイアウトを日本語配列に変更する

setxkbmapによる変更はその場限りのXセッションに対する変更です。再起動後も維持するには、xorg.conf.d、デスクトップ環境の設定、またはセッション開始時の設定などでレイアウトを設定します。Waylandセッションでは、xorg.conf.dやsetxkbmapによる設定が同じように適用されるとは限りません。^{出典：Arch Linuxのsetxkbmapマニュアルページ。setxkbmapは「現在のXセッションに対して」レイアウトを設定するツールと説明されています。[1]}。

Xサーバーへのアクセス制御：xhostとxauth

X11はネットワーク透過的な仕組みであるため、「誰がこのXサーバーに接続してウィンドウを表示してよいか」を制御する仕組みが必要です。

xhost：ホスト単位を中心とするアクセス制御

xhostは、特定のホスト（マシン）からの接続を許可・拒否する、単純なアクセス制御コマンドです。localuser:ユーザー名のようなサーバー解釈型アドレスを指定し、ローカルユーザーを許可することもできます。

xhost +remotehost     # remotehostからの接続を許可する
xhost -remotehost      # remotehostの許可エントリを削除する
xhost +                 # アクセス制御を無効化し、すべてのホストからの接続を許可する（強く非推奨）

xhostによる追加・削除は、DISPLAYで指定される実行中のXサーバーのアクセス制御リストを変更する操作です。通常、これらの変更はXサーバーを再起動すると維持されません。

ホストを指定して許可するxhostの設定は粗い制御であり、そのホストから接続するユーザーを個別に区別できません。 xhost +のように無制限に許可すると、意図しない第三者にまで画面へのアクセスを許してしまう危険があるため、避けるべきとされています。

xauth：Cookie（認証情報）によるアクセス制御

xauthは、Xauthorityファイル内の認証情報を管理するコマンドです。MIT-MAGIC-COOKIEと呼ばれる秘密の認証情報（Cookie）を使い、Cookieを提示できるクライアントを認証します。各ユーザーのホームディレクトリの~/.XauthorityファイルにCookieが保存されることが多く、Xクライアントは接続時にこのCookieを提示することで認証されます。

xauth list                                      # 保存されているCookieの一覧を表示する
xauth extract - "$DISPLAY" | ssh remotehost xauth merge -  # 現在のDISPLAY用のCookieをリモートホストに渡す

この例では、リモートホスト上で設定するDISPLAYに対応するXauthorityエントリを抽出・転送する必要があります。Cookieを別のマシンで使う場合は、Cookieが秘密情報であること、および接続先のXサーバーとDISPLAY名に対応したCookieを扱う必要があることに注意します。リモートホスト上のXクライアントを接続させるには、リモート側で接続先に対応するDISPLAYを設定し、Xサーバー側もその接続を受け入れられる必要があります。

xhostがホスト単位の粗い制御であるのに対し、MIT-MAGIC-COOKIE認証はCookie（秘密情報）を知っているクライアントだけを認証する仕組みです。 ただし、MIT-MAGIC-COOKIE認証はX11通信を暗号化しません。ネットワーク越しにX11を利用する場合は、SSHのX11フォワーディングを使うことが推奨されます。SSHのX11フォワーディング機能を使う場合、Cookieの受け渡しはSSH側が自動的に処理してくれるため、通常はxauthを意識する必要はありません^{SSHによるX11フォワーディングの使い方自体は「SSH・GnuPGによる暗号化」の技術解説記事で扱っています。[2]}。

~/.xsession-errors：Xセッションのエラーログ

~/.xsession-errorsは、グラフィカルログイン時に起動されるXクライアント（ウィンドウマネージャ、パネル、各種アプリケーション等）の標準出力・標準エラー出力が記録される場合があるファイルです。作成されるかどうかや内容は、ディスプレイマネージャ、セッション、ディストリビューションによって異なります。ログイン後に画面が正しく表示されない、特定のアプリケーションが起動しない、といったトラブルシューティングの際に参照します。

Waylandとの関係

Waylandは、X11に代わる新しいディスプレイサーバープロトコルとして開発されました。X11ではXサーバーがクライアントからの描画要求を処理し、画面合成はコンポジットマネージャが担う場合があります。これに対しWaylandでは、コンポジタ（画面合成を行うプロセス）がディスプレイサーバーとしてクライアントの描画を扱い、画面を合成します。GNOMEやKDE Plasmaなど、多くの主要なデスクトップ環境が、既定のディスプレイサーバーとしてWaylandへの対応・移行を進めています^{Waylandへの移行状況はディストリビューション・バージョンによって異なるため、「すべての環境でWaylandが既定になっている」とは断定できません。[3]}。