3

Я только что установил коробку Debian Wheezy (Debian 7.0rc1). По умолчанию консоль отображается с использованием буфера кадров, и из-за определенной аппаратной настройки я не буду вдаваться в подробности, на моем дисплее это выглядит слишком широко, например, самый левый столбец консоли не отображается.

Есть ли способ сделать консоль на один или два столбца уже? Я имею в виду, я не хочу делать шрифт более узким или широким, я хочу, чтобы столбцы были одинаковой ширины, и чтобы весь отображаемый экран консоли занимал меньшую ширину, но центрировался одинаково.

Обновление: на основании ответа @ mr.spuratic я установил и попытался использовать fbset ; который не делает именно то, что я просил, но теоретически может помочь мне преодолеть проблему. Во всяком случае, когда я пытаюсь установить режим с ним я получаю:

fbset FBIOPUT_VSCREENINFO: invalid argument

Заметки:

  • Я хотел бы найти решение как через настройку grub, так и на лету с консоли после загрузки.
  • Если вам нужна дополнительная информация, чтобы предоставить решение, прокомментируйте и спросите.

2 ответа2

1

Мне было интересно, где разместить этот кусок текста. Собственный веб-сайт является возможным кандидатом, или найдите какую-нибудь ветку на superuser.com, которая ближе всего подходит к моей теме (и, возможно, помогла мне). Вот как я сюда попал :-)

Моя конкретная проблема заключалась в том, как принудительно включить определенный видеорежим в мои текстовые консоли. Настройка системы: Debian 9 Stretch на аппаратном обеспечении Haswell, его IGP обрабатывается драйвером i915 в Linux (теперь уже довольно давно поддерживает KVM и DRI/DRM). Какой-то глупый аналоговый KVM-переключатель, сообщающий ПК через DDC/EDID, что максимальное разрешение было 1600x1200, но на самом деле он питает ЖК-дисплей с разрешением 1280x1024 :-)

Я начал играть с vbetool и fbset , которые, тем не менее, устарели / непригодны для этой цели, потому что они несовместимы с KMS+DRM. "Inteldrmfb" кажется просто оболочкой для KMS+DRM (и, похоже, не реализован в собственном модуле ядра). Параметры геометрии доступны только для чтения. Ну, по крайней мере, fbset может пассивно отображать активное разрешение, которое имеет некоторую информационную ценность.

Тем не менее, представляется, что у нас с вами есть возможность установить разрешение и частоту обновления кадров AKA по вертикали из командной строки ядра (параметры начального загрузчика в строке, начинающейся с "linux", которая находится в конце современного многострочный раздел grub.conf).

Вы можете поиграть с параметрами во время загрузки, если вы нажмете e когда Grub будет отсчитывать время ожидания. Следуйте за помощью оттуда. Когда вы будете довольны своими изменениями, нажмите Ctrl+X или F10, чтобы загрузить измененный профиль. (Ваши изменения эфемерны - они будут отображаться в /proc /cmdline в вашем работающем ядре при этой загрузке, но не будут записаны в grub.conf.) Для постоянного хранения ваших дополнительных параметров загрузки (аргументы cmdline ядра) в Debian вы должны ввести их в /etc/default/grub , в переменную с именем GRUB_CMDLINE_LINUX_DEFAULT . И запустите update-grub .

Теперь о аргументах. Во-первых, вам нужно i915.modeset=1 (при условии, что ваша графическая подсистема является Intel IGP). Если вы страдаете от той же проблемы, что и я, то есть то, что ядро устанавливает слишком высокое разрешение, скорее всего, у вас уже установлен modeset = 1 (скомпилированный в ядре). Пока вы боретесь с синтаксисом проклятий cmdline, и иногда вам нужен просто какой-нибудь рабочий графический режим, вы можете попробовать i915.modeset=0 . Это, по-видимому, полностью предотвращает изменения графического режима, и у вас остается почти классическая консоль 80x25 символов, вплоть до входа в консоль. Вы также заметите, что в dmesg нет /dev /fb0 и отладочных сообщений DRM (подробности читайте дальше).

Также обратите внимание на вариант quiet . Это работает с или без настройки режима. Очевидно, что он предотвращает печать сообщений ядра на вашу консоль (/dev/tty) = вы получаете пустой темный экран в течение нескольких секунд, а затем вас приветствует приглашение для входа в систему. Это значение по умолчанию в Debian. (На самом деле в современном Debian с systemd вы, вероятно, получаете на экране загрузочные сообщения systemd вместо журнала ядра ...) Дело в том, что если вы хотите вернуть сообщения ядра, вы просто должны удалить слово "quiet" из командной строки ядра и использовать эту командную строку только для одной загрузки (нажмите "e" в Grub, edit, ctrl+x продолжить) или навсегда (отредактируйте /etc /default /grub && update-grub).

