Чому 640×480 здавався вічним: стандарти, що не відпускають

«Вічний режим»: чому 640×480 постійно перемагає

640×480 — це не просто роздільна здатність. Це перемир’я. Коли ланцюжок виводу на дисплей не може узгодитися, що саме він є, що може робити або що може інша сторона,
він відкотиться до чогось, що майже завжди працює. В продуктивності «майже завжди працює» перемагає «зазвичай більше роздільна здатність».

Стандарти не вмирають від старості. Вони вмирають, коли стають незручними. VGA ніколи не був незручним. Він був дешевим. Він був зрозумілим.
Він був сумісний із усього — від BIOS‑епохи прошивки до корпоративних KVM, що бачили більше переміщень стійок, ніж ваш старший архітектор.
У нього також є властивість, яку тихо цінують команди експлуатації: можна отримати щось на екрані навіть коли все інше палає.

Причини, через які 640×480 «перемагає», рідко стосуються смаку. Це провали у переговорі:

• EDID недоступний або йому не довіряють, тому GPU вибирає безпечний режим за замовчуванням.
• KVM або адаптер брешуть (або «допоміжно» санітизують EDID), тому ви ніколи не бачите справжніх можливостей монітора.
• Прошивка використовує консервативні шляхи GOP/legacy VGA під час завантаження, і ви це помічаєте під час роботи через віддалену консоль.
• Ядро або драйвер завантажуються пізно, тому рання консоль лишається в мінімальному режимі, поки userspace не виправить ситуацію.
• Віртуальні консолі та канал поза мережею емулять старі припущення для максимальної сумісності.

Останній пункт — те, що інженери недооцінюють: «екран», на який ви дивитесь, може не бути вашим фактичним дисплеєм.
Це може бути HTML5‑переглядач BMC, потокове KVM‑IP від IPMI, віртуальний GPU гіпервізора або пристрій захоплення, якому приємніше прикидатися 2004 роком.

Перша сувора істина: 640×480 рідко є первинною проблемою. Це діагностичний симптом, який каже «де‑небудь не вдалося встановити режим». Ваше завдання — знайти де,
а потім вирішити, чи виправляти переговори, примусово задавати режим або обійти проблему.

Короткий жарт на десерт: 640×480 — як колега, який ніколи не вчиться новим інструментам, але якось усе ще має доступ до продакшену.

Факти й історія, які пояснюють цей безлад

Кілька конкретних фактів — коротких, непоетичних і корисних — пояснюють, чому цей стандарт відмовляється виходити з ужитку.
Це не дрібниці; вони безпосередньо відображаються у режимах відмов, які ви побачите в полі.

1. VGA від IBM (1987) популяризував 640×480 як загальну, сумісну базову графіку. Індустрія скопіювала базу, бо сумісність продається.
2. VESA утворилася у 1989 щоб стандартизувати режимы і таймінги, бо вендори відсилали «майже сумісні» сигнали, що засмучували монітори.
3. VESA DDC і EDID (1990‑ті) дозволили моніторам описувати себе по I²C, щоб системи могли автоматично вибирати режими — доки кабель, KVM чи адаптер не зламає той крихітний побічний канал.
4. Режими «безпечного режиму» існують, бо режим поза діапазоном може дати відсутність зображення, що в термінах експлуатації невідмінно від «сервер помер».
5. Сервіси відео епохи BIOS підтримували VGA‑припущення в прошивці і завантажувачах; UEFI не стер ці очікування миттєво.
6. Аналоговий VGA прощає помилки якості сигналу у порівнянні з деякими цифровими тренуваннями лінку і обміном рукопотисків; «прощаючий» важливий в довгих трасах і дешевих подовжувачах.
7. Корпоративні KVM‑перемикачі історично віддавали перевагу сумісності над ідеальним пропусканням EDID. Деякі досі кешують один EDID і показують його кожному серверу.
8. HDMI→VGA адаптери — це активні конвертери, що мають прошивку. Вони можуть брехати. Багато з них постачаються з мінімальною підтримкою EDID і сумнівними таблицями таймінгів.
9. Ранній графічний вивід під час завантаження часто відбувається до повного стеку драйверів. Якщо прошивка вибирає 640×480, ви бачитимете це, поки KMS/userspace не перемодулює екран.

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

Стек стандартів: VGA, VESA, EDID, DDC, GOP, KMS

VGA: база, яку прошивка все ще розуміє

VGA — це і історія конектора, і історія сигналізації, і люди їх постійно плутають.
«VGA» може означати:

