Зовнішній монітор не виявляється: єдиний драйвер, який вам бракує

February 14, 2026 • February 14, 2026 • Читання: 6 хв • Views: 0

Було корисно?

Ви під’єднуєте зовнішній монітор. Вентилятор ноутбука змінює тон, ніби готується до зльоту. Док загорається. Монітор прокидається, а потім знову вимикається. У налаштуваннях немає нічого. Ваш «другий екран» перетворився на «теоретичний екран».

Здебільшого це не магія. Це відсутній або несумісний драйвер у стеку відображення — а стек вищий, ніж думають. Цей матеріал — польовий посібник: як швидко визначити реальне вузьке місце, які команди запускати, що означає вивід і яке рішення приймати далі.

Що насправді означає «єдиний драйвер» (і чому він варіюється)

Коли хтось каже «встановіть драйвер», це натякає на єдиний перемикач, який увімкне «зовнішній монітор». Насправді ж існує ланцюжок. Виявлення зовнішнього дисплея не відбувається, коли одне посилання не відповідає дійсному апаратному шляху, яким ви користуєтеся.

Існує чотири поширені шляхи підключення зовнішніх моніторів у сучасних ноутбуках/десктопах:

Рідні GPU-інтерфейси (HDMI/DP), які під’єднані безпосередньо до GPU (вбудований або дискретний). Драйвери: Intel i915, AMD amdgpu, власний NVIDIA nvidia (і його стек modeset) або відкритий nouveau.
USB-C DisplayPort Alt Mode, коли порт USB-C насправді передає сигнали DisplayPort. Ті самі драйвери GPU, але також потрібні контролер Type-C, ретаймери та іноді стек Thunderbolt, щоб працювати разом.
Thunderbolt-доки, які подають DP-виходи, часто це «рідний» DP, тунельований через Thunderbolt. Драйвери включають GPU DRM/KMS плюс Thunderbolt (thunderbolt) і іноді прошивкові особливості.
DisplayLink-доки/адаптери, які стискають відео по USB і використовують модуль ядра та користувацький сервіс для створення віртуального GPU. Драйвер: DisplayLink (зазвичай evdi модуль ядра + демон у просторові користувача). Інша архітектура. Інші типи відмов.

Отже, що таке «єдиний драйвер, якого вам бракує»? Це залежить від того, яким шляхом ви йдете:

Якщо ваш док — DisplayLink і ви поводитеся з ним як з DP Alt Mode, вам бракує стеку DisplayLink/EVDI.
Якщо ви на NVIDIA і встановили «драйвер», але не увімкнули nvidia-drm modeset або модуль ядра не відповідає користувацьким бібліотекам, вам бракує працюючої пари ядро+користувацький простір NVIDIA.
Якщо ви на Intel/AMD і зовнішні роз’єми постійно показують «disconnected», можливо, вам бракує підтримки kernel modesetting або ви використовуєте старе ядро без потрібних виправлень USB-C/DP MST для вашої платформи.
Якщо монітор присутній, але ніколи не підсвічується, можливо, вам бракує прошивки (контролер Type-C, бінарні прошивки GPU) або виникають проблеми з погодженням EDID — це вже не стільки «відсутній драйвер», скільки «драйвер не може дізнатися, з ким говорити».

Операційно ставте це як граф залежностей. Ваше завдання — визначити, яку гілку ви використовуєте, і перевірити кожний компонент із доказами, а не інтуїцією.

Ось цитата, яку так часто перефразовують в оперуванні, що вона практично протокол: «Надія — це не стратегія.» (парафразована думка, яку часто приписують інженерам і військовому плануванню; широко використовується в культурі надійності)

Жарт №1: Зовнішні монітори схожі на чергування: другий з’являється лише тоді, коли ви вже спізнюєтеся.

План швидкої діагностики

Це послідовність «не ускладнюйте». Ви полюєте на вузьке місце. Починайте широко, потім звужуйте. Якщо пропустите кроки, виправите не те й будете продуктивно залишатися зламаними.

Перше: визначте транспорт (рідний HDMI/DP vs USB-C alt mode vs DisplayLink)

Шукайте ознаки DisplayLink у ідентифікаторах USB-пристроїв та логах ядра.
Перевірте DRM-конектори на предмет стану «connected/disconnected».
Підтвердіть, який GPU керує виходами (особливо на ноутбуках з гібридною графікою).

Друге: підтвердіть, що драйвер завантажений і відповідає ядру

Модуль ядра присутній? (lsmod)
Є помилки в dmesg ядра? (відсутня прошивка, не вдалося ініціалізувати, модуль позначений як tainted)
Consistent користувацький стек? (відповідність версій NVIDIA; демон DisplayLink запущений)

Третє: підтвердіть роз’єм і EDID