Теперь, наконец, к сути: если у вас есть i915.modeset=1 , вам также нужно добавить video=<xres>x<yres>@framerate . Например, в моем случае video=1280x1024@60 или video=1024x768@60 . Существуют и другие возможные варианты, см. Соответствующую главу в Arch wiki . Например, вы также можете указать глубину цвета или применить режим только к одному порту видеовыхода (так называемый "разъем" в кишках DRM). Обратите внимание, что указанный вами режим, вероятно, должен соответствовать одному из режимов, известных ядру, то есть одному из "EDID modelines". Ядро хранит список этих блоков данных, полученных либо через DDC с монитора, либо из /lib /firmware, либо, возможно, скомпилированных в. То есть, вы не можете указать какую-либо нечетную геометрию.

В некоторых документах вы найдете только video=<xres>x<yres> , например video=1024x768 . Это имеет желаемый эффект в том смысле, что разрешение действительно появляется на выходе - но вы позволили решать вопрос о частоте кадров до драйверов, которые стремятся выбрать максимально возможную частоту кадров (среди "линий режима", доступных в набор блоков EDID). Например, в моем случае оказалось, что драйвер выбрал 1024x768@85 , что было бы хорошим выбором еще в эпоху ЭЛТ, но крайне недоступно для многих современных ЖК-дисплеев. Обратите внимание, что дешевые современные ЖК-дисплеи (до FreeSync) обычно используют частоту кадров 60 Гц, так что это то, что вам нужно установить явно, если ваш DDC отсутствует или помешан.

Во время поиска некоторых ответов я все время спотыкался о ссылках на этот патч, установленный Дейвом Эйрли - который приводит к обработке аргумента video = cmdline. Оказывается, это было объединено с ванильным Linux несколько лет назад.

В моем случае монитор работал с разрешением 1600x1200 и показывал "вне диапазона", потому что он не мог справиться. Когда я пробовал различные аргументы cmdline, я пробовал просто video=1024x768 , что приводило к "выходу за пределы диапазона" на мониторе. Внешне, из-за смутного сообщения об ошибке, казалось, что аргумент cmdline никак не влиял. Только позже я узнал, что мне не хватало суффикса @60 :-)

Интересное здесь то, как я узнал. Есть другой аргумент cmdline ядра, который заставляет подсистему DRI/DRM печатать более болтливый журнал отладки:

версия ядра ниже 4.1:

drm.debug=0xe

версия ядра 4.1 или новее:

drm.debug=0x1e log_buf_len=1M

(источник)

Я прилагаю пример журнала отладки с моей машины. На что следует обратить внимание (ключевые слова для поиска): Kernel command line , cmdline , adjusted mode , [drm:

"Имена соединителей" можно найти здесь:ls /sys/class/drm/ и обратите внимание, что синтаксис arg video = ... cmdline не принимает префикс «card-», который можно увидеть в /sys /class / др. Синтаксис video = и имен коннекторов подробно описан в соответствующей главе вики Arch Linux.

Теперь позвольте мне переключить передачи / немного изменить тему.

Первоначальный вопрос в этой теме был о том, как изменить геометрию режима видео. Я делал это раньше в X и в Windows (используя позднюю версию Intel IEGD). В Linux под kvm+drm, единственный способ настроить геометрию и синхронизацию - это, по-видимому, передать свой собственный файл EDID, который вы сначала должны изготовить вручную. Ну, почти.

Конструкция EDID кратко описана в одном фрагменте документации, включенной в исходный код ядра vanilla.

Makefile и примерные определения EDID находятся в своем родительском каталоге.

Выберите некоторые.Например, скопируйте в свой собственный файл (см. Соглашение об именах в верхней части Makefile), отредактируйте время, соберите двоичный файл EDID и ... надеюсь, это решит вашу проблему :-)

Время / количество пикселей требуют математики, чтобы получить правильные значения. И есть несколько альтернативных исторических стандартов, которых вы должны придерживаться и которые конфликтуют друг с другом (это этапы эволюции стандартов синхронизации отображения):

  • CRT-эра GTF ,
  • ЖК-эра DMT или CVT ,
  • а затем CVT-RB (уменьшенное гашение).
Либо вы можете рассчитать числа вручную, либо есть некоторые инструменты и таблицы стандартных режимов. Попробуйте поискать "EDID калькулятор" или "Modeline Calculator" или что-то подобное. Для этой работы есть даже отличный инструмент командной строки Linux . Смотрите также базу данных modeline .

Ваша конкретная проблема может быть решена путем смещения импульса HSYNC вправо (вы также можете попробовать изменить его полярность), или сделав импульс синхронизации и / или общее время гашения относительно более широким, или (как вы предложили), уменьшив видимое / отображаемое разрешение в пикселях (кратно 8). Если вы делаете гашение шире, вам может потребоваться увеличить тактовую частоту пикселей, чтобы сохранить исходную частоту кадров.

0

Обычно автоматическая настройка монитора решает эту проблему, и зачастую это гораздо меньше хлопот, чем программные решения.

В противном случае, проверьте меню информации о мониторе, чтобы увидеть, какое разрешение / обновление оно выполняет, а затем найдите модель монитора и fbset который является инструментом, используемым для установки таймингов низкого уровня, которые управляют таймингами дисплея.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .