The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Настройка framebuffer под Linux (framebuffer console xfree86 video-mode linux)


<< Предыдущая ИНДЕКС Поиск в статьях src Установить закладку Перейти на закладку Следующая >>
Ключевые слова: framebuffer, console, xfree86, video-mode, linux,  (найти похожие документы)
From: Demige <nnlug@hotbox.ru> 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 <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". Автор: Demige <nnlug@hotbox.ru>. Специально для Нижегородской группы пользователей Linux http://www.nnlug.h10.ru

<< Предыдущая ИНДЕКС Поиск в статьях src Установить закладку Перейти на закладку Следующая >>

Обсуждение [ RSS ]
  • 1, Пингвинчик (?), 13:50, 15/10/2004 [ответить]  
  • +/
    А у меня в слаке 10.0 на дровах nvidia работают иксы и есть обычный фреймбуфер (он вкючен в стандартное ядро bare.i, которым я пользуюсь).
    Карточка GF4MX440. Никаких подвисаний не наблюдается. Можете это объяснить? Версия драйвера 43. Еще интереснее объяснить бы, почему когда я ставлю более новые дрова 6111, они при установке ругаются на фреймбуфер и потом консоль действительно виснет?
     

     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:




    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру