libGL.so.fglrx нужно убрать из /usr/X11R6/lib, оптимальный вариант - сделать так же как и для nvidia
Да, действительно, сейчас с libGL.so.fglrx не работает даже r200_dri.so (хотя вроде бы раньше - с XFree86 4.3 и соответствующим fglrx - это работало). Причём решение из nvidia_glx_common в данном случае не годится - во-первых, у меня нет списка PCI ID карт, поддерживаемых fglrx, во-вторых, на R2xx может использоваться как fglrx, так и radeon, в зависимости от настроек в xorg.conf. Кроме того, подобное перекидывание ссылок непосредственно в /usr/X11R6/lib вроде как противоречит policy относительно доступности /usr для записи. Пока что видятся следующие варианты: - возрождать libGLwrapper; - добавить в xorg-x11-server вызов какого-нибудь скрипта (hotplug? :) после успешной инициализации видеодрайвера, и в этом скрипте в зависимости от имени драйвера перекидывать libGL; - при загрузке всегда ставить libGL.so.1 на стандартную библиотеку из xorg, а в /etc/modutils.d/ засунуть в post-install fglrx переустановку ссылки на libGL.so.fglrx, и аналогично для nvidia.
последний вариант мне кажется наиболее правильным
(In reply to comment #2) > последний вариант мне кажется наиболее правильным А мне он вообще-то кажется хаком из-за невозможности нормально отследить используемый xorg драйвер. К тому же создаётся ещё одно препятствие для миграции с modutils на module-init-tools в будущем (если до этого всё-таки дойдёт дело).
(In reply to comment #2) > последний вариант мне кажется наиболее правильным А чем не устраивает вариант с libGLwrapper, но с привязкой не к PCI ID или как там оно было сделано, а к наличию/отсутствию определённого extension типа NV-GLX/ATIFGLRXDRI ?
кто wrapper писать будет? я отказываюсь реанимировать эту страшилку
Ну вы пока думайте, я попробую что-ньдь полуработающее сваять ;-) У нас бывает несколько версий nvidia_glx в системе?
бывает. одно время у меня так std-smp и std-up жили
(In reply to comment #6) > У нас бывает несколько версий nvidia_glx в системе? Канэшна. Именно такая возможность специально сделана, т.к. ядреный и X-овый модуль должны быть одной версии.
(In reply to comment #5) > кто wrapper писать будет? я отказываюсь реанимировать эту страшилку Но, вообще, libGLwrapper шел в комплекте с XFree86, т.е. отказаться у тебя правов нету :-( А помощи просить никто не запрещает :-)
в код его загляни, страшное зрелище.
(In reply to comment #10) > в код его загляни, страшное зрелище. Не, ну в самом деле, нельзя так пугать... :-( Тут на самом деле есть проблема курицы и яйца - что грузится раньше, модуль ядра или libGL? И как определить нужную версию libGL в пределах одной ветки? Можно попробовать совместить все три варианта - libGLwrapper + файл специального вида (или переменная окружения) создаваемый при старте X или в post-install модуля.
(In reply to comment #11) [...] > проблема курицы и яйца - что грузится раньше, модуль ядра или libGL? или грузить ли apggart (для nvidia), но это не слишком актуально, т.к. проблем замечено не было (дома GF-MX440 + i815 без arpgart, на работе GF-MX440 + BX440)
давайте вернемся в начало треда... что получается: libGLwrapper с его ужасной и непредсказуемой логикой возрождать не будем post-install тоже не трогаем остается вызов скрипта при загрузке иксов.
(In reply to comment #13) > остается вызов скрипта при загрузке иксов. Ну вообще было бы неплохо эту процедуру запихать в init иксового драйвера... Версия в этот момент известна. Что-то типа nvidia-common выставляет линки на правильные иксовые драйвера (в соответствии с ядерным), а иксовый драйвер выбирает нужную libGL... Правда не знаю на сколько это реально сделать с binary-only дровами...
Fixed in fglrx_glx-8.12.10-alt3.
