Настройка 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 <kraxel@goldbach.in-berlin.de>
Это не баг - это фича.
Дополнительно можно проставить параметры модулю 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".