Чи читається EDID? (DRM sysfs). Якщо EDID порожній або є помилки, ви «нічого не виявите».
Топологія DP MST? Для доків з кількома портами MST — частий винуватець.
Погодження живлення/alt-mode? Особливості USB-C з’являються в логах як повідомлення typec/ucsi.

Правило прийняття рішення

Якщо монітор ніколи не з’являється в статусі DRM-конектора, припиняйте підлаштовувати налаштування робочого столу. Виправляйте шар транспорту/драйвера/ядра. Якщо конектор відображається як connected, але жоден режим не працює — ви в зоні EDID/modes/MST.

Факти та контекст: чому зовнішні монітори досі крихкі

Надійність зовнішніх дисплеїв мала б бути вирішена ще в 2006 році. Однак ситуація залишається складною. Декілька конкретних контекстних пунктів роблять хаос менш загадковим:

EDID існує десятиліттями (первісно спосіб VESA для моніторів описати себе). Це все ще та рука, на яку спирається ОС, і вона все ще ламається через погані кабелі та доки.
DisplayPort додав MST (Multi-Stream Transport), щоб один DP-лінк міг нести кілька дисплеїв. В теорії добре; на практиці MST-хаби та доки постійно створюють «примарні монітори» й нестабільну перелічуваність.
USB-C ускладнив «ідентичність порту»: той самий конектор може робити лише USB, USB + DP Alt Mode або Thunderbolt. Ваш кабель може підтримувати зарядку, але не DP-лінії. Це не дружня до користувача модель невдач.
Thunderbolt тунелює протоколи (PCIe, DisplayPort). Це потужно, але також означає, що прошивка, рівні безпеки та підтримка ядра можуть блокувати те, що «має просто працювати».
Гібридна графіка (iGPU + dGPU) змінила схему підключення. Багато ноутбуків маршрутизують зовнішні порти через iGPU навіть коли рендеринг робить dGPU, або навпаки. Припущення тут викликають довгі, дорогі зустрічі з відлагодження.
Wayland vs Xorg має значення: деякі вендорні інструменти та старі робочі процеси (як інтенсивні скрипти з xrandr) поводяться по-різному, і драйвери розвивалися з різною швидкістю для різних композитних серверів.
Історія драйвера NVIDIA на Linux включає переходи: legacy vs modern, інтеграцію modesetting і різну поведінку між версіями ядра. Несумісності можуть «працювати» локально, але провалюватися зовні.
DisplayLink не є «протоколом монітора»; це відео по USB зі стисненням і віртуальним пристроєм відображення. Воно може бути чудовим, але це окремий графічний шлях, що потребує власних драйверів і сервісів.

Практична карта відмов: де ламається виявлення

Коли зовнішній монітор не виявляється, правда може ховатися тільки в кількох шарах. Ось карта, яку я використовую в підтримці:

Фізичний шар: кабель, напрямок адаптера, живлення, пошкодження порту, підтримка DP-ліній у кабелі.
Погодження лінку: переговори USB-C alt mode, авторизація Thunderbolt, DP link training.
Перелічення пристроїв у ядрі: чи бачить ОС новий роз’єм/пристрій? З’являється DRM-конектор? З’являється USB-пристрій?
Прикріплення драйвера: правильний модуль ядра завантажується й прив’язується до пристрою; завантажується прошивка.
Modesetting: KMS створює фреймбуфер і список режимів. EDID розборюється.
Компонент compositing/session: Wayland/Xorg підбирає його, застосовує політику, вмикає вихід.
Користувацька політика: закрите кришка, DPMS, дисплей вимкнений, конфлікти дзеркалювання, баги фракційного масштабування.

Якщо ви ставите проблему як «мій монітор невидимий», ви будете ганятися за UI. Ставте її як конвеєр: «де сигнал обірвався?»

Практичні завдання: команди, виводи та рішення (12+)

Ці завдання припускають Linux, бо саме там «відсутній драйвер» найбуквальніший і найбільш поправний за допомогою доказів. Якщо ви на Windows/macOS, концептуальні кроки такі самі, але інструменти інші.

Завдання 1: Перевірте, що ядро думає про DRM-конектори

cr0x@server:~$ for s in /sys/class/drm/card*-*/status; do echo "$s: $(cat $s)"; done
/sys/class/drm/card0-DP-1/status: disconnected
/sys/class/drm/card0-DP-2/status: connected
/sys/class/drm/card0-HDMI-A-1/status: disconnected

Що це означає: DRM-шар ядра бачить конектори та їхній поточний стан. Якщо все disconnected при підключеному моніторі, ви знаходитеся нижче рівня композитора: кабель/порт/alt-mode/драйвер/прошивка.

Рішення: Якщо жоден конектор ніколи не змінює стан на connected, переходьте до логів USB-C/Thunderbolt/typec та перевірки драйверів. Якщо конектор connected, перейдіть до EDID і режимів.

