/lost+found/amanoese

作られては忘れられていくコードや日常のための日記

【Ubuntu】USBドック(DisplayLink)で外部ディスプレイが1枚だけ映らない原因は `nomodeset`

CursorCLIで問題解決させるのにかかった時間が15分ほどで、 Cursorがどのような問題を把握して解決していたかを理解しながなら、この記事するのに2時間かかりました。 また、最初はケチってgemini-3-flashを利用していました問題解決せず、途中からClaude 4.6 Opusを利用することで容易に解決に向かった印象です。

そのため、実際に同じ問題を解決したい場合は、この記事を読むよりCursorやClaude CodeやGemini CLIを利用して適当にプロンプトを打つほうが早く解決するはずです。 (2026/2/8現在)課金してClaude 4.6 Opusを使いましょう

以下の内容はCusosrCLIを利用して解決した事象かつ、ブログ内容多くの部分をCursorに記載してもらっているため、正確性に劣る点がありましたらお気軽にコメントしてください。
この記事が誰かのためになりましたら、幸いです。

はじめに

Ubuntu系Linuxで外部ディスプレイ2枚をAnker 564 USB-Cドッキングステーション（DisplayLink搭載）経由で接続していたところ、2枚のうち1枚だけが認識されないという問題に遭遇しました。カーネルレベルではデバイスが見えているのにX11(xrandr)からは見えないという、なかなか厄介な症状でした。

本記事では、調査の過程と根本原因、そして有効だった修正手順を詳しくまとめます。

環境

項目 内容
PC Lenovo ThinkBook 14 G3 ACL
CPU AMD Ryzen 5 5600U
GPU AMD Radeon Graphics (Cezanne / Radeon Vega Series) ※CPU内蔵
OS Ubuntu 24.04.3 LTS (Noble Numbat)
カーネル 6.8.0-90-generic
USBドック Anker 564 USB-C ドッキングステーション (DisplayLink, ID 17e9:6000)
外部ディスプレイ 2枚（いずれもDock経由で接続）

PC・ディスプレイ構成図

graph TD
    subgraph PC["ノートPC (Ubuntu Linux)"]
        GPU["AMD Radeon Graphics"]
    end

    GPU -- "eDP (内蔵)" --> LCD["内蔵液晶 ✅"]
    GPU -- "USB-C" --> DOCK["Anker 564<br>USB-C ドッキングステーション<br>(DisplayLink / 17e9:6000)"]
    DOCK -- "DisplayPort" --> EXT1["外部ディスプレイ 1枚目 ✅"]
    DOCK -- "HDMI" --> EXT2["外部ディスプレイ 2枚目 ❌<br>← 認識されない！"]

    style LCD fill:#d4edda,stroke:#28a745
    style EXT1 fill:#d4edda,stroke:#28a745
    style EXT2 fill:#f8d7da,stroke:#dc3545
    style DOCK fill:#fff3cd,stroke:#ffc107
  • 内蔵液晶 (eDP): 正常に表示
  • 外部1枚目 (DisplayPort): Dock経由 → 正常に表示
  • 外部2枚目 (HDMI): Dock経由 → 認識されない ※xrandr上では DVI-I として表示される

補足: eDPとは？ eDP (Embedded DisplayPort) は、ノートPC内蔵の液晶パネルとGPUを接続するための規格です。外部ディスプレイ向けのDisplayPortをノートPC内部の液晶パネル接続用に最適化したもので、xrandr の出力で eDP や eDP-1 と表示される場合は内蔵液晶を指しています。

症状

  • Anker 564 Dock経由で接続した外部ディスプレイ2枚のうち、1枚が認識されない
  • もう1枚のDisplayPort接続のディスプレイは正常に動作

調査の流れ

1. カーネル・ドライバー側の確認

まず、DisplayLink関連のサービスとモジュールの状態を確認しました。

# サービスの確認
$ systemctl status displaylink-driver.service
● displaylink-driver.service - DisplayLink Driver Service
     Loaded: loaded (/usr/lib/systemd/system/displaylink-driver.service; static)
     Active: active (running) since Sat 2026-02-07 14:30:20 JST; 6min ago
   Main PID: 2386 (DisplayLinkMana)

