Представьте себе маленького человечка, привыкшего к комфорту, уюту и спокойствию. И вдруг... трах-бабах и... человек, всю жизнь покупавший и использовавший продукцию nVidia (начиная с Riva), прельщается дешевизной бэушного VGA-адаптера от ATI с DVI выходом. 6800gt неожиданно приказала долго жить и, бо последнее время играть в игрушки совершенно не тянет, подыскивал дешёвую замену. Модернизировать компы с AGP слотом ноне смысла нет - посему хай живэ скiлькi осталось. Таким вот макарием и обзавёлся ATI 9600 XT 128Mb за 400 рублей больших денег и испытательным сроком в неделю... "Зарекалась свинья говна не їсти...". Вот так бабло и побеждает все благие намерения...
Впрочем ещё один "виновник" этого беспредела - монитор славной компании Acer, не понимающий аналоговый сигнал, несмотря на наличие D-SUB входа. Качество оборудования Acer не поддаётся описанию нормативной лексикой.
Пробовал найти какие-то внятные статьи по установке и настройке карточек ATI в сети. Болото. Тупое вязкое жирное болото. Особенно умиляют посты людей, упирающих на то, что проблемы возникают только с драйверами nVidia. "Всё чудесатее и чудесатее...".
С лирикой покончили. На повестке дня OpenBSD-4.2, Mac OS X 10.4.10, Archlinux-current и OpenSuSE-10.3. Начинаем с самого простого: OpenBSD. Никаких сторонних модулей, проект xenocara предоставляет Xorg, с которым и возимся. Ничего не нужно удалять. Всё под рукой.
1. Создаём тестовую конфигурацию иксов:
Xorg -configure
эта команда создаст файл ~/xorg.conf.new, над которым и будем измываться до победного...
2. Оцениваем наши скромные достижения:
Xorg -verbose -config /home/Пользователь/xorg.conf.new
до тех пор, пока не получим достойного результата, файл основной конфигурации ( /etc/X11/xorg.conf ) не трогаем.
Основная "засада" - в мерзоиднейшей работе проприетарного и открытого драйверов ATI с DDC - одним из инструментов EDID - механизма описания монитором своей спецификации и взаимодействия с икс-сервером. Это всё относится к стандартам Vesa, любопытных прошу пройти к источникам. Посему никак не обойтись без Modeline параметров, кои трэба с чувством, толком и расстановкой прописать своими заскорузлыми в конфигурационный файл. Механизм очень гибкий и логичный. Используя gtf генерим требуюмую строку Modeline (объяснять надо, что мы указываем ширину, высоту и частотку?):
~ > gtf 1280 1024 75
# 1280x1024 @ 75.00 Hz (GTF) hsync: 80.17 kHz; pclk: 138.54 MHz
Modeline "1280x1024_75.00" 138.54 1280 1368 1504 1728 1024 1025 1028 1069 -HSync +Vsync
и заполняем секцию Modes:
Section "Modes"
Identifier "Modes[0]"
Modeline "1280x1024_75.00" 138.54 1280 1368 1504 1728 1024 1025 1028 1069 -HSync +Vsync
EndSection
Всё, что остаётся, это в секции "Monitor" дать чёткое указание на использование требуемого режима:
Section "Monitor"
*********
UseModes "Modes[0]"
ModeLine "1280x1024" 138.54 1280 1368 1504 1728 1024 1025 1028 1069
*********
EndSection
Указывать "открыто" строку ModeLine в секции "Monitor" особого смысла нет, но вроде как и не мешает. На этом все трудности с конфигурацией ATI в OpenBSD заканчиваются. В секцию "Module" пихаем всё, что найдём под рукой:
Section "Module"
Load "GLcore"
Load "dbe"
Load "extmod"
Load "glx"
Load "record"
Load "xtrap"
Load "freetype"
Load "type1"
EndSection
С Mac OS X дела обстоят ещё проще: прописываем Device ID и Vendor ID в Info.plist драйвера (если по какой-то причине их там нет), ставим AGPGart, коли в том нужда, и отмахиваемся от возможных артефактов программой Mighty Mouse (у карточек 9600 артефакты будут обязательно).
Установка в Linux проприетарного драйвера похожа на песнь нагероиненого шамана. Количество сообщений форумов "на эту тему" потрясает. Толковых постов правда не нашёл. Плохо искал, не иначе...
Сперва в обязательном порядке "выносим" всё, что связано с драйверами nVidia. После чего стоит переустановить xorg и "накатить" сверху последнюю версию Mesa, что найдётся под рукой. Это делается для "отката" драйвера fglrx на Mesa в случае "неувязок" с "родным" OpenGL. И только после этого можно ставить fglrx. Для SuSE компилим и ставим rpm-ку, для Arch/Slackware и прочих не rpm-based дистров ставим сразу. Есть несколько "засад", кроме ModeLine, нигде особо не описанных: во-первых проверить наличие в /etc/fstab строк (ессно не забудем смонтировать сие):
none /dev/pts devpts defaults 0 0
none /dev/shm tmpfs defaults 0 0
Во-вторых - контролировать атрибуты доступа на /dev/dri и всех файлов в /dev/dri/ (при условии конфигурации с несколькими мониторами). Всё, что находится в /dev/dri/, должно иметь атрибуты 666 (rw-rw-rw) и соответственно при запуске иксов не от рута у пользователя должно хватать прав на запись в каталог /dev/dri. Соблюдение этих нехитрых правил позволит заиметь похожую "картинку":
~ > amdcccle
Дополнение:
Плюнув на соображения безопасности ради стабильной работы установил права доступа 777 на сам каталог /dev/dri (drwxrwxrwx). Права доступа на файлы в /dev/dri/ регулируются при помощи секций файла xorg.conf, который и привожу ниже. После долгих экспериментов решил оставить suid bit на /usr/bin/Xorg (755, root:root). Отсутствие нормальной работы с композитом бесит...
> cat /etc/X11/xorg.conf
Section "ServerLayout"
Identifier "X.org Configured"
Screen 0 "Screen0" 0 0
InputDevice "Mouse0" "CorePointer"
InputDevice "Keyboard0" "CoreKeyboard"
EndSection
Section "Files"
RgbPath "/usr/lib/X11/rgb"
ModulePath "/usr/lib/xorg/modules"
ModulePath "/usr/X11R6/lib/modules"
FontPath "/usr/share/fonts/misc/"
FontPath "/usr/share/fonts/local/"
FontPath "/usr/share/fonts/TTF/"
EndSection
Section "Module"
Load "GLcore"
Load "dri"
Load "dbe"
Load "extmod"
Load "glx"
Load "record"
Load "xtrap"
Load "freetype"
EndSection
Section "InputDevice"
Identifier "Keyboard0"
Driver "kbd"
Option "XkbLayout" "us,ru(winkeys)"
Option "XkbModel" "pc105"
Option "XkbOptions" "grp:ctrl_shift_toggle,grp_led:scroll"
Option "XkbRules" "xorg"
EndSection
Section "InputDevice"
Identifier "Mouse0"
Driver "mouse"
Option "Protocol" "auto"
Option "Device" "/dev/psaux"
Option "ZAxisMapping" "4 5"
EndSection
Section "Modes"
Identifier "Modes[0]"
ModeLine "1280x1024_60.00" 108.9 1280 1360 1496 1712 1024 1025 1028 1060
EndSection
Section "Monitor"
Identifier "Monitor0"
VendorName "ACR"
ModelName "Acer MFM DVI"
UseModes "Modes[0]"
DisplaySize 440 280
HorizSync 30.0 - 83.0
VertRefresh 50.0 - 75.0
ModeLine "1280x1024" 108.9 1280 1360 1496 1712 1024 1025 1028 1060
Option "DPMS" "true"
EndSection
Section "Device"
Option "TexturedVideo" "on" # включаем xv
Option "VideoOverlay" "on"
Option "UseFastTLS" "2"
Option "EnablePrivateBackZ" "on"
Driver "fglrx"
BusID "PCI:1:0:0"
Identifier "Card0"
# Driver "radeon"
# Driver "ati"
VendorName "ATI Technologies Inc"
BoardName "RV350 AR [Radeon 9600]"
EndSection
Section "Screen"
Identifier "Screen0"
Device "Card0"
Monitor "Monitor0"
DefaultDepth 24
SubSection "Display"
Viewport 0 0
Depth 24
Modes "1280x1024" "1024x768" "800x600" "640x480"
EndSubSection
EndSection
Section "Extensions"
Option "Composite" "Enable"
EndSection
Section "dri"
Group "video"
Mode 0666
EndSection
Что помогло чуток в написании сего "опуса":
xorg.conf battles
Настройка работы DRI в Linux с новым ATI fglrx драйвером
Выводы:
1. Жить можно, оно работает и может считаться "эталоном" в сравнении с драйверами на VIA Unichrome.
2. Драйверы от ATI - неюзабельное маркетинговое говно
12 комментариев:
ATI драйвера раньше были некачественными, сейчас они несколько лучше.
http://www.helplinux.ru/ati-in-7-10-new
ну ты прямо каких-то ужасов пнарассказал...
Хотя я неспорю что у ати есть проблемы с дровами у энвидии они тоже есть, собственно сидя на gentoo.ru я вижу проюлем хватает у обоих, и их примерно поровну.
Занятно что посты владельцев ати начинаются с "будь проклят тот день когда я сел за бараку этого пылесоса!" а посты юзеров энвидии - "как это вообще может быть?!!" но факты упрямая штука...
Я сам сижу на ати и особых проблем нет - одно время гуглобус неработал, но это потому что оба закрыты, и у гуглобуса своя lib.gl и был глук и у ати и у гуглобуса... последние несколько релизов радуют всё больше. Кстати на 9200 у меня стояли открытые дрова и они вели себя сильно лучше чем закрытые. Собственно мне всегда хватает того что есть на wiki - например http://gentoo-wiki.com/HOWTO_ATI_Drivers и далее по ссылкам, может от того что я на gentoo?
к огромному сожалению это не ужасы. у nvidia проблем с дровами нет. есть проблемы с руками, есть особенности установки, о которых "не пишут в журналах" (удаление инсталлером всех конфликтующих модулей/extensions xorg-а, нюансы с libwfb.so, мерзкая привычка многих дистрибутивов откатывать автоматом драйвер с nvidia на nv). nvidia великолепно поддерживает весь спектр железа, выжимая из него всё возможное.
после nvidia пользоваться ati можно только "наступив на свои яйца". E17-ый в стадии pre-alfa более стабилен, чем поделия от ati. у меня на пустом месте иксы падали несколько раз. кто объяснит, какого буя для включения того же xv (чтобы xvinfo хоть что-то выдало путное) надо что-то самостоятельно дорисовывать в xorg.conf? равно как и для использования прочего потенциала карты (причём в режиме one at a time)??? а работа с композитом? да простят смелое утверждение, но Riva TNT с 16-ю метрами памяти уделает любую карту ati во всём, что не касается игрушек (да и в первой-второй кваке тоже наверное). те же compiz-ик и mplayer пашут не в пример стабильнее. Качество одним словом.
теперь о ссылке на генту-вики - imo - болото. неужели так трудно рассказать о механизме работы дров fglrx и рассмотреть ситуации при старте иксов от рута (с инитскриптов системы) и банальном startx после логина пользователя в консоль? там ой какие интересные нюансы имеют место быть...
собственно поэтому и нарисовал заметку. вдруг кому пригодится...
Мдя вот и я так же когда то со своим IBM T42 мучался(х300)...
Таким же маленьким человеком себя почувствовал, ибо fglrx его не признал.
А у nvidia действительно проблем нет никаких, после пляски вокруг своего x300 понял, что лучше уж проприетарщина, но только, чтоб работала хорошо.
>к огромному сожалению это не ужасы. у >nvidia проблем с дровами нет. есть >проблемы с руками, есть особенности >установки, о которых "не пишут в >журналах" (удаление инсталлером всех >конфликтующих модулей/extensions xorg->а,
собствеено они так-же бросают старые карточки, и других проблем хватает, и так-же иногда сегфолтятся, была проблема со сдвигом вниз на несколько строчек консоли... это то что всплыло из памяти сразу.
в Gentoo инсталлеры не используются, они ломают систему, у нас при установке дров libGL.* складываются в /usr/lib32/opengl/[ati|xorg-x11|nvidia] и в /usr/lib64/opengl/[ati|xorg-x11|nvidia] а потом с помощью комманды
eselect opengl set [ati|xorg-x11|nvidia]
переключается на те что нужно, соответственно либы никто не портит. Пакеты которым на время сборки нужно чтобы opengl был от месы - вначале сборки перключат его на месу, а в конце обратно на то что росло до этого.
Правда иногда разработчики nvidia вспоминают что они лучше всех, и делают какой-нить финт ушами - тогда при сборке приходится отключать "песочницу" ну и ожидать какой-то пакости от дров...
но это совсем другая история.
>нюансы с libwfb.so, мерзкая привычка >многих дистрибутивов откатывать >автоматом драйвер с nvidia на nv).
вот тут я непонял, если ты о проблеме с фрамбуффером - то gentoo такой привычки неимееет, а то о чём я писал - это желание сделать bootsplash и включение в ядре nvidiafb - после чего Х=сервер нестартует сообчая о том что нашёл фрамбуфер в ядре... счасливым владельцам nvidia оставалось юзать vesafb который не держит нестандартные разрешения, а бедные atiшники просто юзают radeonfb. правда недавно появился uvesafb работающий и на 64х битах тоже, так что все теперь счасливы.
>после nvidia пользоваться ati можно >только "наступив на свои яйца". E17-ый >в стадии pre-alfa более стабилен, чем >поделия от ati. у меня на пустом месте >иксы падали несколько раз. кто объяснит, >какого буя для включения того же xv >>(чтобы xvinfo хоть что-то выдало путное) >надо что-то самостоятельно дорисовывать >в xorg.conf?
я скажу, в gentoo всё самостоятельно туда дорисовывается, и насколько я помню мне нужно было сделать записи
Option "RenderAccel" "True"
Option "AIGLX" "True"
Option "VideoOverlay" "True"
Option "OpenGLOverlay" "True"
и всё. помоему это совершенно продрачно и описано в доках.
>теперь о ссылке на генту-вики - imo - >болото. неужели так трудно рассказать о >механизме работы дров fglrx и >рассмотреть ситуации при старте иксов от >рута (с инитскриптов системы) и >банальном startx после логина >пользователя в консоль? там ой какие >интересные нюансы имеют место быть...
так и непонял какие, я поставил нужные дрова особо не напрягаясь, а про инитскрипты я вообше ничего непомню... что за нюансы-то? если ты о правах на dri то
Section "DRI"
Mode 0666
EndSection
их правит на то что нужно...
кстати я вот всё чаще стал встречать что nvidia вообще неюзает dri и при настройке нужно его отклучать так как конфликтует, они что-то своё написали...
>собственно поэтому и нарисовал заметку. >вдруг кому пригодится...
спасибо.
собственно у меня невозникало никогда проблем с атишными дровами, и я тоже думаю что проблемы - от кривых рук, но ты вроде как непохож на человека с кривыми руками... я в замешательстве...
вот что кстати говорит гента при установке атишных дров - попробй, может поможет.
* If you experience unexplained segmentation faults and kernel crashes
* with this driver and multi-threaded applications such as wine,
* set UseFastTLS in xorg.conf to either 0 or 1, but not 2.
*
* You will have to source /etc/profile (or logout and back in) for dri
* to work, unless you previously had ati-drivers installed.
* If you experience screen corruption with this driver, try putting
* Option "XAANoOffscreenPixmaps" "true"
* in the Device Section of /etc/X11/xorg.conf.
спасибо, но сейчас более всего раздражает работа с композитом. вернее полное отсутствие нормальной поддержки оного. и это в 2008-ом то году...
каждый дистрибутив придумывает/имеет свои "костыли" для сглаживания "амбрэ" от продукции ati, генту - не исключение.
а если есть желание - посмотри на бинарник Xorg-а, подумай, что будет, если снять с него рутовый suid bit и запустить иксы от простого юзера с привилегиями этого самого юзера...
вопервых последние дрова ати поддерживают aiglx, а во вторых aiglx это изобретение nvidia и ожидать что на первых порах кто-то кроме них будет её поддерживать глупо.
я сам берил гонял помнится, недавно снёс.
рабоатет начиная с дров 8.42.3 и выше, хотя они не все карточки поддерживают. ну и на последок вспомню о том что ати открывает спеки на карточки постепенно, так что скоро ситуация изменится к лучшему...
кстати система переключения дров сделана не для сглаживания глюков от ати(её энвидия кстати чаще ломает чем ати), а для того чтобы иметь возможность установить несколько вариантов опенгл-дров и переключаться между ними на лету.
1. при чём здесь aiglx, когда невозможно работать при загруженном composite extension и включённом xcompmgr? и это на 9600 XT в 2008-ом году! GeForce2-MX200 (урезанная по самые гланды) гоняет compiz на ура (разгружая проц), а на быдлоподелии ATI уже не знаю, что и где крутить, чтобы заработало. но даже если и "заведётся" - толку-то не будет, ибо композита как такового нет.
2. как прикажете трактовать следующие "заходы":
~ > glxinfo | grep texture_from_pixmap
GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap,
GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap
compiz (core) - Fatal: GLX_EXT_texture_from_pixmap is missing
compiz (core) - Error: Failed to manage screen: 0
compiz (core) - Fatal: No manageable screens found on display :0.0
compiz пересобран с fglrx OpenGL дровами. опять же смотрим на GeForce2-MX200.
выводы:
1. проблем с дровами ATI не будет только у тех, кто не пользовал nVidia в течение длительного времени.
2. я довольно субъективен, ибо всю жизнь пользовал nVidia и не понимаю, почему на драйверах ATI нет "наклейки" pre-alfa...
композит и компиз используют разные технологии, для композита лучше всего ставить открытые дрова и ставить
Option"AccelMethod" "EXA"
а для компиза нужно включить aiglx.
исторически сначала прозрачность сделана была у всех на composite extention но оно всё время тупило, на ЕХА поменьше но его ко времени выхода aiglx умела ати и всё. хотя всёравно тупило сильно. Потом энвидия родила AIGLX и забила на DRI совсем, в новых дровах я насколько помню он ненужен, и соответственно все теперь в роли догоняющих. Сам я гонял на своей карточке берил нативно, а потом он благополучно помёр и компиз я ставить нестал. если тебе очень нужно могу поставить и рассказать что к чему, у тебя версия дров какая?
Просто у каждого производителя - что ати что энвидии есть свои глюки, но если юзать всё время одно и тоже то получается ты привыкаеш к своим и их невидиш - я тоже ставил другу на ноут gentoo и исплевался с дровами энвидии, то что они фрумбуфер не держат, и ещё что-то... как говориться - "чума на оба ваших дома!"
кстати вчера новая версия дров вышла - там какието сегфолты починили, заюзай может поможет.
помоему я наткнулся на решение этой проблемы - у меня прекрасно работал берил, а на компиз я не переехал - наигрался. вот что пишут на гентушной вики
http://gentoo-wiki.com/HOWTO_compiz-fusion#Compiz-fusion_doesn.27t_start.2C_beryl_was_running_great
Compiz-fusion doesn't start, beryl was running great
Did you have beryl, which runs on your Linux perfectly, and now compiz-fusion doesn't start? Yes, i had this problem too :)
If you see in console this:
Missing GLX_EXT_texture_from_pixmap
you must run compiz with LIBGL_ALWAYS_INDIRECT=1, so it will look like that:
env LIBGL_ALWAYS_INDIRECT=1 compiz --replace ccp
I've added this variable to /etc/env.d/03opengl, and it help, i can now run compiz normal.
так что вроде долно работать :)
Отправить комментарий