Завдання 2: Визначте GPU(и) і який драйвер активний

cr0x@server:~$ lspci -nnk | grep -A3 -E "VGA|3D|Display"
00:02.0 VGA compatible controller [0300]: Intel Corporation TigerLake-LP GT2 [Iris Xe Graphics] [8086:9a49]
	Subsystem: Lenovo Device [17aa:XXXX]
	Kernel driver in use: i915
	Kernel modules: i915
01:00.0 3D controller [0302]: NVIDIA Corporation TU117M [GeForce GTX] [10de:1f99]
	Kernel driver in use: nvidia
	Kernel modules: nvidiafb, nouveau, nvidia_drm, nvidia

Що це означає: Ви бачите пристрої і який модуль ядра до них прив’язаний. Тут «я встановив драйвер» стає «ядро використовує драйвер».

Рішення: Якщо ви очікуєте NVIDIA, але бачите nouveau, або навпаки — виправте прив’язку. Якщо у вас гібридна графіка, з’ясуйте, який GPU володіє зовнішніми портами (часто iGPU).

Завдання 3: Підтвердіть, що модулі ядра завантажені (і не напівзавантажені)

cr0x@server:~$ lsmod | egrep 'i915|amdgpu|nvidia|nouveau|evdi|drm_kms_helper|typec|ucsi'
nvidia_drm             73728  2
nvidia_modeset       1236992  3 nvidia_drm
nvidia              62410752  89 nvidia_modeset
i915                 4128768  4
drm_kms_helper        315392  2 i915,nvidia_drm
ucsi_acpi             16384  0
typec_ucsi            49152  1 ucsi_acpi

Що це означає: Здоровий стек часто показує DRM-помічники та модуль GPU. Для DisplayLink ви очікуєте evdi. Для USB-C alt mode зазвичай видно модулі UCSI/typec.

Рішення: Відсутній модуль? Встановіть/увімкніть потрібний пакет драйвера або виправте підпис модулів при Secure Boot. Модуль присутній, але є помилки в логах? Перейдіть до dmesg.

Завдання 4: Подивіться логи ядра на помилки, пов’язані з відображенням

cr0x@server:~$ sudo dmesg -T | egrep -i "drm|edid|dp|hdmi|typec|ucsi|thunderbolt|nvidia|evdi" | tail -n 30
[Mon Feb  3 10:11:24 2026] [drm] Initialized i915 1.6.0 20201103 for 0000:00:02.0 on minor 0
[Mon Feb  3 10:12:01 2026] i915 0000:00:02.0: [drm] DP-2: EDID is invalid
[Mon Feb  3 10:12:01 2026] i915 0000:00:02.0: [drm] DP-2: DPCD: 001 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[Mon Feb  3 10:12:05 2026] ucsi_acpi USBC000:00: PPM init failed (-110)

Що це означає: Тут система признається. EDID invalid вказує на проблеми з кабелем/доком/монітором у рукопотягуванні. UCSI timeouts можуть означати проблеми з контролером USB-C або прошивкою.

Рішення: Помилки EDID → перевірте інший кабель/порт/док, потім подумайте про вимушене EDID (пізніше). UCSI помилки → оновлення BIOS/прошивки або оновлення ядра часто краще, ніж нескінченні налаштування користувацького простору.

Завдання 5: Визначте, чи маєте справу з DisplayLink (USB графіка) чи з Alt Mode

cr0x@server:~$ lsusb
Bus 002 Device 002: ID 2109:0817 VIA Labs, Inc. USB3.0 Hub
Bus 002 Device 003: ID 17e9:6012 DisplayLink USB3.0 to HDMI Adapter
Bus 001 Device 005: ID 046d:c52b Logitech, Inc. Unifying Receiver

Що це означає: Пристрій DisplayLink помітний явно. Якщо ви його бачите, шлях зовнішнього монітора, ймовірно, не DP Alt Mode — це USB-дисплей.

Рішення: Якщо DisplayLink присутній, припиніть перш за все дебаг MST. Встановіть/перевірте DisplayLink/EVDI і його сервіс. Якщо пристрій DisplayLink не з’являється, швидше за все це рідні GPU-виходи або alt mode.

Завдання 6: Перевірте модуль ядра DisplayLink/EVDI (якщо застосовно)

cr0x@server:~$ modinfo evdi | head
filename:       /lib/modules/6.5.0-21-generic/updates/dkms/evdi.ko
version:        1.14.4
license:        GPL
description:    Extensible Virtual Display Interface
author:         DisplayLink (UK) Ltd.

Що це означає: Модуль існує для вашого запущеного ядра. Якщо modinfo не вдається, у вас немає компоненту ядра, зібраного/встановленого.