• Аналоговий RGB через DE-15 (синій роз’єм) плюс сигнали синхронізації.
• Набір режимів: канонічні таймінги, наприклад 640×480 при 60 Гц.
• Шар сумісності в прошивці: «Я завжди можу вивести текст і, можливо, пікселі.»

Чому прошивка його любить: це просто, зрозуміло і не вимагає переговорів.
Саме тому ви все ще бачите VGA‑подібну поведінку під час раннього завантаження, навіть на системах, які ніколи не мали порту DE-15.

Режими VESA і чому важливі таймінги

«Роздільна здатність» неповна без частоти оновлення і точних таймінгів. Монітори дбають про тактові частоти пікселів,
ширини синхронізації, інтервали blanking — те, про що ви не хочете думати під час відлагодження простою.
VESA створила стандартизовані формули таймінгів, щоб GPU і монітори могли узгодити, що саме означає «1024×768 @ 60» електрично.

Коли переговори режиму зазнають невдачі, системи часто вибирають консервативний встановлений таймінг: 640×480 @ 60.
Менше шансів вийти за межі діапазону, менше шансів вимагати екзотичних тактових частот і більше шансів бути в EDID навіть коли EDID неповний.

EDID і DDC: «малий провід», що вирішує ваш день

EDID (Extended Display Identification Data) — це самоопис монітора: підтримувані роздільні здатності, преференційні таймінги, ID постачальника/моделі і часом додаткові блоки для аудіо чи HDR.
Зазвичай воно передається через DDC, канал I²C, який прокладено по роз’єму дисплея.

Операційний момент: EDID — це залежність. Воно може бути відсутнє, пошкоджене, закешоване або замінене.
І системи, що від нього залежать — прошивка, ядро, Xorg/Wayland, віддалені консолі — кожна має свою поведінку відкату.

UEFI GOP проти legacy VGA

Сучасна прошивка використовує GOP (Graphics Output Protocol), щоб надати framebuffer завантажувачам.
Якщо GOP ініціалізується в низькій роздільній здатності (іноді на базі спрощеного читання EDID), ваш ранній вивід виглядатиме як музейний експонат.
Коли завантажиться ОС‑стек графіки, вона зможе перепрограмувати дисплей, але лише якщо зможе коректно прочитати можливості й застосувати підтримуваний режим.

Linux DRM/KMS: де «має просто працювати» зустрічається з реальністю

DRM/KMS (Direct Rendering Manager / Kernel Mode Setting) означає, що ядро встановлює режими дисплея рано, а не чекає userspace.
Це загалом робить процес завантаження плавнішим і уникати мерехтіння режимів.
Але це також значить, що неправильне читання EDID може заблокувати вас у режимі відкату до того, як userspace встигне це виправити.

Якщо запам’ятати одне: коли ви бачите 640×480, запитайте «який шар його вибрав?» Прошивка? Ядро? Xorg/Wayland?
Віддалена консоль? KVM? Адаптер? Ось уся інвестигація.

Цитата, бо інженерна надійність має властивість принижувати впевнені припущення:
«Надія — це не стратегія.» — Gene Kranz

Де 640×480 все ще з’являється в операціях

1) Crash cart і шухляда з «таємничим KVM»

Ви знаєте ту шухляду. З незнaченими VGA‑кабелями, DisplayPort‑адаптером від вендора, якого вже немає,
і KVM‑перемикачем, який «ще працює нормально». Саме тут EDID починає поводитися дивно.

Багато crash cart’ів включають KVM, який або кешує один EDID назавжди, або представляє загальний EDID кожній підключеній системі.
Загальний EDID часто містить консервативні встановлені таймінги, а 640×480 — найбезпечніший із безпечних.

2) Позамережеві віддалені консолі (BMC/IPMI/KVM-over-IP)

BMC часто реалізовують віртуальний графічний конвеєр, захоплюючи відеосигнал і перекодовуючи його для віддаленого перегляду.
Деякі BMC коректно обробляють лише підмножину режимів. Інші неправильно працюють із hotplug чи EDID при відкритті віддаленої консолі.

Результат: сервер локально може рендерити 1920×1080, але віддалена консоль змушує повторне виявлення,
і раптом ОС падає до 640×480, бо думає, що монітор зник.

3) HDMI/DP→VGA адаптери в конференцзалах і лабораторіях

Ці адаптери — активні пристрої. Вони мають прошивку. Вони можуть брехати. Вони також можуть «вирішувати» питання EDID, рекламуючи лише кілька режимів, щоб уникнути звернень у підтримку.
Якщо 640×480 з’являється лише коли адаптер у ланцюгу, довіряйте шаблону.

