ATI+Fedora17 и желание посмотреть фильмы в хорошем качестве с привычной скоростью

[@lohmat]

Я так понял, что у Вас получилось собрать rpm-пакет, может, его тоже выложить?

[@paran01k]

Добавил.

[@cepreu4habr]

Да… Помню сидел на Fedora раньше, чувствовал себя настоящим джедаем. Столько знаний по Linux'у получил пока проблемы решал… А потом перешел на Ubuntu и почувствовал себя человеком. Ну или почти человеком…

[@ArtKun]

Чувствую то же самое, только перейдя с Ubuntu на Fedora :)

[@Godless]

я вот тоже перевел домашний серв с федоры на убунту лтс. И… немного жалею. Но стабильность важнее. На IBM System X3200 M2 федора 18 то не хотела грузиться из-за странной ошибки об инициализации ERST (помог erst_disable в grub), то не хотела нормально перезагружаться уходя в panic.
На убунту некоторые пакеты по-старее будут, но пока ни одного бага с оборудованием…

оффтоп

получается я изменил ей?..

[@ArtKun]

А почему нельзя было просто обновиться до F18? Там как минимум 13.1 есть в репозиториях.

[@paran01k]

Для меня, прежде всего, важна стабильная работа. Поставив 18 релиз (в первые дни после выпуска), на моем железе то и дело что-нибудь да отваливалось. Поэтому, я решил немного подождать (пару месяцев) и откатился обратно. Что касается драйвера из репозитория, то canyon писал в своем блоге, что ему не удалось запустить на нем аппаратное декодирование. Правда версия была 12.10, а не 13.1. Может уже и поправили. Вообщем, в тот момент, я искал самый быстрый вариант.

[@ArtKun]

пару месяцев

Зачем так долго? Достаточно просто подождать обновлений ядра. Сейчас там уже 3.7.9 и оно очень стабильно, хотя через пару недель прикатит 3.8, где запросто может что-нибудь снова поломаться.

[@paran01k]

где запросто может что-нибудь снова поломаться.

Так и живем!

[@Voenniy]

Обновился до 18й в первую неделю релиза.
Никаких проблем замечено не было.

[@ArtKun]

А Хром нормально запускался? У меня на всех машинах работал только после переустановки.

[@Voenniy]

я обновил через yum update
Хром вначале отказался запускаться — точно не помню, кажется хотел какую-то другую версию какого-то файла. Я посмотрел, нужная версия на компе была, сделал симлинк на тот файл, на который смотрел хром и все заработало. Там делов на 2 минуты, я даже не придал этому значения, если бы вы сейчас не спросили, я бы даже не вспомнил.

[@ArtKun]

На самом деле, достаточно было простого yum reinstall google-chrome-stable :)

[@ArtKun]

Кстати, проблема с /usr/include/linux/version.h — известный апстримный баг ядра, и в 3.7.9 точно исправлен.

[@rumkin]

Пффф… Делов-то! )

[@norguhtar]

Установщик ругался на отсутствие файла «/lib/modules/3.7.6-102.fc17.x86_64/build/include/linux/version.h». Рекурсивный поиск по папкам нашел «version.h» по адресу «/usr/include/linux/version.h». Убедившись, что этот файл принадлежит текущей версии ядра — я скопировал его по требуемому адресу.

yum install kernel-devel и не надо придумывать ерунды.

[@paran01k]

Ерунду никто и не придумывает. Не знаю как у Вас, а у меня не было этого файла:

$ rpm -ql kernel-headers | grep version.h

/usr/include/linux/dvb/version.h
/usr/include/linux/version.h

$ rpm -ql kernel-devel | grep version.h

/usr/src/kernels/3.7.6-102.fc17.x86_64/include/config/arch/want/compat/ipc/parse/version.h
/usr/src/kernels/3.7.6-102.fc17.x86_64/include/config/isdn/diversion.h
/usr/src/kernels/3.7.6-102.fc17.x86_64/include/config/localversion.h
/usr/src/kernels/3.7.6-102.fc17.x86_64/include/generated/uapi/linux/version.h
/usr/src/kernels/3.7.6-102.fc17.x86_64/include/uapi/linux/dvb/version.h
/usr/src/kernels/3.7.6-102.fc17.x86_64/include/xen/interface/version.h

Вот ссылка на bugzilla, где, хоть и для 3.7.1, но говорится, что файл «version.h» перемещен в "/usr/src/kernels/3.7.6-102.fc17.x86_64/include/generated/uapi/linux/version.h"

[@norguhtar]

У вас ссылка есть такого вида
lrwxrwxrwx. 1 root root 38 февр. 18 08:18 build -> /usr/src/kernels/3.7.8-202.fc18.x86_64

И в fc17 тоже должно быть.

[@paran01k]

Конечно есть. Просто, как видно из лога команды «rpm -ql kernel-devel | grep version.h», файла «include/linux/version.h» в пакете нет. Его переместили, а установщик драйвера по прежнему пытается его найти по старому пути. Поэтому я и набросал скрипт, который правит исходник. Но, согласитесь, он выглядит более громоздко нежели копирование одного файла, который, после сборки, можно удалить.

[@norguhtar]

Лучше исправить в исходнике путь, а не копировать файлы по системе.

[@paran01k]

Уже исправил. How-To добавлен в раздел «UPDATE1».