Рішення: Немає модуля → встановіть правильний пакет DisplayLink або DKMS-білд; перевірте заголовки ядра. Модуль існує → підтвердіть, що він завантажений і сервіс користувацького простору працює.

Завдання 7: Перевірте, чи працює сервіс DisplayLink (якщо застосовно)

cr0x@server:~$ systemctl status displaylink-driver.service --no-pager
● displaylink-driver.service - DisplayLink Driver Service
     Loaded: loaded (/lib/systemd/system/displaylink-driver.service; enabled; vendor preset: enabled)
     Active: active (running) since Mon 2026-02-03 10:20:11 UTC; 3min ago
   Main PID: 1422 (DisplayLinkMana)
      Tasks: 18 (limit: 18912)
     Memory: 42.1M
        CPU: 1.202s

Що це означає: Для DisplayLink робочий демон — частина «драйвера». Без нього ви можете бачити USB-пристрій, але не бачити виходи дисплея.

Рішення: Якщо сервіс неактивний/завалився, перевірте логи та перевстановіть/оновіть. Якщо працює — поверніться до перевірки DRM-конекторів; виходи DisplayLink повинні з’явитися як додаткові конектори.

Завдання 8: Перевірте сесію Wayland vs Xorg (це впливає на інструменти й особливості)

cr0x@server:~$ echo $XDG_SESSION_TYPE
wayland

Що це означає: Якщо ви на Wayland, xrandr може не відображати реальність. Ви все одно можете дебажити DRM через sysfs і логи.

Рішення: Якщо вендорний інструмент очікує Xorg (деякі старіші DisplayLink-робочі процеси, деякі крайові випадки NVIDIA), розгляньте тимчасовий перехід на Xorg для діагностики — тимчасово, а не назавжди.

Завдання 9: Під Xorg перелікуйте виходи та режими за допомогою xrandr

cr0x@server:~$ xrandr --query
Screen 0: minimum 8 x 8, current 1920 x 1080, maximum 32767 x 32767
eDP-1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 309mm x 174mm
   1920x1080     60.01*+
DP-2 disconnected (normal left inverted right x axis y axis)
HDMI-1 disconnected (normal left inverted right x axis y axis)

Що це означає: X бачить той самий стан конекторів. Якщо DRM каже connected, а xrandr — disconnected, може бути невідповідність сесії/пермісій або кілька GPU з окремими провайдерами.

Рішення: Якщо xrandr показує вихід підключеним — спробуйте його ввімкнути. Якщо disconnected — повертайтеся вниз по стеку: стан конекторів ядра та логи.

Завдання 10: На гібридній графіці перевірте провайдерів і конфігурацію offload

cr0x@server:~$ xrandr --listproviders
Providers: number : 2
Provider 0: id: 0x46 cap: 0x9, Source Output, Sink Offload crtcs: 3 outputs: 4 associated providers: 1 name:Intel
Provider 1: id: 0x1f9 cap: 0x2, Sink Output crtcs: 4 outputs: 0 associated providers: 1 name:NVIDIA-G0

Що це означає: Провайдери показують, чи NVIDIA фактично надає виходи. У багатьох ноутбуках він тільки рендерить, а iGPU володіє роз’ємами.

Рішення: Якщо dGPU має нуль виходів, не чекайте, що він безпосередньо підключатиме зовнішній дисплей. Зосередьтеся на стані конектора iGPU і на USB-C DP alt mode.

Завдання 11: Прочитайте EDID безпосередньо з sysfs, коли конектор «connected», але режими не працюють

cr0x@server:~$ sudo hexdump -C /sys/class/drm/card0-DP-2/edid | head
00000000  00 ff ff ff ff ff ff 00  4c 2d fa 0a 35 31 30 30  |........L-..5100|
00000010  0c 1e 01 03 80 3c 22 78  2a ee 95 a3 54 4c 99 26  |.....<"x*...TL.&|
00000020  0f 50 54 a5 4b 00 71 4f  81 80 81 40 81 c0 95 00  |.PT.K.qO...@....|

Що це означає: Якщо ви отримуєте реальні байти EDID, монітор говорить. Якщо файл порожній або виникають помилки читання — рукопотягування не вдалось.

Рішення: EDID читається → зосередьтеся на modesetting/політиці композитора. EDID не читається → змініть кабель/док; розгляньте вимкнення MST; оновіть прошивку/ядро.

Завдання 12: Перевірте DP MST та підказки топології конекторів

cr0x@server:~$ sudo cat /sys/kernel/debug/dri/0/i915_display_info | head -n 40
CRTC info
  CRTC 0: pipe A, active=yes
Connector info
  DP-2: status: connected
    link-status: GOOD
    max bpc: 12
    has audio: yes
    EDID: yes
    MST: yes

