Чому в X11 збивається розкладка моніторів при перемиканні входу

Чому розкладка моніторів X11 злітає після HDMI або DisplayPort

Причина в Hot-Plug Detect. Монітор коротко опускає HPD-лінію, відеодрайвер трактує це як disconnect, а потім як reconnect. Після цього прилітає RandR event, і система знову складає схему екранів.

Далі все залежить від стеку. Xorg отримує подію, display manager або desktop daemon реагує на неї, а модуль керування дисплеями застосовує нову конфігурацію. Саме тому проблема не прив’язана до одного дистрибутива. Вона сидить нижче.

У MATE це часто робить плагін xrandr у mate-settings-daemon. В інших DE логіка схожа, хоча назви компонентів відрізняються. Нетривіальний момент тут такий: сама подія hotplug часто нормальна, а шкоду приносить не драйвер, а агресивна автоперебудова після неї.

Найстабільніший варіант – autorandr

Якщо потрібна стабільна розкладка моніторів X11, простіше не глушити подію, а щоразу перевиставляти правильний layout. Для цього підходить autorandr. Пакет зберігає профіль екранів і перевикликає його після зміни стану DRM.

Суть підходу проста: спочатку руками виставляється правильна схема екранів, далі вона зберігається як профіль. Після hotplug autorandr намагається повернути саме її. Для більшості X11-конфігурацій це надійніше, ніж спроби заборонити саму подію.

1. Встановити autorandr.
2. Виставити монітори як треба через xrandr, arandr або GUI DE.
3. Зберегти профіль.
4. Призначити його профілем за замовчуванням.

sudo pacman -S autorandr
autorandr --save desk
ln -s desk ~/.config/autorandr/default

На Nvidia тут є окрема умова: повинен працювати DRM modeset. Якщо він вимкнений, udev-події можуть не доходити як слід, і профіль буде застосовуватись через раз або не застосовуватись взагалі.

cat /sys/module/nvidia_drm/parameters/modeset

Потрібне значення – Y. Якщо там N, додають параметр ядра:

nvidia-drm.modeset=1

Коли autorandr спрацьовує нестабільно

Якщо розкладка моніторів X11 відновлюється не кожного разу, проблема часто в таймінгу. udev-подія приходить раніше, ніж xrandr знову бачить монітор доступним. У такій схемі профіль застосовується занадто рано.

Практичний обхідний шлях – predetect-скрипт із короткою затримкою в каталозі ~/.config/autorandr/. Досить sleep 1, інколи трохи більше. Це не витончений фікс, зате для примхливих дисплеїв або повільного DP-handshake працює краще за будь-яку “чисту” теорію.

#!/bin/sh
sleep 1

Саме тут часто видно межу підходу: на простому desktop setup усе працює відразу, а з кількома моніторами, KVM або телевізором на HDMI доводиться ловити затримку вручну.

Опція Nvidia: вимкнути hotplug для HDMI/DVI

На пропрієтарному драйвері Nvidia можна заборонити повідомлення про hotplug для окремих сценаріїв. Це допомагає, коли проблему стабільно створює HDMI- або DVI-монітор. Для DisplayPort цей трюк не рятує.

Section "Device"
    Identifier "nvidia"
    Driver "nvidia"
    Option "UseHotplugEvents" "false"
EndSection

Опцію треба додавати в наявну секцію Device для Nvidia. Створювати другу таку саму секцію з тим самим Identifier – погана ідея. Xorg може взяти будь-яку, а може взагалі не стартувати нормально.

Є й побічний ефект. Після вимкнення UseHotplugEvents Xorg перестає коректно бачити реальне відключення цього монітора до перезапуску X-сесії. Для стаціонарного робочого місця це терпимо. Для стенду, де кабелі й входи часто міняються, вже ні.

Якщо MATE перебудовує екрани поверх фікса

У MATE окремим джерелом проблеми буває xrandr-плагін у settings daemon. Якщо hotplug уже оброблено, а MATE знову перераховує схему, можна вимкнути саме цю реакцію. Це додатковий захід, не основний.

gsettings set org.mate.settings-daemon.plugins.xrandr active false

Після цього MATE перестане автоматично керувати моніторами. Мінус очевидний: новий дисплей або реальна зміна конфігурації теж не підхопляться автоматично. Для статичної multi-monitor конфігурації це нормально. Для часто змінюваного desktop setup – сумнівно.

Жорстка прив’язка EDID для впертих DisplayPort-моніторів

Коли DisplayPort-монітор все одно губиться, лишається грубіший спосіб – змусити драйвер вважати дисплей підключеним постійно через збережений EDID. Підхід робочий, але ризикований: помилка в імені виходу або файлі EDID легко закінчується чорним екраном.

Option "ConnectedMonitor" "DFP-2"
Option "CustomEDID" "DFP-2:/etc/X11/edid-dell.bin"

EDID можна зняти через nvidia-settings. Перед таким налаштуванням варто мати резервну копію X-конфіга і доступ через TTY або SSH. Для homelab-стендів без out-of-band доступу це взагалі останній варіант, а не перший.

Як перевірити, що розкладка моніторів X11 більше не збивається

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

1. Виставити правильний layout.
2. Перемкнути вхід монітора на інше джерело.
3. Повернутись назад.
4. Перевірити позиції екранів, primary display і роздільну здатність.
5. Повторити кілька разів підряд.

Для додаткової перевірки можна подивитися, як X11 бачить дисплеї після повернення:

xrandr --query

Якщо список виходів стабільний, primary не перескакує, а профіль повертається після кожного hotplug – фікс спрацював.

Що вибрати в реальній системі

У більшості випадків розкладка моніторів X11 найкраще лікується через autorandr. Для HDMI/DVI на Nvidia інколи простіше спрацьовує UseHotplugEvents “false”. Якщо проблему добудовує MATE, доводиться ще й вимикати його xrandr-плагін.

Якщо конфігурація складніша – кілька GPU, KVM, AV-ресивер або каскад із перехідників – причина майже завжди в гонці подій, а не в “кривому X11” загалом. Тут уже важливі не красиві налаштування, а передбачуваність після reconnect.