# カーネルモジュールの確認
$ lsmod | grep evdi
evdi                   86016  5

# USBデバイスの確認
$ lsusb | grep DisplayLink
Bus 004 Device 003: ID 17e9:6000 DisplayLink DL-Dock

# DRMコネクタの状態確認
$ cat /sys/class/drm/card2-DVI-I-2/status
connected

結果: カーネルレベルでは、DisplayLinkドライバー(evdi)もUSBデバイスも正常に動作しており、物理的な接続も検知されていました。

2. X11 (xrandr) 側の確認

次に、ウィンドウシステム側から認識状況を確認しました。

プロバイダー一覧の確認:

$ xrandr --listproviders
Providers: number : 1
Provider 0: id: 0x56 cap: 0x9, Source Output, Sink Offload crtcs: 4 outputs: 4 associated providers: 0 name:AMD Radeon Graphics @ pci:0000:05:00.0

Provider 0 (AMD Radeon Graphics) のみで、DisplayLink (evdi) プロバイダーが表示されていません。

出力一覧の確認:

$ xrandr --query
Screen 0: minimum 320 x 200, current 3840 x 1080, maximum 16384 x 16384
eDP connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 309mm x 174mm
   1920x1080     60.05*+
   ...
HDMI-A-0 disconnected (normal left inverted right x axis y axis)
DisplayPort-0 disconnected (normal left inverted right x axis y axis)
DisplayPort-1 connected 1920x1080+1920+0 (normal left inverted right x axis y axis) 544mm x 303mm
   1920x1080     60.00*+
   ...

eDP (内蔵) と DisplayPort-1 (外部1枚目) は認識されていますが、DVI-I-x などの DisplayLink 用出力が表示されていません。

結果: カーネルでは認識されているのに、X11のxrandrからはDisplayLinkプロバイダーが一切見えていませんでした。

3. ここまでの推測

カーネルレベルではevdiモジュールが正常動作しているが、X11の出力プロバイダーとして登録・同期されていない状態。つまり、ドライバーとX11の間のどこかに問題がありそうでした。

根本原因の特定

効果のない対応が続いたため、Xorgのログを詳細に調査しました。ここで根本原因が判明します。

原因1（主因）: nomodeset カーネルパラメータ

GRUBの設定を確認したところ、カーネルコマンドラインに nomodeset が設定されていました。

# /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nomodeset"

nomodeset はカーネルモードセッティング(KMS)を無効化するパラメータです。おそらく過去にグラフィックドライバーの問題を回避するために追加されたものが、そのまま残っていたようです。

なぜこれがDisplayLinkに影響するのか、メカニズムを詳しく説明します。

カーネルモードセッティング (KMS) とは

Linuxでは、ディスプレイの解像度設定やフレームバッファの管理をカーネル側で行う仕組みをカーネルモードセッティング (KMS) と呼びます。KMSが有効な場合、GPUドライバー（今回は amdgpu）はカーネル内の DRM (Direct Rendering Manager) サブシステムと連携し、/dev/dri/card* デバイスを通じてX11にGPU情報を公開します。

graph TD
    subgraph KMS有効時の正常な流れ
        GPU["GPU (amdgpu)"] -- "KMS経由で<br>DRMデバイスを公開" --> CARD0["/dev/dri/card0"]
        GPU -- "KMS経由で<br>DRMデバイスを公開" --> CARD2["/dev/dri/card2"]
        CARD0 --> P0["Xorg: Provider 0<br>(AMD Radeon Graphics)"]
        CARD2 --> P1["Xorg: Provider 1<br>(modesetting / evdi)"]
        P0 --> X0["xrandr: eDP, DP-1"]
        P1 --> X1["xrandr: DVI-I-1, DVI-I-2"]
    end

    style P0 fill:#d4edda,stroke:#28a745
    style P1 fill:#d4edda,stroke:#28a745
    style X0 fill:#d4edda,stroke:#28a745
    style X1 fill:#d4edda,stroke:#28a745