4) Headless‑системи, що прикидаються монітором

Headless‑сервери іноді потребують framebuffer для інсталяторів, для iDRAC/iLO консолей або для GPU‑обчислень.
Без фізичного монітора GPU може повідомляти «немає конекторів» або синтезувати мінімальний режим.
Плаг‑заглушка, яка дає EDID, може вирішити це миттєво — за умови, що вона видає адекватний EDID.

5) Віртуалізація і вкладені консолі

VM може використовувати віртуальний GPU з фіксованим набором режимів. Консоль гіпервізора може примусово встановлювати режим відкату.
Або ваш RDP/VNC клієнт може мати власні нюанси переговорів. Якщо ваш «монітор» — програмний переглядач,
ставтеся до нього як до KVM: він може стати найслабшою ланкою.

Швидкий план діагностики: що перевірити першим/другим/третім

Це чекліст, який я хочу бачити на стіні, коли хтось пише «консоль застрягла на 640×480» і вікно змін закривається.
Мета: визначити, чи вузьке місце в фізичному ланцюгу, EDID, прошивці, драйвері ядра або userspace.

Перше: чи ланцюг дисплея не брешe?

• Обійдіть KVM/подовжувач/адаптер. Підключіться напряму до відомого робочого монітора.
• Замість кабеля та порту поміняйте їх. Віддавайте перевагу цифровому підключенню (DP/HDMI), якщо можливо.
• Якщо віддалена консоль: спробуйте локальний монітор; якщо локально все добре, «дисплей» — це BMC‑конвеєр.

Друге: чи EDID читається і адекватний?

• На Linux перевірте стан DRM‑конектора і наявність EDID у sysfs.
• Шукайте «EDID checksum is invalid» або «failed to read EDID» у логах ядра.
• Якщо EDID відсутній: підозрюйте KVM, адаптер, довгі кабелі або проблеми з DDC‑контактом.

Третє: який шар встановив 640×480?

• Лише раннє завантаження? Це прошивка/GOP. ОС може бути в порядку після повного старту.
• Залишається низьким у графічному логіні? Драйвер ядра або вибір режиму в userspace.
• Змінюється при відкритті віддаленої консолі? Запущено hotplug/повторне читання EDID, спричинене BMC/KVM.

Четверте: вирішіть — виправляти переговори чи примусово задавати режим

• Якщо це транзиторне або залежить від ланцюга: виправте ланцюг (пропуск EDID, кращий KVM, коротша DDC‑лінія).
• Якщо це headless за задумом: використайте правильний EDID‑override або відомий dongle‑емулятор EDID.
• Якщо це одноразова система в стояку: примусове встановлення режиму може бути прийнятним, але задокументуйте це як міну.

Практичні завдання: команди, виводи та рішення, які ви приймаєте

Нижче реальні завдання, які можна виконати на Linux‑хості, щоб діагностувати і виправити проблеми класу «застрягло на 640×480».
Кожне завдання містить: команду, що означає її вивід, і яке рішення це дає. Запускайте від root, де потрібно.

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

cr0x@server:~$ ls -1 /sys/class/drm/
card0
card0-DP-1
card0-HDMI-A-1
card0-eDP-1
renderD128
version

Значення: Кожен запис card0-* — це конектор. Якщо ви не бачите очікуваного конектора, то ви не налагоджуєте «роздільну здатність» — ви налагоджуєте виявлення.

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

Завдання 2: Перевірити статус конектора (connected/disconnected)

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

Значення: Ядро бачить HDMI-A-1 як connected. Якщо воно показує disconnected, поки у вас підключено екран, то, ймовірно, ви дивитесь через віддалений/BMC‑шлях.

Рішення: Якщо статус хилиться між connected/disconnected, підозрюйте поганий кабель, поведінку hotplug KVM або енергозбереження монітора/KVM.

Завдання 3: Прочитати підтримувані режими з sysfs

cr0x@server:~$ cat /sys/class/drm/card0-HDMI-A-1/modes | head
640x480
800x600
1024x768
1280x720
1920x1080

Значення: Це те, що DRM вважає допустимим для цього конектора. Якщо видно тільки 640×480, EDID відсутній/фільтрується або драйвер перейшов на малий вбудований список.

Рішення: Якщо список режимів підозріло короткий, переходьте до перевірки EDID та логів ядра.

Завдання 4: Перевірити, чи існує EDID для конектора

