- Kernel mode setting
- Contents
- Background
- Installation
- Late KMS start
- Early KMS start
- Troubleshooting
- My fonts are too tiny
- Problem upon bootloading and dmesg
- Forcing modes and EDID
- Forcing modes
- Disabling modesetting
- Kernel mode setting (Русский)
- Contents
- История
- Установка
- Поздний запуск KMS
- Ранний запуск KMS
- Устранение неполадок
- Мои шрифты слишком маленькие
- Проблемы во время загрузки и dmesg
- Принудительный режим и EDID
- Отключение modesetting
- Графическая среда Linux без единого разрыва
- Атомарная смена режима видео
Kernel mode setting
This article or section needs expansion.
Kernel Mode Setting (KMS) is a method for setting display resolution and depth in the kernel space rather than user space.
The Linux kernel’s implementation of KMS enables native resolution in the framebuffer and allows for instant console (tty) switching. KMS also enables newer technologies (such as DRI2) which will help reduce artifacts and increase 3D performance, even kernel space power-saving.
Contents
Background
Previously, setting up the video card was the job of the X server. Because of this, it was not easily possible to have fancy graphics in virtual consoles. Also, each time a switch from X to a virtual console was made ( Ctrl+Alt+F2 ), the server had to give control over the video card to the kernel, which was slow and caused flickering. The same «painful» process happened when the control was given back to the X server ( Alt+F7 when X runs in VT7).
With Kernel Mode Setting (KMS), the kernel is now able to set the mode of the video card. This makes fancy graphics during bootup, virtual console and X fast switching possible, among other things.
Installation
At first, note that for any method you use, you should always disable:
- Any vga= options in your bootloader as these will conflict with the native resolution enabled by KMS.
- Any video= lines that enable a framebuffer that conflicts with the driver.
- Any other framebuffer drivers (such as uvesafb).
Late KMS start
Intel, Nouveau, ATI and AMDGPU drivers already enable KMS automatically for all chipsets, so you need not install it manually.
The proprietary NVIDIA driver supports KMS (since 364.12), which has to be manually enabled.
Early KMS start
KMS is typically initialized after the initramfs stage. However it is possible to already enable KMS during the initramfs stage. Add the required module for the video driver to the MODULES array in /etc/mkinitcpio.conf :
- amdgpu for AMDGPU, or radeon when using the legacy ATI driver.
- i915 for Intel graphics.
- nouveau for the open-source Nouveau driver.
- mgag200 for Matrox graphics.
- Depending on QEMU graphics in use: virtio-gpu for VirtIO, qxl for QXL, or cirrus for Cirrus.
- nvidia nvidia_modeset nvidia_uvm nvidia_drm for nvidia driver. See NVIDIA#DRM kernel mode setting for details.
For example to enable early KMS for the Intel graphics driver:
If you are using a custom EDID file (not applicable for the built-in resolutions), you should embed it into initramfs as well:
Troubleshooting
My fonts are too tiny
See Linux console#Fonts for how to change your console font to a large font. The Terminus font ( terminus-font ) is available in many sizes, such as ter-132n which is larger.
Alternatively, disabling modesetting might switch to lower resolution and make fonts appear larger.
Problem upon bootloading and dmesg
Polling for connected display devices on older systems can be quite expensive. Poll will happen periodically and can in worst cases take several hundred milliseconds, depending on the hardware. This will cause visible stalls, for example in video playback. These stalls might happen even when your video is on HDP output but you have other non HDP outputs in your hw configuration. If you experience stalls in display output occurring every 10 seconds, disabling polling might help.
If you see an error code of 0x00000010 (2) while booting up, (you will get about 10 lines of text, the last part denoting that error code), use:
Forcing modes and EDID
If your native resolution is not automatically configured or no display at all is detected, then your monitor might send none or just a skewed EDID file. The kernel will try to catch this case and will set one of the most typical resolutions.
In case you have the EDID file for your monitor you merely need to explicitly enforce it (see below). However most often one does not have direct access to a sane file and it is necessary to either extract an existing one and fix it or to generate a new one.
Generating new EDID binaries for various resolutions and configurations is possible during kernel compilation by following the upstream documentation (also see here for a short guide). Other solutions are outlined in details in this article. Extracting an existing one is in most cases easier, e.g. if your monitor works fine under Windows you might have luck extracting the EDID from the corresponding driver, or if a similar monitor works which has the same settings you may use get-edid from the read-edid package. You can also try looking in /sys/class/drm/*/edid .
After having prepared your EDID place it in a folder, e.g. called edid under /usr/lib/firmware and copy your binary into it.
To load it at boot, specify the following in the kernel command line:
For kernels older than 4.13, use this line instead:
In order to apply it only to a specific connector use:
For the built-in resolutions, refer to the table below. The Name column specifies the name which one is supposed to use in order to enforce its usage.
Resolution | Name |
---|---|
800×600 | edid/800×600.bin |
1024×768 | edid/1024×768.bin |
1280×1024 | edid/1280×1024.bin |
1600×1200 (kernel 3.10 or higher) | edid/1600×1200.bin |
1680×1050 | edid/1680×1050.bin |
1920×1080 | edid/1920×1080.bin |
If you are doing early KMS, you must include the custom EDID file in the initramfs, otherwise you will run into problems.
The value of the drm.edid_firmware parameter may also be altered after boot by writing to /sys/module/drm/parameters/edid_firmware :
This will only take affect for newly plugged in displays, already plugged-in screens will continue to use their existing EDID settings. For external displays replugging them is sufficient to see the effect however.
Since kernel 3.15, to load an EDID after boot, you can use debugfs instead of a kernel command line parameter if the kernel is not in lockdown mode. This is very useful if you swap the monitors on a connector or just for testing. Once you have an EDID file as above, run:
Forcing modes
A mode can be forced on the kernel command line. Unfortunately, the command line option video is poorly documented in the DRM case. Bits and pieces on how to use it can be found in
- https://cgit.freedesktop.org/nouveau/linux-2.6/tree/Documentation/fb/modedb.txt
- https://cgit.freedesktop.org/nouveau/linux-2.6/tree/drivers/gpu/drm/drm_fb_helper.c
- : Connector, e.g. DVI-I-1, see /sys/class/drm/ for available connectors
- x : resolution
- M : compute a CVT mode?
- R : reduced blanking?
- — : color depth
- @ : refresh rate
- i : interlaced (non-CVT mode)
- m : margins?
- e : output forced to on
- d : output forced to off
- D : digital output forced to on (e.g. DVI-I connector)
You can override the modes of several outputs using video= several times, for instance, to force DVI to 1024×768 at 85 Hz and TV-out off:
To get the name and current status of connectors, you can use the following shell oneliner:
Disabling modesetting
You may want to disable KMS for various reasons. To disable KMS add nomodeset as a kernel parameter. See Kernel parameters for more info.
Источник
Kernel mode setting (Русский)
Эта статья или раздел нуждается в переводе
Kernel Mode Setting (KMS) представляет собой метод для задания разрешения дисплея и глубины в пространстве ядра, а не в пространстве пользователя.
Реализация KMS в ядре Linux активирует родное расширение в framebuffer и допускает мгновенное переключение консолей (tty). KMS содержит новые технологии (такие как DRI2) которые помогают снизить количество артефактов и увеличить производительность в 3D, даже при включенном режиме энергосбережения.
Contents
История
Ранее настройками видео карты занимался непосредственно X сервер. По этой причине достигнуть высокого качества графики в tty консолях было непросто. Кроме того, каждый раз при переключении из X в виртуальную консоль с помощью комбинации клавиш ( Ctrl+Alt+F1 ) сервер должен был передавать управление видеокартой ядру, что было медленным и вызывало мерцания. Особенно «болезненным» был переход управления обратно к X серверу ( Ctrl+Alt+F7 ).
С использованием Kernel Mode Setting (KMS) ядру стала доступна установка режимов видео карты. Наряду с другими достоинствами это улучшает визуальные эффекты при установке параметров графики, а также позволяет быстрее переключаться между виртуальными консолями и X.
Установка
Обратите внимание — для любых используемых Вами методов необходимо всегда отключать:
- Любые vga= режимы в загрузчике, так как это вызовет конфликт с разрешением, активированным в KMS.
- Любые video= строки, активирующие framebuffer, что вызовет конфликт с драйвером.
- Любые другие драйвера framebuffer (такие как uvesafb).
Поздний запуск KMS
Драйвера Intel, Nouveau и ATI уже активируют KMS автоматически для всех чипсетов, так что не требуется ручной настройки.
Проприетарные драйвера NVIDIA и AMD Catalyst не используют стек свободных драйверов. В случае использования KMS необходимо заменить ими свободные драйвера.
Ранний запуск KMS
Ранний запуск KMS возможен во время процесса загрузки путём добавления модуля radeon (для ATI/AMD карт), i915 (для графики Intel) или nouveau (для карт Nvidia) в строку MODULES в /etc/mkinitcpio.conf . Например:
Если Вы используете изменённый файл EDID (не совпадающий с преднастроенными разрешениями), следует встроить его в initramfs:
Пересоберите образ ядра (смотрите статью о mkinitcpio для получения дополнительной информации):
Устранение неполадок
Мои шрифты слишком маленькие
Смотрите статью Fonts о том, как изменить шрифт в консоли на более крупный. Например, шрифт Terminus ( terminus-font ) доступен в нескольких размерах, в том числе и в больших.
Проблемы во время загрузки и dmesg
Опрос подключенных дисплеев на старых системах может быть довольно громоздким. Опрос происходит периодически и может занять несколько сотен миллисекунд в зависимости от оборудования.
Если выскакивает ошибка с кодом 0x00000010 (2) во время процесса загрузки (Вы можете получить около 10 строк текста, последняя часть содержит этот код), используйте:
Принудительный режим и EDID
Эта статья или раздел нуждается в переводе
В случае когда Ваш дисплей не отправляет соответствующий EDID или вызывает какие-либо проблемы, Вы будете уведомлены, что родное разрешение автоматически не настроено или не отображается вообще. Ядро имеет условие для загрузки бинарных данных EDID, и поддерживает четыре наиболее типичных разрешения.
Если у Вас имеется EDID файл для Вашего монитора, процесс упрощается. Если нет, можете использовать один из преднастроенных EDID файлов (или сгенерированных однажды во время компиляции ядра, больше информации здесь) или создать свой собственный EDID.
В случае когда EDID имеется (например извлечённый из Windows драйверов для Вашего монитора или полученный командой get-edid из пакета read-edid ), создайте директорию edid в /usr/lib/firmware :
затем скопируйте Ваш файл в директорию /usr/lib/firmware/edid .
Для запуска во время загрузки, следуйте указаниям из kernel command line:
Также, можно указать только для заданного дисплея:
Для преднастроенные разрешений, смотри таблицу имён спецификаций:
Разрешение | Имя спецификации |
1024×768 | edid/1024×768.bin |
1280×1024 | edid/1280×1024.bin |
1600×1200 (kernel 3.10 or higher) | edid/1600×1200.bin |
1680×1050 | edid/1680×1050.bin |
1920×1080 | edid/1920×1080.bin |
Если осуществлён ранний запуск KMS, необходимо включить кастомизированный файл EDID в initramfs иначе возможны проблемы.
Вы также можете собрать собственный EDID с использованием makefile входящего в ядро. Полная информация доступна по адресам здесь и здесь.
Режим может быть принудительным в командной строке ядра. К сожалению, опция командной строки видео бедно документирована в случае с DRM. Части и куски того как это использовать можно найти в
- : Коннектор, т.н. DVI-I-1, смотри доступные здесь /sys/class/drm/
- x : разрешение
- M: посчитать режим CVT?
- R: снижение мерцания?
- — : глубина цвета
- @ : частота обновления
- i: черезстрочный (non-CVT mode)
- m: поля?
- e: принудительный вывод on
- d: принудительный вывод off
- D: принудительный цифровой вывод on (т.н. DVI-I коннектор)
Вы можете переопределять режимы нескольких выходов использующих «video» несколько раз, в частности, для вывода DVI в 1024×768 на 85 Hz и отключения TV-out:
Для получения имени и текущего статуса коннекторов, Вы можете использовать однострочную команду:
Отключение modesetting
Вы можете захотеть отключить KMS по различным причинам, таким как получение пустого экрана или «no signal» ошибку с монитора, когда используются драйвера Catalyst, и т.п. Для отключения KMS добавьте nomodeset в параметры ядра. См. Kernel parameters для более подробной информации.
Источник
Графическая среда Linux без единого разрыва
TL;DR — Если ваше графическое окружение Linux во время просмотра видео, сеанса игры или прокрутки интерактивной веб страницы не успевает вовремя обновлять картинку целиком, то тогда для вас имеет смысл установить последнюю стабильную версию ядра ≥ 4.10.
Давным давно, то есть несколько лет назад каждая реализация протокола X11 предполагала смену режима видео напрямую, поперек батьки кернела. Затем появился KMS (kernel mode setting) и эта важная функция перешла к ядру. Но остались некоторые шероховатости. Атомарная смена режима является дальнейшим улучшением механизма KMS.
Для чего нужны атомарные операции KMS? Главным образом для того, чтобы избежать вот таких моментов.
Атомарная смена режима видео
DRM драйвер с поддержкой атомарной смены режима, a․ k․ a․ atomic mode setting имеет полезное свойство, которое заключается в том, что изменения видео режима проходят полную проверку прежде, чем вступят в силу. Это делается с целью обеспечить их корректное исполнение в драйверах и на дисплее с тем, чтобы избавить пользователей от мерцания, тиринга и прочих артефактов изображения. Скорость исполнения при этом также повышается. Звучит неплохо, а как это работает?
- Framebuffer — Видео память, однако в терминологии KMS это скорее пул источников памяти видео — объектов GEM, для которого заданы такие характеристики как активная зона памяти, или то, что будет изображено, а также формат данных, длина шага.
- CRTC — Аббревиатура расшифровывается как Cathode Ray Tube Controller, CRT Controller. Мало кто в нынешнее время использует мониторы на электронно-лучевых трубках, однако историческое название сохранилось с виде абстракции железа, которое считывает байты с памяти видео-карты и выдает пиксели на шину данных.
- Encoder — Интерфейс между разнородными источниками видео, читает с CRTC и передает в соединительный разъем, a․ k․ a․ Connector . Один CRTC может иметь несколько кодеров.
- Connector — Это может быть представлением для соединительного разъема монитора или же самим монитором в случае встроенных устройств с подключенных внешним экраном.
- Planes — Слой или план изображения на CRTC .
Для этого надо понять как изменяется видео режим без этого нововведения. Рассмотрим обычный сценарий, в котором пользователь смотрит видео в окне браузера или плеера, не в полный экран, используя аппаратное ускорение. Видео образует передний план, окно и декорации браузера или плеера, это второй — задний план.
- Драйверу видео передается список различных параметров: кадровый буфер, CRTC, экраны, режим.
- Пользователь перемещает окно плеера.
- Для этого нужно подгрузить новую страницу, a․ k․ a․ page flip, например.
- Если новая страница не синхронизирована между передним и задним планом, видео сместится относительно своего окна.
Механизма, обеспечивающего синхронизацию на предпоследнем шаге нет, отсутствовал ioctl() , который выполнял бы всю работу. Например, только основной план имел механизм неблокирующих обновлений критичных с точным завершением событий. А для того, чтобы обновления произошли в нескольких слоях, требовалось куча системных вызовов из пользовательского пространства в надежде на то, что они завершатся синхронно. В то же время атомарные операции KMS имеют встроенную защиту от этого. Вместо трех разных ioctl() , все изменения проходят в одном единственном ioctl() .
Вообще-то проблему отсутствия синхронизации между активной зоной и задним планом во время просмотра видео решалась компоновкой всего с помощью GL, так как последний умеет обновлять кадры синхронно с VBlank. Все бы хорошо, только вот для мобильных устройств это не приемлемо из за высоких требования к памяти и питанию со стороны GL компоновщика.
Работы над «атомным» проектом началась в 2015-м с патчей Дейва Эйрли (Dave Airlie), затрагивающих интеловские i915 и еще несколько драйверов, плюс новое атомарное API.
В настоящий момент атомарный процесс обновлений происходит следующим образом.
- Все изменения передаются ядру одним списком свойств (в середине картинки Properties ).
- Ядро генерирует состояние устройства (справа на картинке State ).
- atomic_check() проверяет валидность всех элементов списка свойств. Если есть ошибка ioctl() вернет уведомление об ошибка и отменит обновления.
- atomic_commit() также в соответствии с названием вводит изменения в действие, если на предыдущем шаге atomic_check() завершился без ошибок.
Структура атомарной KMS определена в файле /usr/include/uapi/drm/drm_mode.h .
Для открытых драйверов Nouveau от Nvidea атомарный KMS включен по умолчанию начиная с версии Linux 4.10, для драйверов Intel — начиная с 4.12. Дальше — больше!
Источник