evdi (DisplayLinkドライバー) のKMS依存

DisplayLinkのLinuxドライバーは、evdi (Extensible Virtual Display Interface) というカーネルモジュールで構成されています。evdiは「仮想GPU」としてDRMサブシステムに登録され、/dev/dri/card2 のようなDRMデバイスを作成します。

重要なのは、evdiがDRM/KMSの枠組みの上に構築されているという点です。evdiは自分自身をDRM KMSドライバーとしてカーネルに登録し、Xorgの modesetting ドライバーがそのDRMデバイスを認識することで、xrandrのプロバイダーとして表示されるようになります。

nomodeset が引き起こす連鎖的な問題

nomodeset をカーネルパラメータに設定すると、以下の連鎖が発生します:

flowchart LR
    S1["1. カーネル起動時に<br>KMS が無効化される"]

    S1 --> S2["2. amdgpu の KMS が初期化されない<br>→ ファームウェア設定済みの<br>フレームバッファ (efifb/simpledrm)<br>がそのまま使われる"]
    S1 --> S4["4. evdi はカーネルモジュール<br>としてロードされる (成功)<br>→ /dev/dri/card2 は作成される<br>→ DRMコネクタは connected を返す"]

    S2 --> S3["3. Xorg が起動<br>→ modesetting ドライバーが<br>正常に動作しない"]

    S3 --> S5["5. evdi の DRMデバイスを<br>プロバイダーとして登録できない"]
    S4 -.->|"Xorgに伝わらない"| S5

    S5 --> S6["xrandr --listproviders に<br>DisplayLink が表示されない"]

    style S1 fill:#f8d7da,stroke:#dc3545
    style S2 fill:#f8d7da,stroke:#dc3545
    style S3 fill:#f8d7da,stroke:#dc3545
    style S4 fill:#d4edda,stroke:#28a745
    style S5 fill:#f8d7da,stroke:#dc3545
    style S6 fill:#f8d7da,stroke:#dc3545

つまり、nomodeset の影響は以下のように整理できます:

レイヤー 状態 説明
USB 正常 DisplayLink DL-Dock がデバイスとして認識
カーネルモジュール (evdi) 正常 モジュールがロードされ、DRMデバイスを作成
DRM/KMS 異常 KMSが無効のため、DRMデバイスの情報がXorgに正しく伝わらない
X11 (Xorg/xrandr) 異常 modesettingドライバーがevdiのDRMデバイスを認識できず、プロバイダー未登録

「カーネルでは見えるのにxrandrでは見えない」 という症状は、まさにDRM/KMSレイヤーが nomodeset によって機能不全に陥り、カーネルとX11の橋渡しが断たれたことによるものでした。

原因2（副因）: xorg.conf の不正な設定

/etc/X11/xorg.conf に存在しないデバイスが定義されていました。

  • Card1 (PCI:5:0:1) が定義されていたが、実際には存在しない
  • Xorgログに AMDGPU(1): [drm] Failed to open DRM device for pci:0000:05:00.0 エラー
  • Screen 0 deleted because of no matching config section エラーが3件発生

これらの不要な設定がXorgの起動時にエラーを引き起こし、正常なデバイス構成を阻害していた可能性があります。

有効だった修正

修正1: GRUBから nomodeset を削除（最も重要）

# /etc/default/grub を編集
sudo vi /etc/default/grub

変更内容:

- GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nomodeset"
+ GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

GRUBの更新を反映:

sudo update-grub

修正2: xorg.conf の整理

まずバックアップを作成:

sudo cp /etc/X11/xorg.conf /etc/X11/xorg.conf.bak.20260207

存在しないデバイスの定義を削除し、Card0 (PCI:5:0:0, amdgpu) のみのシンプルな構成に変更:

# /etc/X11/xorg.conf（修正後）
Section "ServerLayout"
    Identifier     "X.org Configured"
    Screen      0  "Screen0" 0 0
EndSection

