GOP и simpledrm: раннее разрешение экрана при загрузке

15.09.2026 · ~4 минут чтения

Раннее разрешение экрана (меню загрузчика, текст ядра, промпт LUKS) задаёт прошивка UEFI через GOP (Graphics Output Protocol). Если монитор не успевает отдать EDID по HDMI до старта прошивки, прошивка выставляет 1024x768, и драйвер simpledrm наследует этот режим. Надёжных рычагов управления GOP из самой операционной системы нет.

Что такое GOP и при чём тут simpledrm

GOP, или Graphics Output Protocol, часть UEFI-спецификации. До передачи управления ядру Linux работает с видеовыходом только через этот протокол. Прошивка опрашивает монитор (EDID), определяет нативное разрешение, выставляет framebuffer нужного размера.

После передачи управления ядру на короткий период поднимается драйвер simpledrm. Это обёртка над тем же framebuffer, который уже настроила прошивка. Простой драйвер не меняет разрешение, он просто наследует то, что есть.

Когда загружается полный KMS-драйвер (amdgpu, i915, nouveau), он берёт управление и переключает на нативный режим. Но до этого момента всё, что видит пользователь, зависит только от прошивки.

Почему именно 1024x768 вместо нативного

На части плат с HDMI подключением монитор не успевает ответить на запрос EDID в отведённое прошивкой время. Результат: прошивка не знает нативное разрешение и ставит безопасный fallback, 1024x768.

Проблема конкретная: не все порты одинаковы, не все мониторы одинаковы, не все прошивки одинаковы. На одном и том же железе через DisplayPort может работать нативно, а через HDMI будет 1024x768.

Как проверить текущее разрешение на этапе simpledrm

Первое, что стоит сделать, посмотреть, какой режим реально активен на раннем этапе:

journalctl -b -k --no-pager | grep 'frame buffer device'

В выводе simpledrm: строка 128x48 означает 1024x768, а 240x67 приблизительно 1920x1080. Числа символьные, пересчитываются через отношение стандартных шрифтов консоли.

Дополнительные команды диагностики:

# Проверить, какой initrd лежит в UKI
sudo objcopy -O binary --only-section=.initrd /boot/EFI/Linux/arch-linux.efi /tmp/x.cpio
lsinitcpio -l /tmp/x.cpio ; rm -f /tmp/x.cpio

# Посмотреть EFI-переменную консольного режима
efivar -l | grep -i consolemode

Переменная LoaderConfigConsoleMode может перекрывать настройки из loader.conf. Если она существует, обрати внимание на её значение.

Что НЕ помогает: проверено на практике

Вот что я пробовал и что не дало результата:

1. Параметр console-mode max в конфиге systemd-boot. Не помогает, проверено ребутом. Этот параметр влияет на режим консоли, а не на этап GOP/simpledrm.

2. Параметр video=HDMI-A-1:1920x1080@60 в cmdline ядра. Не помогает: параметр video= влияет на выбор режима KMS-драйвером, но к этапу firmware GOP и simpledrm он ещё не имеет отношения.

3. MODULES=(amdgpu) в /etc/mkinitcpio.conf. Не влияет на этап simpledrm. Драйвер amdgpu поднимается позже, когда ядро уже передало управление framebuffer.

4. Крупный консольный шрифт через хук consolefont. Визуально хуже: глифы растягиваются по уже убийственной 1024x768 сетке.

Ловушка с хуком consolefont

Если используешь UKI и хук consolefont в mkinitcpio, обрати внимание: хук кладёт шрифт в образ под именем /consolefont.psf, а не ter-*.psf.gz. Если проверяешь наличие шрифта через lsinitcpio -l или objcopy, grep по оригинальному имени ложно покажет, что шрифта нет.

# Правильная проверка
lsinitcpio -l /tmp/x.cpio | grep console
# Не так:
lsinitcpio -l /tmp/x.cpio | grep ter-

Что реально можно попробовать

Самый честный ответ: изнутри ОС надёжных рычагов нет. Вот варианты за пределами Linux:

• Попробовать другой порт HDMI на плате. Некоторые встроенные HDMI-контроллеры ведут себя иначе.
• Включить/выключить CSM в BIOS. Режим совместимости может повлиять на то, как прошивка опрашивает монитор.
• Обновить UEFI. Производители иногда чинят timing EDID-запросов. Гарантий, что поможет, нет.
• Переключиться на DisplayPort или DVI. На этих интерфейсах EDID-опрос работает надёжнее.

Если ни один из вариантов не подходит, 1024x768 на раннем этапе просто приходится принять. Нативное разрешение появится сразу после загрузки amdgpu.

Частые вопросы

Влияет ли раннее разрешение на работоспособность системы?

Нет. 1024x768 на этапе загрузки и LUKS-промпта влияет только на эстетику. После поднятия amdgpu всё переключается на нативный режим.

Можно ли задать разрешение через video= в cmdline?

Нельзя. Параметр video=HDMI-A-1:1920x1080@60 влияет на выбор режима драйвером KMS, а GOP и simpledrm работают до этого этапа.

Поможет ли console-mode max в loader.conf?

Нет, проверено. Параметр влияет на размер текстового буфера консоли, а не на framebuffer, настроенный прошивкой.

Стоит ли включать MODULES=(amdgpu) в mkinitcpio?

Для ускорения поднятия KMS после передачи управления ядру, да. Но на этап simpledrm это не влияет: ранний framebuffer наследуется от GOP, а не от драйвера amdgpu.

Почему на DisplayPort всё нормально, а на HDMI 1024x768?

Это особенность конкретной платы и прошивки. DisplayPort обычно опрашивает EDID быстрее и надёжнее, чем HDMI.

Заключение

Раннее разрешение при загрузке Arch Linux с UKI определяется исключительно прошивкой UEFI и тем, как быстро монитор отвечает на EDID-запрос. Никакие параметры cmdline, хуки mkinitcpio или EFI-переменные не дают надёжного контроля над GOP. Если проблема существует, выход за пределами ОС: другой кабель, другой порт, обновление BIOS, CSM. В остальном, после поднятия amdgpu нативное разрешение появляется само, и система работает полноценно.

Полезные ресурсы

• mkinitcpio — ArchWiki — генерация initrd и настройка хуков
• Unified Kernel Image (UKI) — ArchWiki — сборка UKI и структура EFI-образа
• Чек-лист по установке Arch Linux — если только начинаешь путь с Arch
• Драйвер NVIDIA в Arch Linux — настройка KMS-драйвера после загрузки ядра

Читайте также

• Установка Arch на внешний SSD: обход запрета USB-boot
• Один EFI-раздел для дуалбута: правильное монтирование ESP
• Быстрая установка через archinstall: за и против