cr0x@server:~$ ls -l /sys/class/drm/card0-HDMI-A-1/edid
-r--r--r-- 1 root root 256 Jan 21 10:14 /sys/class/drm/card0-HDMI-A-1/edid

Значення: EDID‑блоб існує. Це не гарантує його правильності, але це добрий знак.

Рішення: Якщо файл відсутній або його розмір 0, підозрюйте проблеми з DDC/EDID‑шляхом (KVM, адаптер, кабель).

Завдання 5: Розкодувати EDID, щоб підтвердити преференційний режим і адекватність

cr0x@server:~$ edid-decode /sys/class/drm/card0-HDMI-A-1/edid | sed -n '1,40p'
edid-decode (hex):
00 ff ff ff ff ff ff 00 4c 2d 07 0c 01 01 01 01
...
Manufacturer: SAM Model 3079 Serial Number 16843009
Made in week 1 of 2018
...
Display Product Name: S24D330
...
Preferred timing: 1920x1080p at 60 Hz

Значення: У вас є валідний EDID з преференційним таймінгом. Якщо система все одно обирає 640×480, проблема, ймовірно, у політиці вибору режиму, обмеженнях драйвера або пізнішому hotplug‑події.

Рішення: Якщо EDID показує лише низькі режими або декодується з попередженнями контрольної суми, замініть підозрілий ланцюг (KVM/адаптер) або зробіть override EDID.

Завдання 6: Пошук у логах ядра помилок EDID і modesetting

cr0x@server:~$ dmesg -T | egrep -i 'drm|edid|hdmi|dp|vga|modeset' | tail -n 20
[Tue Jan 21 10:13:02 2026] [drm] Initialized i915 1.6.0 20201103 for 0000:00:02.0 on minor 0
[Tue Jan 21 10:13:03 2026] [drm:intel_hdmi_detect [i915]] HDMI-A-1: EDID read succeeded
[Tue Jan 21 10:13:03 2026] [drm:intel_hdmi_compute_config [i915]] requested mode 640x480 rejected, falling back
[Tue Jan 21 10:13:04 2026] [drm] fb0: i915drmfb frame buffer device

Значення: Лог каже, чи вдалося прочитати EDID і чи відхилено валідацію режиму.

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

Завдання 7: Подивитися, що думає Xorg/Wayland (приклад X11 з xrandr)

cr0x@server:~$ xrandr --verbose | sed -n '1,120p'
Screen 0: minimum 320 x 200, current 640 x 480, maximum 8192 x 8192
HDMI-1 connected primary 640x480+0+0 (0x48) normal (normal left inverted right x axis y axis) 477mm x 268mm
  1920x1080 (0x4a) 148.500MHz +HSync +VSync *preferred
  1280x720  (0x4b) 74.250MHz +HSync +VSync
  640x480   (0x48) 25.175MHz -HSync -VSync

Значення: X бачить 1920×1080 як преференційний, але наразі встановлено 640×480. Це зазвичай означає політику вибору, невдалу спробу встановити преференційний режим або гонку з hotplug.

Рішення: Спробуйте переключитися на преференційний режим; якщо це не вдається, шукайте помилки драйвера та нестабільність EDID.

Завдання 8: Тимчасово примусово встановити режим (X11) для валідації можливостей

cr0x@server:~$ xrandr --output HDMI-1 --mode 1920x1080 --rate 60
cr0x@server:~$ xrandr | head -n 3
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192
HDMI-1 connected primary 1920x1080+0+0 normal (normal left inverted right x axis y axis)
DP-1 disconnected

Значення: Перемикання режиму працює в userspace. Якщо пізніше воно повертається на 640×480, щось викликає повторне виявлення (hotplug KVM, енергозбереження, відкриття/закриття віддаленої консолі).

Рішення: Якщо відбувається відкат, зосередьтесь на стабільності: відключіть проблемні події hotplug, виправте KVM або використайте override EDID.

Завдання 9: Перевірити, чи ви на шляху віртуальної консолі BMC

cr0x@server:~$ dmidecode -t system | egrep -i 'manufacturer|product'
Manufacturer: Supermicro
Product Name: X11SSH-F

Значення: Ідентифікує платформу сервера, яка, ймовірно, має BMC. Це не доказ, але підказка, що ви можете дивитися через KVM‑over‑IP зі своїми обмеженнями.

Рішення: Якщо віддалена консоль працює інакше, ніж локальний монітор, вважайте BMC частиною ланцюга дисплея і тестуйте обидва шляхи.

Завдання 10: Підтвердити, який драйвер використовується і чи активний KMS