Що це означає: debugfs може підтвердити, що MST задіяний. MST + доки + декілька моніторів — класичний кейс відмови виявлення.

Рішення: Якщо MST задіяний і нестабільний — тестуйте з одним монітором, іншим портом дока або відключіть MST, якщо платформа це дозволяє (залежить від вендора). Якщо один монітор працює, а кілька — ні, MST — підозрюваний.

Завдання 13: Перевірте авторизацію та статус Thunderbolt-пристрою (шлях Thunderbolt)

cr0x@server:~$ boltctl
 ● CalDigit TS3 Plus
   ├─ type:          peripheral
   ├─ name:          CalDigit TS3 Plus
   ├─ uuid:          00112233-4455-6677-8899-aabbccddeeff
   ├─ status:        authorized
   ├─ connected:     yes
   └─ stored:        yes

Що це означає: Безпека Thunderbolt може блокувати функціонал пристрою до авторизації. Якщо він не авторизований, тунелювання DP може ніколи не статися.

Рішення: Якщо статус не авторизований — авторизуйте його (за політикою) або налаштуйте BIOS/політику bolt. Якщо авторизований — переходьте до перевірки DRM-конекторів.

Завдання 14: Перевірте на помилки завантаження прошивки (поширено для Intel/AMD GPU)

cr0x@server:~$ sudo dmesg -T | egrep -i "firmware|failed to load|ucode|amdgpu|i915" | tail -n 20
[Mon Feb  3 10:11:23 2026] i915 0000:00:02.0: [drm] Finished loading DMC firmware i915/tgl_dmc_ver2_12.bin
[Mon Feb  3 10:11:23 2026] i915 0000:00:00.0: [drm] GuC firmware i915/tgl_guc_70.1.1.bin version 70.1.1
[Mon Feb  3 10:11:23 2026] i915 0000:00:02.0: [drm] HuC firmware i915/tgl_huc_7.9.3.bin version 7.9.3

Що це означає: Прошивка завантажується успішно. Якщо ви бачите «failed to load», ви можете отримати дивну поведінку зовнішнього дисплея, навіть якщо внутрішня панель працює.

Рішення: Відсутня прошивка → встановіть правильний пакет прошивки для вашого дистрибутива; розгляньте оновлення ядра, якщо ваше обладнання новіше за ОС.

Завдання 15: Санітарна перевірка NVIDIA (узгодженість версій драйвера)

cr0x@server:~$ nvidia-smi
Tue Feb  3 10:25:12 2026
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 550.54.14              Driver Version: 550.54.14      CUDA Version: 12.4   |
|-----------------------------------------+------------------------+----------------------|
| GPU  Name                 Persistence-M | Bus-Id          Disp.A | Volatile Uncorr. ECC |
|  0   NVIDIA GeForce GTX               Off| 00000000:01:00.0  Off  |                  N/A |
+---------------------------------------------------------------------------------------+

Що це означає: Інструмент NVIDIA у користувацькому просторі може спілкуватися з модулем ядра. Це не гарантує, що зовнішні виходи працюють, але виключає велику категорію невідповідностей.

Рішення: Якщо nvidia-smi не працює — виправте встановлення драйвера перед будь-якими іншими діями. Якщо працює, але зовнішні дисплеї не працюють — перевірте nvidia_drm modeset і сумісність з композитором.

Завдання 16: Підтвердіть, що NVIDIA DRM modesetting увімкнено (поширена «прихована відсутність драйвера»)

cr0x@server:~$ cat /sys/module/nvidia_drm/parameters/modeset
Y

Що це означає: Y вказує, що інтеграція NVIDIA з DRM KMS увімкнена. Без цього зовнішня поведінка моніторів може бути непередбачуваною, особливо з Wayland.

Рішення: Якщо N, увімкніть modesetting через параметри модуля ядра у підтримуваний вашим дистрибутивом спосіб, перезавантажтеся і перевірте статус DRM-конекторів ще раз.

Жарт №2: «Універсальний док» універсальний так само, як «універсальний пульт» — головним чином як тема для розмови.

Три корпоративні міні-історії з полів

Міні-історія №1: Інцидент через хибне припущення

У середній компанії з багатьма Linux-ноутбуками ІТ-команда стандартизувала приємний USB-C док. Закупівлям сподобалося. Він добре виглядав на столах. Дописи в службу підтримки почалися через два тижні: «зовнішній монітор не виявляється» на конкретній моделі ноутбука, але лише на одному з двох портів монітора.

Хтось зробив впевнене припущення: «USB-C — це USB-C. Док у порядку; проблема в образі ОС.» Вони відкотили оновлення робочого середовища. Без змін. Потім зафіксували версію ядра. Все ще без змін. Кількість звернень зросла, і це стало «проблемою стабільності платформи», що в корпоративній мові означає «усі тепер ходять на наради».

