Как их вместе использовать, то бишь включить и далее, и чем чревато
Включать в lilo.conf вот это как то стремно,
# VESA framebuffer console @ 1024x768x64k
#vga=791правь его потом с livecd в случае чего
Настоятельно просим вас при общении соблюдать Правила форума и законы РФ. Наша тематика вне политики, поэтому воздержитесь от обсуждения ситуации на Украине и связанных с ней событий, независимо от того, какую сторону вы поддерживаете.
Также напоминаем, что наш форум находится в доменной зоне .ru, физически расположен на российских серверах и мы соблюдаем действующее законодательство России. Любые сообщения о политике будут удаляться.
Linux Forum → Slackware Linux → Блоб nvidia и uvesafb
Страницы 1
Чтобы отправить ответ, вы должны войти или зарегистрироваться
Как их вместе использовать, то бишь включить и далее, и чем чревато
Включать в lilo.conf вот это как то стремно,
# VESA framebuffer console @ 1024x768x64k
#vga=791правь его потом с livecd в случае чего
Как их вместе использовать, то бишь включить и далее, и чем чревато
никак увы, т.е. включить то ты включишь, но эффекта будет ноль, ей(ювесе) нужен костыль v86d который непойми как и через что работает( у меня вообще не хочет вовремя стартовать) и т.д. и т.п.
если тебе нужна графическая консоль есть решение, но сайт с его описанием уже с пол-года умер. Вот вариант - тыц
если тебе нужна графическая консоль есть решение, но сайт с его описанием уже с пол-года умер. Вот вариант - тыц
Thanks. Опробованный вариант, а то "на кошках потренироваться" как не получается ?:-)
ей(ювесе) нужен костыль v86d который непойми как и через что работает( у меня вообще не хочет вовремя стартовать) и т.д. и т.п.
У гентушников нарыл что надо пересобирать под него ядро с
CONFIG_INITRAMFS_SOURCE="/usr/share/v86d/initramfs
Может оно ?
Может оно ?
да оно, только стоит крепко курнуть(да-да совсем не табака!) чтобы проделать сей финт ушами в Слаке, прочти внимательно последовательность действий - да за такие извращения убивать нужно из рогатки колотым горохом...
... и таки да - вся эта пляска с тухлым членом мамонта всё равно не принесет ожидаемого эффекта - ювеса всё-равно не стартует вместе с ядром, максимум её можно дёрнуть как модуль после монтирования корня, но это всё касается только случая НЕиспользования блоба - таки Слака это не Гента, хотя и похожи некоторыми плоскостями. Я этим онанизмом как-то с месяц занимался(в целях саморазвития) в результате тупо собрал Генту и сейчас понимаю над чем так стебается львиная доля гентушников когда дело касается дистросрачей... а на Слаке я сделал так - тыц, в общем очень доволен и обои в консоли есть и система не напрягается.
"Так" это как ? :-)
"Так" это как ? :-)
ссылку не видишь ?
вот она...ссылка
или тебе нужен мунуал ?
Если правильно путаю, то CONFIG_INITRAMFS_SOURCE -- это то же самое, что и внешний initrd, только приклеенный к ядру.
В /usr/share/v86d/initramfs (текстовый файл) лежат "инструкции" по которым строится initramfs, там совсем немного.
В Slackware традиционно для построения initrd.gz используется mkinitrd. Это хозяйство можно допаковать в его начальный образ в /usr/share/mkinitrd/initrd-tree.tar.gz или, добавив в /boot/initrd-tree, перепаковать сжатый образ вызовом mkinitrd без ключей.
Появится под рукой машина с nvidia, попробую с блобом провернуть...
черт, будет интересно, результаты будут ?
Появится под рукой машина с nvidia, попробую с блобом провернуть...
ничилавечески человечный человек !
... вот только зачем это в Слаке ? Есть же красивое и простое решение.., ну да ладно, ждем историю успеха(с подробностями), тоже интересно как у тебя получится.
Возможно пригодится — http://www.funtoo.org/wiki/Uvesafb
Возможно пригодится — http://www.funtoo.org/wiki/Uvesafb
ещё чуть-чуть и легким..лег...гким...тьфу изящным движением руки Слака превращается в Gentoo ...
да, вот мануал по которому я делал - http://en.gentoo-wiki.com/wiki/Initramfs
nvidia под руку ещё не попалась, поэтому пока опишу, что нужно для перехода на uvesafb в общем случае.
Сразу оговорюсь, что процесс оказался прост и прямолинеен.
0. Исходные:
Slackware-13.37 32-bit внутри VirtualBox-3.2.12
Ядра стоковые:
- основное generic-smp-2.6.37.6, создан initrd
- резервное huge-smp, прописано в lilo.conf отдельным пунктом загрузки (да, из ремонтных соображений).
Поехали...
1. Читаем
http://dev.gentoo.org/~spock/projects/uvesafb/
Смотрим, как собрано ядро:
$ zgrep "CONFIG_CONNECTOR\|CONFIG_FB_UVESA" /proc/config.gz
CONFIG_CONNECTOR=m
# CONFIG_FB_UVESA is not setПонимаем, что нужно дособрать собственно uvesa, чем и займёмся.
2. Собираем модуль uvesafb
Ставим исходники ядра (если ещё не установлены):
# slackpkg install kernel-sourceВключаем сборку uvesafb, собираем и ставим модуль:
# cd /usr/src/linux
# zcat /proc/config.gz > .config
# make menuconfig
Graphics support --->
Support for frame buffer devices --->
<M> Userspace VESA VGA graphics support
# make prepare modules_prepare
# make drivers/video/uvesafb.ko
# cp drivers/video/uvesafb.ko /lib/modules/$(uname-r)/kernel/drivers/video/
# depmod -A3. Ставим klibc (есть на slackbuilds.org)
# mkdir ~/bld; cd ~/bld
# wget http://slackbuilds.org/slackbuilds/13.37/misc/klibc.tar.gz
# tar xf klibc.tar.gz
# cd klibc
# wget http://mirror.sit.wisc.edu/pub/linux/libs/klibc/1.5/klibc-1.5.24.tar.bz2
# PKGTYPE=txz VERSION=1.5.24 ./*Build
# rm -rf /tmp/SBo/klibc-*/ /tmp/SBo/package-klibc/
# upgradepkg --install-new /tmp/klibc-*t?z4. Ставим v86d
# cd /src
# wget -O - http://dev.gentoo.org/~spock/projects/uvesafb/archive/v86d-0.1.10.tar.bz2 | tar jx
# cd v86d
# ./configure --with-klibc
# make
# strip --strip-unneeded v86d
# make install
# make cleanРезультат -- единственный файл: /sbin/v86d, желающие могут опакетить ;-)
5. Готовим initrd
Как говорил выше, у меня initrd был создан ранее, поэтому мне достаточно было просто немного модифицировать существующий /boot/initrd-tree и пересобрать /boot/initrd.gz. Если в сказанном что-то непонятно, читаем /boot/README.initrd, man mkinitrd. Полезняшка:
# /usr/share/mkinitrd/mkinitrd_command_generator.sh
mkinitrd -c -k 2.6.37.6-smp -f ext4 -r /dev/sda2 -m jbd2:mbcache:ext4 -u -o /boot/initrd.gzДобавляем uvesafb в список модулей (коннектор -- cn -- добавится по зависимостям) и выполняем:
# mkinitrd -c -k 2.6.37.6-smp -f ext4 -r /dev/sda2 -m uvesafb:jbd2:mbcache:ext4 -u -o /boot/initrd.gzЧитаем /usr/src/linux/Documentation/fb/uvesafb.txt
Модифицируем дерево, добавляя туда /sbin/v86d, правим параметры модуля в /boot/initrd-tree/load_kernel_modules и пересобираем initrd:
# cp /sbin/v86d /boot/initrd-tree/sbin/
# sed -i /boot/initrd-tree/load_kernel_modules \
-e 's/uvesafb/uvesafb mode_option=1024x768-32 mtrr=3 scroll=ywrap/'
# mkinitrd6. Загрузчик
Правим /etc/lilo.conf, ставим vga=normal или vga=extended, если не было initrd -- добавляем. Получится что-то вроде:
append=" vt.default_utf8=1"
boot = /dev/sda
compact
lba32
bitmap = /boot/slack.bmp
bmp-colors = 255,0,255,0,255,0
bmp-table = 60,6,1,16
bmp-timer = 65,27,0,255
prompt
timeout = 30
change-rules
reset
vga=normal
image = /boot/vmlinuz-generic-smp-2.6.37.6-smp
root = /dev/sda2
initrd = /boot/initrd.gz
label = Linux
read-only
image = /boot/vmlinuz-huge-smp-2.6.37.6-smp
root = /dev/sda2
label = LinuxHS
read-onlyЗаписываем загрузчик:
# liloПерезагружаемся, лицезрим uvesafb в действии. На всякий случай проверяем:
# dmesg | grep uvesafb
[ 4.294639] uvesafb: Oracle Corporation, Oracle VM VirtualBox VBE Adapter,
Oracle VM VirtualBox Version 3.2.12, OEM: VirtualBox VBE BIOS http://www.virtualbox.org/, VBE v2.0
[ 4.350977] uvesafb: protected mode interface info at c000:7fe6
[ 4.351902] uvesafb: pmi: set display start = c00c8031, set palette = c00c80e2
[ 4.353167] uvesafb: pmi: ports = 1ce 1cf 1cf 1d0
[ 4.355195] uvesafb: no monitor limits have been set, default refresh rate will be used
[ 4.356568] uvesafb: scrolling: ywrap using protected mode interface, yres_virtual=2304
[ 4.359920] uvesafb: message too long (57808), can't execute task
[ 4.359923] uvesafb: VBE get state call failed (eax=0x4f04, err=-7)
[ 4.374637] uvesafb: framebuffer at 0xe0000000, mapped to 0xe0880000, using 9216k, total 9216kbormant - Голова !
Пожалуй, вместо
# sed -i /boot/initrd-tree/load_kernel_modules \
-e 's/uvesafb/uvesafb mode_option=1024x768-32 mtrr=3 scroll=ywrap/'можно поступить проще, после сборки uvesafb
# echo "options uvesafb mode_option=1024x768-32 mtrr=3 scroll=ywrap" > /etc/modprobe.d/uvesafb.confmodprobe позвать с -M, или ручками:
# mkdir /boot/initrd-tree/etc/modprobe.d/
# cp /etc/modprobe.d/uvesafb.conf /boot/initrd-tree/etc/modprobe.d/Люкс :-) Thanks
Примечание: в качестве исходного дерева mkinitrd использует /usr/share/mkinitrd/initrd-tree.tar.gz. Если дополнить его файликом /sbin/v86d, при создании initrd можно будет обходиться одним вызовом mkinitrd, наподобие:
# mkinitrd -c -M -k 2.6.37.6-smp -f ext4 -r /dev/sda2 -m uvesafb:jbd2:mbcache:ext4 -u -o /boot/initrd.gz
или
# mkinitrd -c -M -m uvesafb:ext4 -u
или даже (при условии правильного содержимого /etc/mkinitrd.conf)
# mkinitrd -F
только не забывать модифицировать /usr/share/mkinitrd/initrd-tree.tar.gz после обновления пакета mkinitrd (да-да, превратится в тыкву ;-) ).
вот только klibc на новых ядрах не хочет собираться( в куренте если чё 3.2.7) :
In file included from /lib/modules/3.2.7-smp/source/include/linux/netdevice.h:30:0,
from /lib/modules/3.2.7-smp/source/include/linux/if_arp.h:26,
from /tmp/SBo/klibc-1.5.23/usr/klibc/../include/net/if_arp.h:3,
from usr/kinit/ipconfig/main.c:15:
/lib/modules/3.2.7-smp/source/include/linux/if_packet.h:176:2: ошибка: unknown type name «__aligned_u64»
usr/kinit/ipconfig/main.c: В функции «loop»:
usr/kinit/ipconfig/main.c:361:6: предупреждение: variable «nr» set but not used [-Wunused-but-set-variable]
make[3]: *** [usr/kinit/ipconfig/main.o] Ошибка 1
make[2]: *** [usr/kinit/ipconfig] Ошибка 2
make[1]: *** [all] Ошибка 2
make: *** [klibc] Ошибка 2и это нормально для klibc ! вот патч для неё - тыц
Вопрос: насколько я понял работу видеосистемы вообще, если, к примеру, я такое проверну, то мне приется распрощаться с проприетарными драйверами на видюшку (у меня nvidia GF FX5200), так? Вроде бы модуль фреймбуфера с модулем видеодрайвера конфликтуют, и если есть один, то второй откажется работать?
Вопрос: насколько я понял работу видеосистемы вообще, если, к примеру, я такое проверну, то мне приется распрощаться с проприетарными драйверами на видюшку (у меня nvidia GF FX5200), так? Вроде бы модуль фреймбуфера с модулем видеодрайвера конфликтуют, и если есть один, то второй откажется работать?
это касается только CONFIG_FB_NVIDIA=y и CONFIG_FB_RIVA=y они оба конфликтуют с блобом, ювеса не конфликтует. Поправлю сам себя(то о чём я сказал в самом начале, что увеса не работает с блобом) - увеса работает, но! во первых какого то профита(учитывая тот гемор, который нужен для того чтобы она заработала) это не даст, во вторых(очевидно эту цель преследует большинство тех кто пытается её запустить) получить нативное разрешение монитора, то которое так лихо демонстрирует nouveau в консоли в первые минуты после только что установленной системы добиться(с вероятностью 98%) не удастся - хоть убейся, все доступные разрешения которые можно получить в фреймбуфере легко находятся в lilo, достаточно в lilo.conf в строке vga=XXX вместо ХХХ указать любую дикую цифру(от балды), тогда при загрузке он предложит выбрать любой режим из возможных в VBIOS вашей карты, и это всё что вы можете получить, если нужного режима нет тогда упс-...пичалька, если есть повезло, но тогда эта самая увеса даром не нужна вот в чем соль.
Вместо дикой цифры можно выполнить
# lilo -T video
но гораздо больше можно узнать у
# vbetest
(есть в lrmi (см. slackbuilds.org) и v86d).
в любом случае это лотерея - вариантов комбинаций карта+монитор - мульён, кому-то везёт, кому-то нет, в любом раскладе если VBIOS поддерживает нужный режим проблем нет, можно использовать и простую весу и увесу, а если нет то увы...
Страницы 1
Чтобы отправить ответ, вы должны войти или зарегистрироваться
Linux Forum → Slackware Linux → Блоб nvidia и uvesafb
Форум работает на PunBB, при поддержке Informer Technologies, Inc