cr0x@server:~$ lspci -k | sed -n '/VGA compatible controller/,+6p'
00:02.0 VGA compatible controller: Intel Corporation UHD Graphics 630 (Desktop)
	Subsystem: Dell Device 087c
	Kernel driver in use: i915
	Kernel modules: i915

Значення: Підтверджує драйвер ядра. Якщо ви бачите загальний драйвер (наприклад, vesa в деяких контекстах), ви можете застрягти у шляху відкату, що обмежує режими.

Рішення: Якщо правильної підтримки драйвера немає, виправте це спочатку; жоден xrandr не виправить неправильний модуль ядра.

Завдання 11: Переглянути стан дебагу DRM для підказок про валідацію режимів

cr0x@server:~$ cat /sys/kernel/debug/dri/0/i915_display_info 2>/dev/null | head -n 30
CRTC info
  CRTC 0: active yes (pipe A)
  connector HDMI-A-1: connected
    max bpc: 12
    link-status: GOOD
    modes:
      1920x1080@60
      1280x720@60
      640x480@60

Значення: Специфічний для драйвера дебаг може показати статус лінку і списки режимів, які драйвер готовий використовувати.

Рішення: Якщо link-status поганий або режими відсутні тут, але є в інших місцях, у вас проблема драйвер/тренування лінку, а не десктопного середовища.

Завдання 12: Перевірити, чи параметр завантаження ядра примусово встановлює низьку роздільну здатність

cr0x@server:~$ cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-6.5.0 root=/dev/mapper/vg0-root ro quiet splash video=HDMI-A-1:640x480@60

Значення: Хтось примусово встановив режим через video=. Це часто трапляється після «тимчасових фіксів», що стали постійними.

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

Завдання 13: Тимчасово примусово встановити відомий добрий режим з раннього етапу через DRM (тест)

cr0x@server:~$ sudo sed -i 's/^GRUB_CMDLINE_LINUX_DEFAULT=.*/GRUB_CMDLINE_LINUX_DEFAULT="quiet splash video=HDMI-A-1:1920x1080@60"/' /etc/default/grub
cr0x@server:~$ sudo update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.5.0
done

Значення: Ви наказуєте modesetting ядра вибрати конкретний режим для цього конектора.

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

Завдання 14: Зберегти EDID у файл для порівняння між кабелями/KVM

cr0x@server:~$ sudo cat /sys/class/drm/card0-HDMI-A-1/edid > /tmp/hdmi.edid
cr0x@server:~$ sha256sum /tmp/hdmi.edid
8f7c5d2b1b8a8b5e2c0c0b44f1b1c4f2a0a7b6a3c9d2a1e8d4c0f1a2b3c4d5e6  /tmp/hdmi.edid

Значення: Хеш дозволяє виявити, коли EDID змінюється між «прямим монітором» і «через KVM», що часто є суттю проблеми.

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

Завдання 15: Підтвердити, чи проблема лише в текстовій консолі

cr0x@server:~$ fgconsole
1
cr0x@server:~$ cat /sys/class/graphics/fb0/virtual_size
640,480

Значення: Ваша framebuffer‑консоль встановлена на 640×480. Графічна сесія може переключитися пізніше, але якщо ні, це натякає на те, що KMS/ранній modesetting зафіксований на низькому рівні.

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

Завдання 16: Виявити «шторм» hotplug (часто спричиняють KVM)

cr0x@server:~$ sudo journalctl -k -b | egrep -i 'hotplug|link-status|HDMI|DP|drm' | tail -n 30
Jan 21 10:21:14 server kernel: [drm] HDMI-A-1: Hotplug event received
Jan 21 10:21:15 server kernel: [drm] HDMI-A-1: EDID read failed
Jan 21 10:21:15 server kernel: [drm] HDMI-A-1: using fallback mode 640x480

Значення: Система втрачає EDID під час hotplug. Це класична поведінка KVM (або ненадійного адаптера) і пояснює «воно рандомно скидається на 640×480».

Рішення: Виправте фізичний ланцюг або використайте EDID емулятор/заглушку; не боріться з цим через десктопні налаштування.

Другий короткий жарт, і назад до роботи: EDID означає «Eventually Displays In 640×480», якщо посеред шляху поставити дешевий KVM.

Три корпоративні міні‑історії (анонімізовані, правдоподібні, технічно точні)

Міні‑історія 1: Інцидент через неправильне припущення