Section "Files"
    ModulePath   "/usr/lib/xorg/modules"
    FontPath     "/usr/share/fonts/X11/misc"
    FontPath     "/usr/share/fonts/X11/Type1"
    FontPath     "built-ins"
EndSection

Section "Module"
    Load  "glx"
EndSection

Section "Monitor"
    Identifier   "Monitor0"
    VendorName   "Monitor Vendor"
    ModelName    "Monitor Model"
    EndSection

Section "Device"
    Identifier  "Card0"
    Driver      "amdgpu"
    BusID       "PCI:5:0:0"
EndSection

Section "Screen"
    Identifier "Screen0"
    Device     "Card0"
    Monitor    "Monitor0"
    SubSection "Display"
        Viewport   0 0
        Depth     24
    EndSubSection
EndSection

削除したもの: - Card1 (PCI:5:0:1) の Device セクション - 対応する Screen1、Monitor1 のセクション - ServerLayout 内の Screen 1 の記述

修正3: 20-displaylink.conf の修正

不要な BusID "USB" の記述を削除しました。

# /etc/X11/xorg.conf.d/20-displaylink.conf（修正後）
Section "Device"
    Identifier "DisplayLink"
    Driver     "modesetting"
    Option     "PageFlip" "false"
EndSection

再起動して確認

すべての修正を行った後、OSを再起動します。

再起動後にプロバイダーを確認:

$ xrandr --listproviders
Providers: number : 5
Provider 0: id: 0x56 cap: 0x9, Source Output, Sink Offload crtcs: 4 outputs: 4 associated providers: 4 name:AMD Radeon Graphics @ pci:0000:05:00.0
Provider 1: id: 0x10c cap: 0x6, Sink Output, Source Offload crtcs: 1 outputs: 1 associated providers: 1 name:modesetting
Provider 2: id: 0xeb cap: 0x6, Sink Output, Source Offload crtcs: 1 outputs: 1 associated providers: 1 name:modesetting
Provider 3: id: 0xca cap: 0x6, Sink Output, Source Offload crtcs: 1 outputs: 1 associated providers: 1 name:modesetting
Provider 4: id: 0xa0 cap: 0x6, Sink Output, Source Offload crtcs: 1 outputs: 1 associated providers: 1 name:modesetting

DisplayLink (modesetting) プロバイダーが Provider 1〜4 として認識されました！

出力一覧を確認:

$ xrandr --query
Screen 0: minimum 320 x 200, current 3840 x 2160, maximum 16384 x 16384
eDP connected primary 1920x1080+0+1080 (normal left inverted right x axis y axis) 309mm x 174mm
   1920x1080     60.05*+
   ...
HDMI-A-0 disconnected (normal left inverted right x axis y axis)
DisplayPort-0 disconnected (normal left inverted right x axis y axis)
DisplayPort-1 connected 1920x1080+1920+0 (normal left inverted right x axis y axis) 544mm x 303mm
   1920x1080     60.00*+
   ...
DVI-I-4-4 disconnected (normal left inverted right x axis y axis)
DVI-I-3-3 disconnected (normal left inverted right x axis y axis)
DVI-I-2-2 disconnected (normal left inverted right x axis y axis)
DVI-I-1-1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 527mm x 296mm
   1920x1080     60.00*+
   ...

DVI-I-1-1 が connected として認識され、外部ディスプレイ2枚目が使用可能になりました！

カーネルコマンドラインの確認（nomodeset が消えていることを確認）:

$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-6.8.0-90-generic root=UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx ro quiet splash vt.handoff=7

※ UUIDは環境固有のため伏せています。

USBデバイスとカーネルモジュールの確認:

$ lsusb | grep DisplayLink
Bus 004 Device 003: ID 17e9:6000 DisplayLink DL-Dock

$ lsmod | grep evdi
evdi                   86016  5

無事、DisplayLinkプロバイダーが認識され、外部ディスプレイ2枚目（DVI-I-1-1）が使えるようになりました。

まとめ

項目 内容
症状 DisplayLink経由の外部ディスプレイがX11から認識されない
根本原因 GRUBの nomodeset パラメータがKMSを無効化し、evdiのプロバイダー登録を阻害
副次的原因 xorg.conf内の存在しないデバイス定義によるXorgエラー
解決方法 nomodeset の削除 + xorg.conf の整理

