Вопросы Теги

Установка привилегированного режима по сравнению с кадровым буфером?

По-видимому, много инструментов (среди них udev) скоро потребуют/run/каталога, который смонтирован рано (как tmpfs). Разработчики дуги представили/, выполненный в прошлом месяце для подготовки к этому.

udev данные во время выполнения, перемещенные от/dev/.udev/до/run/udev/. / работают, точка монтирования, как предполагается, является tmpfs, смонтированным во время ранней начальной загрузки, доступной и перезаписываемой к для всех инструментов в любое время во время начальной загрузки, это заменяет/var/run/, который должен стать символьной ссылкой однажды. [1]

Здесь существует больше детали: http://www.h-online.com/open/news/item/Linux-distributions-to-include-run-directory-1219006.html

[1] От потока на Проектах Дуги ML

24
15.06.2012, 17:15
2 ответа

KMS устанавливает разрешение дисплея и глубину в пространстве ядра, а не пространстве пользователя. Так да это заменяет его. Это включает родное разрешение в кадровом буфере.

Установка привилегированного режима

3
27.01.2020, 19:41
  • 1
    Wiki о KMS легко найти, но объяснения ужасны. Как KMS может заменить fb, и в то же время включают его? fb уже поддерживал родное разрешение, поэтому что отличается? Утилиты fb работают с KMS? –  user5184 28.06.2011, 18:29
  • 2
    я не думаю родное разрешение поддержки кадрового буфера, особенно когда монитор является широким экраном. например, родное разрешение моего ЖК-монитора 1680x1050, однако, кадровый буфер только обнаруживают 1280x1024, разрешение –  LiuYan 刘研 28.10.2012, 11:34

Прежде всего, существует два типа классических драйверов для фреймбуфера:

  • Generic hardware & firmware drivers (например, vga, vesafb/uvesafb, efifb)
  • Hardware-specific drivers (например, rivafb, atyfb)

Классические драйверы для фреймбуфера все имеют поддержку базового набора режимов, но они практически не поддерживают аппаратные драйверы, если таковые вообще имеются.

При классическом дизайне X это не было проблемой: чтобы получить 2D-ускорение, X-сервер работал как root, и мог получить прямой доступ к оборудованию. Он практически полностью обходил драйвер фрейм-буфера. Для поддержки 3d (и 2d на новых картах) он также использовал драйвер DRM ядра, который опосредовал доступ и управлял видеопамятью.

В этой установке было два места, где осуществлялся набор режимов: как в драйвере фрейм-буфера ядра, так и в пользовательском пространстве X сервера. Такое дублирование кода (и случайные ссоры между драйверами, например, на VT-переключателе) не было идеальным.

Кроме того, в ядре было два отдельных драйвера для одной и той же части оборудования: драйвер фрейм-буфера и драйвер DRM. В некоторых случаях (например, prekms intelfb), можно было загрузить тот или иной, но не оба одновременно.

KMS был решением этих проблем. Она:

  • Объединяет специфический для ядра драйвер фреймбуфера и драйвер drm в один драйвер.
  • Предоставляет интерфейс, который X-сервер может использовать для управления набором режимов, так что X-серверу не нужно иметь прямого доступа к оборудованию. (Действительно, в KMS X-серверу больше не нужны права root)

Некоторые интересные заметки: Переход на то, что сейчас является KMS, на самом деле начался примерно в 2004 году; см. письмо Джона Смирла о консольной перестройке .

Чтобы ответить на более конкретные вопросы:

  • Скорость, как правило, не хуже, чем один из неускоренных общих драйверов (например, VGA, vesafb), но текстовая консоль фрейм-буфера KMS была разработана для удобства и экстренного использования, а не для скорости, и на некоторых драйверах консоль не полностью ускоряется. Обернутые длинные строки довольно плохо на картах intel, например.
  • Приложения, предназначенные для использования старых интерфейсов фреймбуфера, все равно будут работать на фреймбуфере KMS.
6
27.01.2020, 19:41

Теги

Похожие вопросы