Справжня проблема: другий порт того дока покладався на DisplayPort MST, а шлях USB-C ноутбука проходив через певний ретаймер. Під навантаженням link training деградував і зчитування EDID час від часу не вдавалося. Внутрішній дисплей завжди працював, тому люди гналися за поведінкою віконного менеджера та налаштуваннями дисплея. Класична помилка напрямку.

Виправлення не було драматичним. Вони протестували прямий кабель USB-C-to-DP (обійшовши док) і монітор одразу перерахувався. Поміняли доки й кабелі; відмова відтворювалася тільки з тією комбінацією дока + порту. Потім оновили BIOS/прошивку і перейшли на версію ядра з виправленнями стабільності для Type-C/DP стека цієї платформи. «Єдиний відсутній драйвер» виявився «відсутньою прошивкою+поведінкою ядра, що робить драйвер надійним».

Операційний урок: не припускайте транспорт. Доведіть це. «Док» — не транспорт; це лотерейний квиток з кремнію.

Міні-історія №2: Оптимізація, що дала зворотний ефект

Інша організація мала парк робочих станцій з NVIDIA GPU. Вони хотіли швидше завантаження й менше складних частин, тож «оптимізували», видаливши «непотрібні сервіси» і обрізавши модулі ядра. Доброзичливий інженер прибрав усе, що виглядало опціональним, включно з елементами, пов’язаними з гачками дисплей-менеджера та поведінкою modesetting GPU.

Тижнями все здавалося в порядку — на одиночних моніторах. Потім команда привезла нову партію 4K-дисплеїв і кілька Thunderbolt-доків. Раптом: зовнішні дисплеї «не виявляються» або з’являються й зникають. Люди звинувачували доки. Люди звинувачували монітори. Люди звинувачували вендора GPU, що для деяких — хобі.

Корінна причина була тонкою. Система більше не завантажувала послідовно правильний шлях modesetting на ранньому етапі завантаження. Драйвер NVIDIA завантажувався, але інтеграція DRM/KMS не була увімкнена так, щоб гармонійно працювати з композитором і подіями hotplug. Ви могли рендерити й запускати compute, але конвеєр зовнішнього відображення був крихким і залежним від часу.

Відкат був болючим: повернути очікувані модулі й конфігурацію, і перестати вважати графіку «необов’язковою трубою». Час завантаження трохи виріс. Інциденти зменшилися значно. «Оптимізація» зекономила секунди й коштувала днів.

Операційний урок: оптимізації продуктивності, що видаляють «невикористане» ядро-підключення, неможливо відрізнити від саботажу, коли топологія обладнання змінюється. Зберігайте нудні сумісні компоненти, якщо немає виміряної причини їх прибирати.

Міні-історія №3: Нудна, але правильна практика, що врятувала ситуацію

Фінансова компанія підтримувала стандартний Linux-образ для тисяч користувачів. Зовнішні монітори були критичними, бо багато столів мали подвійні дисплеї для торгових інструментів. У них була нуднувата політика: сертифікаційні тести апаратури для кожної комбінації ноутбук+док+монітор, з коротким чеклистом і набором збережених логів.

Коли приходила нова модель ноутбука, вони не просто шпалили образ і сподівалися. Вони виконували чеклист: знімали dmesg, статус DRM-конекторів, lspci -nnk, перевіряли читання EDID і перевіряли сесії Wayland і Xorg, якщо підтримувалися. Якщо щось не проходило, вони відкривали кейс у вендора з конкретними доказами, а не «воно зламалося».

Через місяці оновлення ядра внесло регресію, що впливала на USB-C hotplug для тієї моделі. Користувачі швидко помітили. Але усунення було швидким, бо у них були базові знімки: «ось як виглядав стан конекторів раніше; ось як виглядає зараз; ось точний фрагмент логів ядра, де UCSI починає таймаутитися».

Вони зафіксували ядро лише для тієї моделі, розгорнули цілеспрямоване обхідне рішення і запланували контрольоване оновлення, коли виправлення з’явилося. Ніякої драми. Ніяких масових відкатів. Ніяких загальних зборів.

Операційний урок: нудне збереження базових даних перетворює суб’єктивний біль на дієве відмінювання. Це не гламурно, але і 2,000 місць з відмовою дисплеїв — теж не гламурно.

Поширені помилки: симптом → корінна причина → виправлення

Тут ми перестаємо вдавати, що всі «монітор не виявляється» — однакові. Ось повторювані випадки, які я бачу, зіставлені з конкретними виправленнями.

1) Симптом: Нічого не з’являється в налаштуваннях дисплея; DRM-конектори всі disconnected