Середня компанія розгорнула новий «стандартний» набір crash cart’ів у кількох залах. Набір виглядав охайно:
1U‑шухляда, монітор, компактний KVM і пакет адаптерів, щоб покрити все. Він пройшов лабораторне тестування. Пройшов пілот.
Потім зустрів реальність: мікс GPU‑вендорів, версій прошивки і стійок з уже наявними KVM‑подовжувачами.

Неправильне припущення було простим: «Якщо монітор працює напряму, він працюватиме через KVM». Новий KVM кешував EDID від першого монітора,
що його побачив під час налаштування, і потім давав цей EDID кожному серверу назавжди. В одній залі перший підключений монітор був старшим пристроєм,
який рекламував мінімальний список режимів. KVM faithfully cloned ту посередність для всього вниз по ланцюгу.

Інцидент стався під час вікна обслуговування, коли інженерам потрібен був доступ до BIOS на партії серверів. Половина машин показувала лише 640×480,
і BIOS‑інтерфейс перетворився на карусельню. Інженери неправильно читали пункти меню, переключили неправильний SATA‑режим на кількох системах і спричинили уникальний каскад завантажувальних збоїв.
Нічого екзотичного не зламалося. Люди помилилися, підсилені низьким UI та стислим графіком.

Виправлення не було «поставити вищу роздільну здатність». Виправлення було операційним: стандартизувати ланцюг crash cart’а,
зафіксувати EDID KVM на відомому профілі та документувати процес очищення EDID‑кешу при заміні моніторів. І ще: перестати змішувати подовжувачі й KVM,
якщо ви не можете довести пропускання EDID скрізь. Якщо ваш ланцюг дисплея є станомим, ставтесь до нього як до продакшен‑залежності.

Міні‑історія 2: Оптимізація, що вдарила у спину

Інша організація намагалася «оптимізувати» віддалене налагодження, напхавши всіх користуватися BMC‑консолями замість принесених crash cart’ів.
План був розумним: менше рук у дата‑залі, швидша відповідь, кращі логи. Хтось помітив, що при вищих роздільних здатностях віддалений стрім пригальмовує.
Тож вони знизили графіку завантаження серверів до меншого режиму, щоб зробити потік відео легшим і «швидшим».

Це справді зробило стрім легшим. Воно також зробило інженерів сліпими. Декілька критичних операцій обслуговування залежали від читання повних рядків завантажувача і виводу kernel panic.
При 640×480 рядки оберталися непередбачувано. Люди почали копіювати неправильні параметри. Декілька машин були перезавантажені з некоректними налаштуваннями root device.
Інцидент не був драматичним; він був гіршим. Це був повільний витік часу, помилок і непотрібних перезавантажень через кілька черг чергування.

Відкат був тонким: «оптимізація» покращила одну метрику (відповідність потоку віддаленої консолі), водночас погіршивши реальну мету (успішне відновлення).
Організація оптимізувала пропускну здатність і CPU в BMC‑конвеєрі, а не людську коректність під стресом. Читабельна консоль — це функція надійності.

Вони відкотили зміну і впровадили краще рішення: зберегти читабельну роздільну здатність (зазвичай 1024×768 або 1280×1024) і зменшити навантаження кодування BMC
через налаштування, що не руйнують придатність. Також вони перевели критичні шляхи відновлення на серіал‑over‑LAN для текстового виводу — не гарно, але прогнозовано і скриптується.

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

Команда фінансових послуг мала правило, яке звучало надто консервативно: у кожній стійці має бути принаймні один відомо робочий цифровий кабель (без адаптерів),
а кожен crash cart має носити невеликий EDID‑емулятор, що рекламує перевірений набір режимів. Нікому це не подобалось. Закупівля питала, навіщо купують «дивні дрібниці».
Інженери жартували. Потім це окупилося.

Під час відключення електроенергії кілька KVM перезавантажилися в стан за замовчуванням і почали представляти загальний EDID для downstream хостів.
Частина серверів відкотилася до 640×480 під час раннього завантаження. Команда на виклику потребувала доступу до налаштувань прошивки на кількох машинах, що піднялися в деградованому режимі RAID.
Низька роздільна здатність робила UI прошивки ледь керованим через ланцюг KVM.

Замість відлагодження в моменті вони застосували нудну практику: обійшли KVM, підключили відомо‑добрий кабель, і якщо сервер був headless або вибагливий — вставили EDID‑емулятор.
Список режимів стабілізувався. UI прошивки став читабельним. Команда швидко прийняла правильні рішення.

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

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

1) Симптом: у списку режимів доступний лише 640×480