付録: 試行錯誤（効果がなかった対応）

根本原因の特定に至るまでに試した対応を、参考として記録しておきます。

sudo systemctl restart displaylink-driver.service

→ 効果なし。サービス自体は正常に動作しているため、再起動しても状態は変わりませんでした。

xrandr --setprovideroutputsource の試行

xrandr --setprovideroutputsource 1 0

このコマンドは、X11のマルチGPU環境でサブGPU（プロバイダー1）の映像出力を、メインGPU（プロバイダー0）経由で表示させるための設定です。

通常、DisplayLinkのようなUSB接続のGPUは、メインGPU（ここではAMD Radeon）とは独立したプロバイダーとしてX11に登録されます。しかしそのままではメインGPUのディスプレイとして統合されないため、--setprovideroutputsource を使って「プロバイダー1（DisplayLink）の出力ソースをプロバイダー0（AMD）にする」と指定します。これにより、DisplayLink側のディスプレイがxrandr上で通常の外部モニターとして扱えるようになります。

# 正常時のプロバイダー一覧（期待される状態）
$ xrandr --listproviders
Provider 0: AMD Radeon Graphics    # メインGPU
Provider 1: modesetting            # DisplayLink (evdi)

# プロバイダー1の出力をプロバイダー0に統合
$ xrandr --setprovideroutputsource 1 0

→ 失敗。今回はそもそもDisplayLinkがプロバイダーとして認識されていなかったため（--listproviders にProvider 0しか表示されない）、設定対象が見つからず実行できませんでした。

OS再起動

→ 効果なし。

xorg.conf.d にDisplayLink設定ファイルを追加

/etc/X11/xorg.conf.d/20-displaylink.conf を作成しました。

Section "Device"
    Identifier "DisplayLink"
    Driver     "modesetting"
    Option     "PageFlip" "false"
EndSection

この設定ファイルの意味は以下の通りです:

  • Driver "modesetting": DisplayLinkデバイス（evdiが作成するDRMデバイス）に対して、Xorgの汎用KMSドライバーである modesetting を使用するよう明示的に指定します。DisplayLinkの公式ドライバーはevdiカーネルモジュール + Xorgのmodesettingドライバーの組み合わせで動作する設計のため、この指定が推奨されています。
  • Option "PageFlip" "false": ページフリップ（ダブルバッファリングによる画面更新）を無効化します。DisplayLinkはUSB経由の仮想GPUであり、ハードウェアレベルのページフリップをサポートしていないため、これを無効にしないと画面のちらつきや描画崩れが発生することがあります。

この設定は、Xorgが起動時にDisplayLinkデバイスを正しいドライバーで認識させるためのもので、DisplayLink公式のセットアップガイドでも推奨されている定番の対応です。

→ 効果なし。設定自体は正しいものの、根本原因が nomodeset によるKMS無効化だったため、modesetting ドライバーが正常に機能する前提が崩れており、この設定だけでは問題を解決できませんでした。

教訓

  1. nomodeset は強力だが副作用も大きい: グラフィック問題の応急処置として nomodeset を設定することはよくありますが、問題が解決した後に外し忘れると、今回のようにDisplayLinkなどKMS依存の機能に影響が出ます。

  2. カーネルレベルとX11レベルを分けて調査する: 「カーネルでは認識されているのにX11では見えない」という状況は、その間にある仕組み（KMS、DRMプロバイダー登録）を疑うべきサインです。

  3. Xorgログは情報の宝庫: 今回も最終的にはXorgログの詳細調査で根本原因を特定できました。/var/log/Xorg.0.log や journalctl のログを丁寧に読むことが重要です。

  4. xorg.conf は定期的に見直す: ハードウェア構成を変更した際に、古い設定が残っているとエラーの原因になります。不要な設定は積極的に整理しましょう。

参考文献

※本記事はCursor CLIを用いて作成し、内容は筆者が確認・加筆修正しています。