Корінна причина: хибне припущення про транспорт (DisplayLink vs Alt Mode), пошкоджений кабель або збій переговорів USB-C alt mode.
Виправлення: запустіть lsusb для виявлення DisplayLink; перевірте статус DRM-конекторів; перегляньте dmesg на помилки UCSI/typec; протестуйте відомо робочий кабель, який явно підтримує DP Alt Mode; спробуйте інший USB-C порт, якщо є.

2) Симптом: Монітор інколи виявляється, потім зникає після suspend/resume

Корінна причина: ненадійний DP link training через док, нестабільність MST-хаба або баги драйвера в обробці hotplug.
Виправлення: оновіть BIOS/прошивку; оновіть ядро; протестуйте з вимкненим MST (або з одним дисплеєм); уникайте дешевих DP-кабелів; якщо NVIDIA — переконайтеся, що DRM modeset увімкнено і ви на драйвері, відомому своєю сумісністю з вашим композитором.

3) Симптом: DisplayLink-док з’являється в lsusb, але нових моніторів нема

Корінна причина: відсутній модуль EVDI для поточного ядра, або сервіс DisplayLink не запущений, або Secure Boot блокує модуль.
Виправлення: підтвердіть modinfo evdi і lsmod | grep evdi; перевірте systemctl status displaylink-driver.service; якщо увімкнено Secure Boot — підпишіть модуль або вимкніть Secure Boot згідно політики.

4) Симптом: DRM показує конектор «connected», але немає доступних режимів / чорний екран

Корінна причина: відмови парсингу EDID або пошкоджений EDID через док; іноді особливості HDR/DSC; іноді плутанина MST.
Виправлення: прочитайте EDID з sysfs; замініть кабель/док; спробуйте пряме під’єднання; спробуйте іншу частоту оновлення; розгляньте примусове встановлення відомого режиму в Xorg; оновіть прошивку/ядро.

5) Симптом: Система з NVIDIA; внутрішній дисплей працює; зовнішній монітор ніколи не виявляється на Wayland

Корінна причина: вимкнено NVIDIA DRM modesetting або несумісні компоненти драйвера; обмеження композитора на старих стеках.
Виправлення: перевірте /sys/module/nvidia_drm/parameters/modeset; переконайтеся, що модуль ядра і користувацький простір узгоджені; тимчасово спробуйте Xorg, щоб підтвердити апаратний шлях, а потім правильно виправте сумісність Wayland.

6) Симптом: Док має два виходи монітора; працює лише один надійно

Корінна причина: топологія MST і обмеження пропускної спроможності, або док з MST-хабом, чутливий до якості кабелю.
Виправлення: протестуйте кожен порт окремо; зменшіть частоту оновлення або роздільну здатність; використовуйте DP замість HDMI на доку, якщо підтримується; оберіть інший док, відомий кращою обробкою MST.

7) Симптом: Зовнішній монітор працює лише після перезавантаження, а не при хотплагу

Корінна причина: події hotplug не доставляються/не обробляються, або стан Type-C застрягає.
Виправлення: перевірте логи навколо часу підключення; оновіть ядро/прошивку; уникайте агресивних режимів енергозбереження; для діагностики відновіть кабель і спробуйте повний перезапуск дока й монітора.

Чеклисти / покроковий план

Чеклист A: 10-хвилинна тріаж для «не виявляється»

Підтвердіть транспорт: запустіть lsusb. Якщо з’являється DisplayLink — слідуйте шляху DisplayLink; інакше — шлях DP/HDMI/alt-mode.
Перевірте статус DRM-конекторів: якщо нічого не показує connected, зупиніться. Ви нижче рівня робочого середовища.
Перевірте прив’язку драйвера GPU: lspci -nnk. Підтвердіть правильний драйвер у використанні.
Проскануйте логи: dmesg на EDID/typec/ucsi/thunderbolt помилки.
Підтвердіть EDID, якщо підключено: hexdump sysfs EDID. Нема EDID — немає стабільних режимів.

Чеклист B: Шлях виправлення для DisplayLink-доків

Підтвердіть пристрій: lsusb показує DisplayLink ID.
Підтвердіть наявність модуля ядра: modinfo evdi.
Підтвердіть, що модуль завантажений: lsmod | grep evdi.
Підтвердіть, що сервіс працює: systemctl status displaylink-driver.service.
Перезавантажтеся після встановлення драйвера (так, справді). Стек відображення неввічливий до гарячої заміни їхніх основ.

Чеклист C: Шлях виправлення для USB-C DP Alt Mode / Thunderbolt

Перевірте відомо робочий кабель, сертифікований для відео. Багато «USB-C кабелів для зарядки» — лише для даних або недостатньо специфікації для DP-ліній.
Підтвердіть модулі typec/ucsi: lsmod | grep -E 'typec|ucsi'.
Перевірте логи UCSI/typec у dmesg на таймаути.
Якщо Thunderbolt: підтвердіть авторизацію через boltctl.
Оновіть BIOS/прошивку, якщо з’являються UCSI-помилки. Часто це найменш болюче виправлення.

