Ключевые слова:framebuffer, console, xfree86, video-mode, linux, (найти похожие документы)
From: Demige <[email protected]>
Newsgroups: http://www.nnlug.h10.ru
Date: Mon, 23 Feb 2004 14:31:37 +0000 (UTC)
Subject: Настройка framebuffer под Linux
Оригинал: http://www.nnlug.h10.ru/index.php?page=other_page&active_menu=opyt&link=issues/fb.html
Настройка framebuffer под Линукс.
Скажите, кто из вас не делал этого? Наверняка почти все. Мне просто
захотелось все это обобщить и рассмотреть различные варианты
настройки. Буду рад всем вашим дополнениям. И наконец - появится
первая статья :).
Все желающие могут использовать материал данной статьи, но только при
наличии ссылки на первоисточник. В статье использован материал с сайта
http://kmxb.narod.ru/index.html
Для осуществления сабжа вам будет необходимо несколько вещей:
* не кривые руки (надо хотя бы иметь опыт компиляции ядра),
* ОС Linux,
* ведро линукс больше >=2.4.5 (уточните - не помню когда появился
fb). Насчет всего сказанного относительно 2.6 прошу не пинать -
сам не проверял.
О чем базар?
Framebuffer - это такая классная штука, которая позволяет нам в
текстовом режиме увидеть больше символов чем 80x25, да еще посмотреть
картинки и фильмы поверх текста - виндузятники просто помирают от
зависти. В дословном переводе означает "кадровый буфер". Когда мы
включаем свой компьютер, мы в большинстве своем видим при загрузке как
lilo обращается через BIOS к нашей видюхе, а затем и ядро (уже
напрямую) выдает на консоль все в том же режиме 80х25. Возникает
вопрос - почему же мы владельцы наикрутейших видеокарт с поддержкой
vesa 2.0 (с s3tri64v2) и vesa 3.0 (начиная вроде с ривы) должны
пользоваться этим наследием доисторических времен, когда компьютеры
были большими а программы - маленькими?
Первым делом, первым делом - самолеты...
Наипростейшим решением узнать поддерживает ли ваша карта vesa >=2.0
было бы написать простенькую программку, которая загружается с дискеты
и инициализирует vesa, считывая при этом инфу... Но некоторым кажется
проще найти какой-нибудь виндозный софт типа sandra-soft- че-то-там
или AIDA32... На самом деле это уже ваши проблемы. Могу только
заверить, что если у вас agp-карта то она vesa 2.0 точно поддерживает.
Так вот о чем это я...
Заходим в консоли под root'ом в /usr/src/linux
пишем make menuconfig
ставим галку
"Code maturity level options>Prompt for development and/or incomplete
code/drivers"
далее идем в
"Console drivers>Frame-buffer support"
и включаем vesafb (у кого карта nvidia - включите rivafb - о нем тоже пойдет речь)
все это компилим.
Дальше смотрим в /usr/src/linux/Documentation/fb/vesafb.txt
И что же мы видим?
640x480 800x600 1024x768 1280x1024
256 0x301 0x303 0x305 0x307
32k 0x310 0x313 0x316 0x319
64k 0x311 0x314 0x317 0x31A
16M 0x312 0x315 0x318 0x31B
Это список нужных нам режимов. Т.к. vesa 2.0 не поддерживает смену
частоты развертки все режимы на частоте 60Hz... В следующей версии
этой статьи будет как этот досадный факт исправить Открываем
/etc/lilo.conf (если у вас в качестве загрузщика lilo) и
добавляем(!!!) вместе с новым ядром строчку типа vga=... вы думаете
это число из таблицы? А нифига - берите калькулятор и пересчитывайте
все в десятичную систему счисления. Именно добавляем а не исправляем.
Не спрашивайте почему.
image = /boot/vmlinuz
root = /dev/hda2
label = Linux-fb
read-only
vga=[режим]
После этого пишем lilo и reboot.
После перезагрузки вы должны увидеть мир линукс другими глазами.
Если вывалилось сообщение типа incorrect vga mode press space or enter
и т.д то значит на вашей карточке vesafb работать не будет как не
старайся. Все вопросы к Gerd Knorr <[email protected]>
Это не баг - это фича
Дополнительно можно проставить параметры модулю vesafb написав в
lilo.conf
append=vesa:opt[,opt1[,opt2...]]
* ypan - скроллинг работает быстрее за счет того что экран не
перерисовывается, а просто изменяется адрес окна в памяти.
* ywrap - тоже самое, только уже при достижении конца памяти
указатель перемещается в начало. Быстрее, чем ypan
* redraw - самый медленный вариант - перерисовка
* vgapal и pmipal - при изменении палитры использовать либо
стандартные регистры либо через защищенный режим.
* mtrr - включить использование MemoryTypeRangeRegisters - в кратце
это должно ускорить работу. (только на PII и выше)
Для самых смелых
А теперь поговорим о счастливых (или несчастных) владельцах видеокарт
от nVIDIA.
Спешл для вас есть модуль rivafb, который мы и попытаемся использовать
по-назначению.
Сразу оговорюсь - в X Window вам придется пожертвовать деревами от
nvidia(т.е. и ускорением GLX) и поставить nv, иначе все что вы
добъетесь - повесившаяся консоль и даже SysRq иногда не спасает.
Для нормальной настройки вам еще понадобится пакет fbset.
По умолчанию при загрузке модуля rivafb инициализируется режим
640x480/8-60Hz Это естественно нас не устраивает и тогда мы при помощи
пакета fbset это исправим. Если Вы скомпилили rivafb как модуль, то
потрудитесь прописать его загрузку где-нить в одном из скриптов в
/etc/rc.d, который исполняется как можно раньше.
Например у меня это /etc/rc.d/rc.sysinit
modprobe rivafb
где-то там можно еще и прописать строку
fbset -a -x ....
Не буду перечислять параметры fbset - это не входит в цели данного
документа так что RTFM.
Вместо этого опишу файл /etc/fb.modes. В нем находится самое
интересное - различные разрешения экрана для fbset.
Чтобы добавить свое любимое разрешение из X достаточно запустить под
ним xvidtune и нажать кнопку show. Мы получим т.н. Modeline, который
нам теперь предстоит преоброзовать в формат понятный fbset.
Например у меня.
"1024x768" 75.00 1024 1048 1184 1328 768 771 777 806 -hsync -vsync
Для этого запускаем /usr/sbin/modeline2fb и пишем в него (например
просто вставив все мышкой)
Modeline "1024x768" 75.00 1024 1048 1184 1328 768 771 777 806 -hsync -vsync
Получаем описание режима и сохраняем его где-нибудь в /etc/fb.modes
под другим именем. Глубину цвета указываем в строчке geometry в
качестве последнего параметра. Идеальный вариант - 15 бит/пиксель
Все теперь прописываем fbset в скриптах с названием этого режима в
качестве параметра.
fbset -x -a 1024x768-70.
Если вы не сделали такой же ошибки как и я и не стали компилировать
rivafb как модуль, а встроили его в ядро то можно забить на fbset и
обратиться к /etc/lilo.conf
append="video=rivafb:xres:800,yres:600,pixclock:17761,
left_margin:152,right_margin:32,upper_margin:27,lower_margin:1,
hsync_len:64,vsync_len:3,bits_per_pixel:32"
Параметры из /etc/fb.modes.
теперь мы поимели консоль с нужной нам частотой развертки, но это еще
не все. Теперь мы можем запускать mplayer -vo fbdev. Это так к
слову... Работает все значительно быстрее чем с vesafb.
Сыроедам
Чтобы не пользовать fbset или есть резон использовать rivafb как
модуль или просто ради извращенного интереса то можно прописать нужный
режим в исходниках модуля. kernel-2.4.xx
/usr/src/linux-2.4.xx/drivers/video/riva/fbdev.c: ищем такие строки:
static struct fb_var_screeninfo rivafb_default_var = {
xres:1024,
yres:768,
xres_virtual:1024,
yres_virtual:768,
xoffset:0,
yoffset:0,
bits_per_pixel:15,
grayscale:0,
red:{0, 6, 0},
green:{0, 6, 0},
blue:{0, 6, 0},
transp:{0, 0, 0},
nonstd:0,
activate:0,
height:-1,
width:-1,
accel_flags:0,
pixclock:13333,
left_margin:144,
right_margin:24,
upper_margin:29,
lower_margin:3,
hsync_len:136,
vsync_len:6,
sync:0,
vmode:FB_VMODE_NONINTERLACED
};
в kernel 2.5.xx аналогично правим этот же и еще один файл:
/usr/src/linux-2.5.xx/drivers/video/vfb.c
static struct fb_var_screeninfo vfb_default __initdata = {
.xres =1024,
.yres =768,
.xres_virtual =1024,
.yres_virtual =768,
.bits_per_pixel = 15,
.red ={ 0, 8, 0 },
.green ={ 0, 8, 0 },
.blue ={ 0, 8, 0 },
.activate =FB_ACTIVATE_TEST,
.height =-1,
.width =-1,
.pixclock =13333,
.left_margin =144,
.right_margin =24,
.upper_margin =29,
.lower_margin =3,
.hsync_len =136,
.vsync_len =6,
.vmode =FB_VMODE_NONINTERLACED,
};
Приложение 1: Конкретизация
Некоторые уточнения.
* Параметр video ядра (который мы указывали в lilo.conf)
используется для задания драйвера консоли и его параметров (в
нашем случае это rivafb или vesa). Т.е. Если у вас одновременно
встроен в ядро несколько драйверов, то выбирается конкретный
именно здесь. Это не относится к варианту, когда у вас драйвер
скомпилен как модуль (в этом случае передача параметров не
происходит).
* В данном документе не учитываются особенности некоторых
дистрибутивов (во многих уже включен по умолчанию vesafb)
Приложение 2: Конвертирование таймингов modeline в тайминги фрэйм-буфера
Converting XFree86 timing values info frame buffer device timings
---------------------------------------------------------------------
An XFree86 mode line consists of the following fields:
"800x600" 50 800 856 976 1040 600 637 643 666
< name > DCF HR SH1 SH2 HFL VR SV1 SV2 VFL
The frame buffer device uses the following fields:
- pixclock: pixel clock in ps (pico seconds)
- left_margin: time from sync to picture
- right_margin: time from picture to sync
- upper_margin: time from sync to picture
- lower_margin: time from picture to sync
- hsync_len: length of horizontal sync
- vsync_len: length of vertical sync
1) Pixelclock:
xfree: in MHz
fb: in picoseconds (ps)
pixclock = 1000000 / DCF
2) horizontal timings:
left_margin = HFL - SH2
right_margin = SH1 - HR
hsync_len = SH2 - SH1
3) vertical timings:
upper_margin = VFL - SV2
lower_margin = SV1 - VR
vsync_len = SV2 - SV1
Good examples for VESA timings can be found in the XFree86 source tree,
under "xc/programs/Xserver/hw/xfree86/doc/modeDB.txt".
Автор: Demige <[email protected]>.
Специально для Нижегородской группы пользователей Linux
http://www.nnlug.h10.ru
А у меня в слаке 10.0 на дровах nvidia работают иксы и есть обычный фреймбуфер (он вкючен в стандартное ядро bare.i, которым я пользуюсь).
Карточка GF4MX440. Никаких подвисаний не наблюдается. Можете это объяснить? Версия драйвера 43. Еще интереснее объяснить бы, почему когда я ставлю более новые дрова 6111, они при установке ругаются на фреймбуфер и потом консоль действительно виснет?