Корінна причина: EDID не читається (DDC зламано) або KVM/адаптер представляє мінімальний EDID.

Виправлення: Обійдіть ланцюг; підтвердіть наявність EDID у /sys/class/drm/*/edid. Замініть кабель/KVM/адаптер або використайте EDID‑емулятор/override.

2) Симптом: преференційний режим існує, але система завантажується та залишається на 640×480

Корінна причина: Параметри завантаження ядра примушують низький режим; userspace не виконує modeset; драйвер застряг у відкаті.

Виправлення: Перевірте /proc/cmdline. Видаліть video=...:640x480 або встановіть бажаний режим. Переконайтеся, що завантажено правильний GPU‑драйвер.

3) Симптом: роздільна здатність у порядку локально, але віддалена консоль спричиняє падіння до 640×480

Корінна причина: BMC/KVM‑over‑IP ініціює hotplug або повторне читання EDID; EDID читається з перебоями.

Виправлення: Шукайте події hotplug у journalctl -k. Стабілізуйте EDID за допомогою емулятора або налаштуйте KVM, щоб тримати EDID підтвердженим.

4) Симптом: екран стає порожнім при примусовому 1080p, але 640×480 працює

Корінна причина: Ланцюг не витримує pixel clock або таймінги (дешевий подовжувач, довгий VGA‑кабель, слабкий конвертер).

Виправлення: Виберіть проміжний режим (1024×768 або 1280×720) і замініть слабку ланку. Не примушуйте режим, що поза специфікацією ланцюга.

5) Симптом: випадкові перемикання між 640×480 і вищою роздільною здатністю

Корінна причина: Hotplug‑шторм або сон монітора викликають тимчасову втрату EDID; ненадійні DDC‑контакти в кабелі.

Виправлення: Спочатку замініть кабель. Потім приберіть KVM/подовжувач з ланцюга. Підтвердіть стабільність, порівнявши хеші EDID з часом.

6) Симптом: лише текстова консоль 640×480, графічна сесія в порядку

Корінна причина: Рання консоль зафіксована в framebuffer‑режимі, обраному прошивкою; userspace пізніше виконує modeset правильно.

Виправлення: Якщо вам важлива читабельність раннього виводу, задайте ядру параметр video= на адекватний режим або налаштуйте GOP прошивки, якщо доступно.

7) Симптом: різні сервери на одному моніторі/KVM поводяться по‑різному

Корінна причина: Різні драйвери GPU по‑різному валідують режими; версії прошивки по‑різному читають EDID; деякі драйвери суворіші щодо поганого EDID.

Виправлення: Стандартизувати версії драйверів/прошивки, де можливо. Використати override EDID, щоб усунути варіабельність, коли фізичний ланцюг фіксований.

8) Симптом: «працює після перезавантаження», але знову ламається

Корінна причина: Гонка під час завантаження: EDID не готовий під час опитування (KVM повільно стверджує DDC), тоді відкат закріплюється.

Виправлення: Оновіть прошивку/KVM. Використайте EDID‑емулятор. У деяких випадках затримка modeset або примусове встановлення режиму через параметр ядра стабілізує завантаження.

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

Покроково: виправити хост, застряглий на 640×480 без гадань

1. Визначте шлях дисплея. Локальний монітор? KVM? подовжувач? адаптер? віддалена консоль BMC? Запишіть це; не покладайтеся на пам’ять.
2. Обійдіть ланцюг. Підключіться напряму до відомого робочого монітора з відомим‑хорошим кабелем. Якщо це виправляє — припиніть звинувачувати ОС.
3. Перевірте статус конектора в sysfs. Підтвердіть «connected» і адекватний список режимів.
4. Підтвердіть наявність EDID і розкодуйте його. Підтвердіть преференційний таймінг і чистоту контрольної суми.
5. Пошукайте в логах ядра помилки EDID/modeset. Шукайте збої читання, проблеми з чексуом, відхилення режимів, hotplug‑шторм.
6. Протестуйте переключення режиму в userspace (якщо є інструменти X11). Якщо воно вдається, зосередьтесь на причині, чому воно не зберігається.
7. Стабілізуйте фізичний шар. Замініть кабель. Приберіть адаптери. Віддавайте перевагу цифровому підключенню end‑to‑end.
8. Якщо headless або залежить від KVM, використайте EDID‑емуляцію. Стабільний EDID часто найчистіше «виправлення», бо воно ремонтує переговори, а не симптом.
9. Лише потім розгляньте примусовий режим через параметри ядра чи конфіг. Документуйте це. Зробіть відкат простим.
10. Протестуйте регресії при перезавантаженні і подіях hotplug. Відкрийте/закрийте віддалену консоль, переключіть порти KVM, перезавантажте монітор. Більшість багів — у переходах.

Чекліст: що стандартизувати по всьому флоту

• Одна чи дві затверджені моделі crash cart’ів, включно з KVM і поведінкою EDID.
• Відомі‑хороші кабелі (помічені) і політика вилучення «таємничих» кабелів.
• Затверджені профілі EDID‑емуляторів для headless та віддалених консолей.
• Базова прошивка (BIOS/UEFI + BMC) і база драйверів GPU для моделей серверів.
• Задокументовані параметри ядра та політика: жодних «тимчасових» video= override без тікету і терміну дії.
• Шлях серійної консолі для критичного відновлення, коли графіка ненадійна.

Чекліст: коли допустимо примусово встановлювати роздільну здатність (а коли ні)

• Допустимо: Середовище кіоску, фіксований монітор, стабільний ланцюг, протестована поведінка при перезавантаженні.
• Допустимо: Headless‑сервер, що потребує передбачуваного framebuffer для конкретного інструменту; override EDID задокументований і контрольований версіями.
• Недопустимо: Змішане KVM‑середовище, де ланцюг змінюється; примус може створити порожні екрани під час інцидентів.
• Недопустимо: Все, що використовується для відновлення прошивки, якщо ви не протестували точний ланцюг і не маєте плана обходу.

FAQ

Чому 640×480 з’являється навіть на HDMI/DisplayPort‑системах?

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

Чи «VGA‑режим» 640×480 те саме, що використання VGA‑кабеля?

Ні. Ви можете працювати в 640×480 через HDMI, DP або віртуальну консоль. «VGA» часто означає «режим сумісної графіки», а не роз’єм DE‑15.

Який найшвидший спосіб довести, що EDID — це проблема?

Порівняйте EDID‑блоб/хеші між прямим підключенням і проблемним ланцюгом (KVM/адаптер). Якщо EDID змінюється або зникає — ви знайшли проблему.

Чому KVM‑перемикачі спричиняють це так часто?

Багато KVM або кешують EDID, або представляють загальний EDID, щоб сервери думали, що монітор завжди підключений. Такий загальний EDID може рекламувати лише консервативні режими.

Чому відкриття віддаленої консолі іноді змінює локальну роздільну здатність?

Деякі BMC ініціюють hotplug або оновлення EDID, коли сесія захоплення починається. Якщо EDID читається з помилками в той момент, ОС може відкотитися до 640×480.

Чи завжди мені примусово встановлювати вищу роздільну здатність через параметри ядра?

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

Яку роздільну здатність обрати для «безпечної, але читабельної» роботи?

1024×768 та 1280×720 — часто оптимальні варіанти для UI прошивки і віддалених консолей. Вони широко підтримуються і зазвичай читабельні, не навантажуючи слабкі ланцюги.

Як обробляти headless‑сервери, яким потрібна графіка для інсталяторів або віддаленого KVM?

Використовуйте EDID‑емулятор або перевірений override EDID, щоб система стабільно показувала адекватний список режимів. Ставте це до стандартного набору, а не як «костиль».

Чому список режимів відрізняється між sysfs, xrandr і тим, що я бачу на екрані?

Різні шари звітують різні речі: список режимів DRM у ядрі, вибір userspace‑композитора і те, що може кодувати віддалений переглядач.
Визначте, який «екран» ви насправді використовуєте.

Це переважно проблема Linux?

Ні. Linux просто показує вам більше «трубопроводу». Ті самі проблеми переговорів існують у будь‑якій ОС, бо слабка ланка часто — EDID/DDC через реальний апаратний ланцюг.

Висновок: наступні кроки, що справді знижують ризик

640×480 не вижив через сентиментальність інженерів. Воно вижило, бо сумісність — це бізнес‑вимога і функція безпеки,
і бо переговори дисплея — це розподілена система, що ховається в кабелі.

Якщо ви хочете, щоб воно перестало вас дивувати — зробіть три речі:

1. Стандартизуйте фізичний ланцюг (кабелі, KVM, адаптери) так само, як ви стандартизуєте БП і NIC.
2. Інструментуйте переговори повторюваними перевірками: статус конектора в sysfs, декодування EDID, шаблони логів ядра і виявлення hotplug.
3. Майте нудний план відступу: прямий кабель + відомо‑добрий монітор + EDID‑емулятор + серійна консоль, коли графіка перетворюється на театр.

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