Чеклист D: Шлях виправлення для проблем NVIDIA із зовнішніми моніторами

Підтвердіть завантаження драйвера: nvidia-smi працює.
Підтвердіть DRM modeset: cat /sys/module/nvidia_drm/parameters/modeset повертає Y.
Підтвердіть статус конекторів у DRM sysfs.
Якщо гібрид: використайте xrandr --listproviders (під Xorg), щоб підтвердити, який GPU володіє виходами.
Якщо Wayland проблемний: протестуйте в Xorg, щоб відокремити «драйвер vs композитор». Потім виправляйте потрібний шар.

Поширені запитання

1) Який «єдиний драйвер» найчастіше відсутній у людей?

На Linux це зазвичай один із таких: власний драйвер NVIDIA (правильно встановлений і узгоджений), стек DisplayLink/EVDI для USB-доків або новіше ядро/прошивка, що надійно підтримує ваш USB-C/DP шлях.

2) Як дізнатися, чи мій док — DisplayLink?

Запустіть lsusb. Якщо ви бачите пристрій з міткою DisplayLink або відомий vendor ID DisplayLink — ви на USB-графіці і потрібні DisplayLink/EVDI плюс сервіс.

3) Монітор підключено, але показує «No signal». Це ще драйвер?

Часто це EDID/modesetting або link training. Якщо DRM каже connected, прочитайте EDID з sysfs. Якщо EDID недійсний або відсутній, ОС не може надійно обрати режим.

4) Чому інколи зміна HDMI-кабелю «виправляє драйвер»?

Тому що справа ніколи не була в драйвері. Погані або недоспецифіковані кабелі викликають корупцію EDID, збої link training і нестабільне виявлення hotplug. Драйвер — той, хто отримує докори.

5) Чи потрібен Xorg, щоб зовнішні монітори працювали?

Ні. Але інструменти Xorg можуть бути корисні для діагностики, і деякі вендорні стеки історично краще поводилися там. Використовуйте Xorg як тестовий стенд, а не як постійний режим.

6) Чому після перезавантаження працює, а при хотплагу — ні?

Hotplug залежить від подій, що йдуть від апаратури до ядра і композитора. Доки, MST-хаби та контролери Type-C можуть застрягнути. Логи навколо часу підключення зазвичай підкажуть шар, що не впорався.

7) У мене Intel + NVIDIA. Хто контролює зовнішній порт?

Залежить від проводки ноутбука. Багато моделей маршрутизують зовнішні виходи через iGPU, навіть якщо dGPU рендерить. Використовуйте lspci -nnk і (під Xorg) xrandr --listproviders, щоб підтвердити.

8) Чи дійсно оновлення BIOS — це частина «пошуку драйвера»?

Так. USB-C alt mode і Thunderbolt залежать від прошивки. Якщо в логах видно UCSI-помилки або повторні таймаути переговорів, оновлення BIOS/прошивки часто є найшвидшим шляхом до стабільності.

9) Чи можна «примусово» змусити зовнішній монітор працювати без EDID?

Іноді, під Xorg, можна примусово задати modeline або надати EDID-оверрайд. Це тимчасове рішення, а не виправлення. В керованих середовищах це може бути прийнятним для конкретної моделі монітора, але це крихке рішення для різних доків.

10) Що зібрати перед ескалацією до вендора?

Щонайменше: lspci -nnk, вивід статусу DRM-конекторів, фрагмент dmesg навколо часу підключення, чи це DisplayLink (lsusb) та ваші версії ядра/драйверів.

Висновок: подальші кроки, що не створять проблем

Якщо ваш зовнішній монітор не виявляється, не починайте з перевстановлення робочого середовища або хаотичного перемикання налаштувань. Доведіть транспорт. Доведіть прив’язку драйвера. Потім доведіть рукопотягування. Так ви виправите правильну річ швидше і уникнете класичної регресії, коли «на моєму столі працює» стає «не працює для всіх інших».

Практичні подальші кроки:

Запустіть План швидкої діагностики в порядку і запишіть, що ви виявили на кожному шарі.
Якщо це DisplayLink — встановіть/підтвердіть EVDI + сервіс; не марнуйте час у DP/MST зоні.
Якщо це USB-C/Thunderbolt alt mode — довіряйте логам: помилки UCSI/typec зазвичай означають узгодження прошивки/ядра, а не UI.
Якщо це NVIDIA — переконайтеся, що модуль ядра, бібліотеки користувацького простору та DRM modeset узгоджені.
Після виправлення зніміть базову картину (статус конекторів, фрагмент dmesg, версії драйверів). Майбутній ви подякує нинішньому вам тихо — це найвища форма похвали в операціях.