[@norguhtar]

Ну и да надо класть не сюда файл /lib/modules/3.7.6-102.fc17.x86_64/build/include/linux/ а править исходник. А так вы вот своими действиями отлично загадили систему.

[@paran01k]

Конечно, я понимаю, что это не совсем «true linux way», но так было гораздо быстрее. Хотя, я не думаю, что один заголовочный файл мог сильно загадить систему, тем более, что после сборки модуля его можно удалить. Всё же, что бы дать людям выбор, набросал еще один вариант:

$ wget -c http://www2.ati.com/drivers/linux/amd-driver-installer-catalyst-13.1-linux-x86.x86_64.zip
$ unzip amd-driver-installer-catalyst-13.1-linux-x86.x86_64.zip
$ chmod +x amd-driver-installer-catalyst-13.1-linux-x86.x86_64.run
$ sudo -s
# ./amd-driver-installer-catalyst-13.1-linux-x86.x86_64.run --force
# cp -a /usr/lib/modules/fglrx /usr/lib/modules/fglrx_backup
# for i in `find /lib/modules/fglrx/ -type f`; do cat $i | sed -e "s/linux\/version\.h/generated\/uapi\/linux\/version\.h/g" > ${i}_tmpext; doneup
# for i in `find /lib/modules/fglrx -name '*_tmpext'`; do mv -vf $i `echo $i | sed s/\_tmpext//`; done

# gedit /usr/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c

#ifndef VM_RESERVED
#define VM_RESERVED (VM_DONTEXPAND | VM_DONTDUMP)
#endif

# chmod +x make_install.sh build_mod/make.sh
# cd build_mod
# ./make.sh
# cd ..
# ./make_install
# aticonfig --initial -f
# exit
$ reboot

Всё, вроде, прошло успешно. Только вот перезагружаться боюсь! Ссыкотно.

[@J_o_k_e_R]

И после этого мы — гентушники красноглазики? На стабильной генте вчера за ~15 минут перешел на проприетарный атишный драйвер:
1) vi /etc/portage/make.conf (добавил fglrx в список VIDEO_CARDS)
2) emerge -vabkDuN world
3) eselect opengl set ati
4) aticonfig --intitial
Ребут и профит.

Спасибо за наводку с xvba. Интересно на каких видюхах оно есть. А то у меня медиацентром ноут с каким-то древним радеоном.

[@kreativf]

[шутка] Вы же модуль fglrx в /etc/conf.d/modules не прописали. Непорядок! [/шутка]

[@J_o_k_e_R]

Да я вообще половину утаил. Потом ведь еще в /etc/portage/package.use/x11-drivers_ati-drivers
x11-drivers/ati-drivers disable-watermark вписал, так как в генте признаны стабильными 12.11_beta11.

А fglrx иксы сами грузят. А открытый драйвер radeon, если он используется, у меня вообще dracut из initramfs грузит, чтоб консоль красивенькая была пораньше.

[@paran01k]

Unified Video Decoder, в разделе: «UVD enabled GPUs»

[@braintorch]

Ох. Я прямо вспомнил, как Ubuntu 6.06 ставил и разбирался (и тоже устанавливал драйвера вручную, в то время их ещё в пакетах не предоставляли, кажется). Судя по тому, что автор не знает, что для сборки модуля ядра нужны хедеры или исходники, линуксом он пользуется не так долго. Поэтому есть подозрение, что всё можно было проделать проще и с меньшим количеством драмы. Я, конечно, не знаю, как там в федоре, но всё равно вижу подозрительно много усилий.

[@charon]

вот расстраивает меня такой способ решения банальной пользовательской проблемы. Я тоже когда-то пытался настроить xvba для аппаратного ускорения, но не смог осилить весь путь. Неужели нельзя эту проблему решить попроще и для всех?
Кто-нибудь пробовал использовать xvba в Федора 18, но только с меньшими танцами с бубном?

[@chupkb]

15 экранов текста, чтобы смотреть кино, «как в винде». Это успех.

[@santeri]

симлинки? не, не слышал.

[@paran01k]

Изначально копировался файл, принадлежащий пакету «linux-headers», в директорию, где должен был лежать файл из пакета «kernel-devel». В случае обновления ядра, этот симлинк ссылался бы на совсем другой «version.h». С этой точки зрения — копирование безопасней. Можно, конечно, было сделать симлинк на «version.h» лежащий в "/usr/src/kernels/`uname -r`/include/generated/uapi/linux/". Вариантов много. В «UPDATE1», например, c файлом «version.h» вообще не нужно ничего делать. Поправил исходник и хорошо. При обновлении ядра, не нужно ничего менять. Но опять же, при установке новой версии проприетарного драйвера, придется заново править исходники модуля.

[@santeri]

Понятно. У меня на Федоре была похожая проблема после обновления и установки нового ядра…

[@santeri]

еще интересно сколько часов было потрачено на решение «проблемы» :)

[@paran01k]

Около 4 часов.

[@cawaleb]

Спасибо за подробное описание, скомпилировал рпм для fc18.x86_64. Может кому то пригодится libva-xvba-driver-0.8.0-2.fc18.R.x86_64.rpm. На Lenovo s205 AMD E-300.

[@cawaleb]

Для работы необходимы симлинки описанные в статье.