Не минуло багато часу від попереднього, як AMD порадувала новою версією драйверів для відеокарт.
Правда підтримки 2.6.30 все ще нема (незважаючи на протилежні заяви від ЛОРу)...
Чекаємо.
пʼятниця, 19 червня 2009 р.
субота, 30 травня 2009 р.
Vuze + Flash
Однією з особливостей Лінакс, яка мені страшно подобається - це автоматичне поновлення пакунків. Правда в деяких випадках це не надто зручно, особливо, коли поновлення в дистрибутиві відстає від офіційного поновлення. Правда в цьому випадку все-одно зручніше дистрибутивне поновлення, в якому "вилизуються" помилки.
Сьогодні припекло поставити Vuze (колишній azureus). Поставити з дистрибутиву - не складно, от тільки в дистрибутиві версія 3 з хвостиком, а на офіційному сайті 4.2... Тому було прийнято Соломонове рішення про ручне поновлення, що і було зроблено протягом найближчих кількох хвилин.
Перші граблі - завантажений vuze не запускається. Тобто він запускається, і каже, що swt.jar (яка йде в пакунку) лише для 32-розрядних версій. Тобто при завантаженні запитатися не можна було, про те, яка версія в мене встановлена. Ну Бог з вами, виробники vuze відсилають на сторінку swt, і в принципі не залишається нічого іншого, як туди піти.
Уважно читаємо що пише, вибираємо стабільну версію і..... попадаємо на сторінку завантаження Eclipse. Крутимо донизу в пошуках окремого SWT, і завантажуємо свою версію x86_64. Розпаковуємо до теки з vuze (в мене це /opt/vuze) та насолоджуємося запуском.
Наступні граблі - відсутня підтримка flash, який все-таки встановлений в системі. Тут вже на допомогу приходить гугл, і виявляється, що vuze шукає плагін у теці /usr/lib/xulrunner-1.9 . Одразу ж є рекомендація, про створення символічного посилання. От тільки працює вона для 32-розрядних систем. В нашому випадку слід скористатися наступним закляттям:
sudo ln -s /usr/lib/firefox/plugins/npwrapper.libflashplayer.so /usr/lib/xulrunner-1.9/plugins/libflashplayer.so
і перезавантажити vuze.
Дещо буде плисти, але загалом користуватися можна. Всі питання знову ж таки до розробників vuze ;)
Сьогодні припекло поставити Vuze (колишній azureus). Поставити з дистрибутиву - не складно, от тільки в дистрибутиві версія 3 з хвостиком, а на офіційному сайті 4.2... Тому було прийнято Соломонове рішення про ручне поновлення, що і було зроблено протягом найближчих кількох хвилин.
Перші граблі - завантажений vuze не запускається. Тобто він запускається, і каже, що swt.jar (яка йде в пакунку) лише для 32-розрядних версій. Тобто при завантаженні запитатися не можна було, про те, яка версія в мене встановлена. Ну Бог з вами, виробники vuze відсилають на сторінку swt, і в принципі не залишається нічого іншого, як туди піти.
Уважно читаємо що пише, вибираємо стабільну версію і..... попадаємо на сторінку завантаження Eclipse. Крутимо донизу в пошуках окремого SWT, і завантажуємо свою версію x86_64. Розпаковуємо до теки з vuze (в мене це /opt/vuze) та насолоджуємося запуском.
Наступні граблі - відсутня підтримка flash, який все-таки встановлений в системі. Тут вже на допомогу приходить гугл, і виявляється, що vuze шукає плагін у теці /usr/lib/xulrunner-1.9 . Одразу ж є рекомендація, про створення символічного посилання. От тільки працює вона для 32-розрядних систем. В нашому випадку слід скористатися наступним закляттям:
sudo ln -s /usr/lib/firefox/plugins/npwrapper.libflashplayer.so /usr/lib/xulrunner-1.9/plugins/libflashplayer.so
і перезавантажити vuze.
Дещо буде плисти, але загалом користуватися можна. Всі питання знову ж таки до розробників vuze ;)
субота, 16 травня 2009 р.
Драйвери AMD/ATI 8.612
Я вже писав, що не вірю, у машину часу, але моя думка може змінитися ;).
Підготовка:
Перш за все, слід перейменувати безпечно старі модулі:
sudo mv /usr/src/fglrx.tar.bz2 /usr/src/fglrx.tar.bz2.8602
sudo mv /usr/src/modules/fglrx /usr/src/modules/fglrx.8602
Таке дивне розширення (8602) це версія попереднього драйверу. Поточна версія має порядковий номер 8.612
Отримати нову версію драйверів можна звідси, або ж виконавши в консолі наступну команду:
wget -c http://www2.ati.com/drivers/linux/ati-driver-installer-9-5-x86.x86_64.run
Тепер необхідно встановити права на виконання завантаженого файлу:
chmod 744 ati-driver-installer-9-5-x86.x86_64.run
та згенерувати пакунки для свого дистрибутиву:
sudo ./ati-driver-installer-9-5-x86.x86_64.run --buildpkg Debian/testing
В мене ця операція пройшла без жодних проблем.
Зазвичай я пакую їх до спеціальної теки, щоб потім мати можливість відкотитися на останню стабільну версію:
mkdir -p ati/8.612; mv fglrx*8.612* ati/8.612; cd ati/8.612
Якщо все пройшло успішно Ви повинні б опинитися у теці з драйверами. Запускаємо на встановлення драйвери:
sudo dpkg -i *.deb
І отримуємо готовий результат.
P.S. Дана версія драйверів все ще не сумісна з ядром 2.6.30-rc3
P.P.S. Як виявилося пізніше - версія 8.612 (або 9.5) має проблеми при роботі з відеокартою. Принаймні в мене іграшки, ті, що працювали на 9.4 - не запустилися (wine завершував роботу з помилками доступу до пам'яті), а поновлення версії wine до 1.1.22 не допомогло.
Висновок: Важко сказати, чим ця версія хороша. Можливо все-таки слід почекати до версії 9.6.
Підготовка:
Перш за все, слід перейменувати безпечно старі модулі:
sudo mv /usr/src/fglrx.tar.bz2 /usr/src/fglrx.tar.bz2.8602
sudo mv /usr/src/modules/fglrx /usr/src/modules/fglrx.8602
Таке дивне розширення (8602) це версія попереднього драйверу. Поточна версія має порядковий номер 8.612
Отримати нову версію драйверів можна звідси, або ж виконавши в консолі наступну команду:
wget -c http://www2.ati.com/drivers/linux/ati-driver-installer-9-5-x86.x86_64.run
Тепер необхідно встановити права на виконання завантаженого файлу:
chmod 744 ati-driver-installer-9-5-x86.x86_64.run
та згенерувати пакунки для свого дистрибутиву:
sudo ./ati-driver-installer-9-5-x86.x86_64.run --buildpkg Debian/testing
В мене ця операція пройшла без жодних проблем.
Зазвичай я пакую їх до спеціальної теки, щоб потім мати можливість відкотитися на останню стабільну версію:
mkdir -p ati/8.612; mv fglrx*8.612* ati/8.612; cd ati/8.612
Якщо все пройшло успішно Ви повинні б опинитися у теці з драйверами. Запускаємо на встановлення драйвери:
sudo dpkg -i *.deb
І отримуємо готовий результат.
P.S. Дана версія драйверів все ще не сумісна з ядром 2.6.30-rc3
P.P.S. Як виявилося пізніше - версія 8.612 (або 9.5) має проблеми при роботі з відеокартою. Принаймні в мене іграшки, ті, що працювали на 9.4 - не запустилися (wine завершував роботу з помилками доступу до пам'яті), а поновлення версії wine до 1.1.22 не допомогло.
Висновок: Важко сказати, чим ця версія хороша. Можливо все-таки слід почекати до версії 9.6.
ATI-драйвери версія 9-5
 | Ніколи не вірив у існування машини часу, однак виявляється - вона таки є. Яким чином працює? Ну наприклад, коли треба терміново нову версію драйверів для відеокарти, а на сайті викладена лише версія місячної давності (за що щира подяка команді ATI), слід просто ввести у вікні браузера потрібну версію. Наразі на сайті доступна версія драйверів 9-4, однак можна спокійно завантажити (не чекаючи офіційного повідомлення) версію 9-5 (wget -c http://www2.ati.com/drivers/linux/ati-driver-installer-9-5-x86.x86_64.run) Про результати тестування напишу окремо. |
середа, 11 лютого 2009 р.
Налаштування інтегрованого мікрофону
Мене довгий час непокоїла проблема роботи вбудованого мікрофону, який не працював. Власне він то працював, але для його запуску мені довелося поновити ядро, викачати останні пакунки alsa та увімкнути мікрофон у ноутбуці.
Власне можна обійтися просто увімкненням мікрофону, але хіба ж то вихід для справжнього дослідника? ;)
Зрештою, це не суть важливо. Важливо, що мікрофон таки робочий і за час встановлення я встиг поновити BIOS до версії F.22 (я знаю, що він вийшов ще в листопаді, але в мене руки дійшли тільки тепер :)). Попереджаю одразу, що над BIOS треба почаклувати, щоб запустити давач температури процесора.
Отже, мікрофон налаштовується у аудіо налаштуваннях, а саме (для GNOME):
Тобто все, що слід зробити - це змінити вхідний канал із аналогового входу на цифровий, і мікрофон запрацює. Правда для цього вікно запис слід привести до порядку:
Я увімкнув DAC0 та DAC1 і все запрацювало. Можливо працює і без цього, однак я не пробував.
Власне можна обійтися просто увімкненням мікрофону, але хіба ж то вихід для справжнього дослідника? ;)
Зрештою, це не суть важливо. Важливо, що мікрофон таки робочий і за час встановлення я встиг поновити BIOS до версії F.22 (я знаю, що він вийшов ще в листопаді, але в мене руки дійшли тільки тепер :)). Попереджаю одразу, що над BIOS треба почаклувати, щоб запустити давач температури процесора.
Отже, мікрофон налаштовується у аудіо налаштуваннях, а саме (для GNOME):
Тобто все, що слід зробити - це змінити вхідний канал із аналогового входу на цифровий, і мікрофон запрацює. Правда для цього вікно запис слід привести до порядку:
Я увімкнув DAC0 та DAC1 і все запрацювало. Можливо працює і без цього, однак я не пробував.
пʼятниця, 9 січня 2009 р.
OpenCMS: встановлення
Загорілося дике бажання допиляти/доробити власну сторінку, яка наразі в настільки сирому вигляді, що навіть посилання давати соромно.
Одразу ж спало на гадку використати одну з існуючих CMS (content management system) , для полегшення власного ж життя (чисто теоретично;) ). Тому не довго думаючи, та враховуючи своє "бе" та "фу", які нічим не обгрунтовуються, окрім "хочу так і тільки так", було висунуто наступні вимоги до CMS:
9 січ 2009 13:18:26 org.apache.catalina.core.StandardContext start SEVERE: Error listenerStart 9 січ 2009 13:18:26 org.apache.catalina.core.StandardContext start SEVERE: Context [/opencms] startup failed due to previous errors
Аналіз логів привів до ще однієї загадки:
9 січ 2009 12:12:43 org.apache.catalina.startup.TldConfig tldScanJar
SEVERE: Exception processing TLD META-INF/c-1_0-rt.tld in JAR at resource path /var/lib/tomcat5.5/webapps/opencms/WEB-INF/lib/standard-1.1.2.jar in context /opencms
java.security.AccessControlException: access denied (java.io.FilePermission /usr/share/java/jsp-api-2.0.jar read)
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:342)
at java.security.AccessController.checkPermission(AccessController.java:553)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
at java.lang.SecurityManager.checkRead(SecurityManager.java:888)
at java.util.zip.ZipFile.(ZipFile.java:126)
at java.util.jar.JarFile.(JarFile.java:150)
at java.util.jar.JarFile.(JarFile.java:87)
at sun.net.www.protocol.jar.URLJarFile.(URLJarFile.java:90)
at sun.net.www.protocol.jar.URLJarFile.getJarFile(URLJarFile.java:66)
at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:71)
at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:122)
at sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:150)
at org.apache.xerces.impl.XMLEntityManager.setupCurrentEntity(Unknown Source)
at org.apache.xerces.impl.XMLEntityManager.startEntity(Unknown Source)
at org.apache.xerces.impl.XMLEntityManager.startDTDEntity(Unknown Source)
at org.apache.xerces.impl.XMLDTDScannerImpl.setInputSource(Unknown Source)
at org.apache.xerces.impl.XMLDocumentScannerImpl$DTDDispatcher.dispatch(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
at org.apache.tomcat.util.digester.Digester.parse(Digester.java:1562)
at org.apache.catalina.startup.TldConfig.tldScanStream(TldConfig.java:514)
at org.apache.catalina.startup.TldConfig.tldScanJar(TldConfig.java:472)
at org.apache.catalina.startup.TldConfig.execute(TldConfig.java:307)
at org.apache.catalina.core.StandardContext.processTlds(StandardContext.java:4307)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:4144)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:760)
at org.apache.catalina.core.ContainerBase.access$0(ContainerBase.java:744)
at org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:144)
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:738)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:544)
at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:831)
at org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:720)
at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:490)
at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1217)
at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:293)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:120)
at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1306)
at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1570)
at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1579)
at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1559)
at java.lang.Thread.run(Thread.java:636)
Чергова перевірка прав доступу до файлів та правильності шляхів поставила в глухий кут. Однак на російськомовному форумі в останньому записі було знайдено рішення проблеми:
слід змінити політику доступу до ресурсів, внісши до файлу /etc/tomcat5.5/50user.policy наступний запис:
grant codeBase "file:${catalina.home}/webapps/opencms/-" {
permission java.security.AllPermission;
};
Не знаю наразі, наскільки це правильно з точки зору безпеки, але наразі працює. Буду пробувати колупати далі, однак скидається на те, що це не єдиний варіант вирішення проблеми.
Одразу ж спало на гадку використати одну з існуючих CMS (content management system) , для полегшення власного ж життя (чисто теоретично;) ). Тому не довго думаючи, та враховуючи своє "бе" та "фу", які нічим не обгрунтовуються, окрім "хочу так і тільки так", було висунуто наступні вимоги до CMS:
- База даних PostgreSQL
- Мова - Java
9 січ 2009 13:18:26 org.apache.catalina.core.StandardContext start SEVERE: Error listenerStart 9 січ 2009 13:18:26 org.apache.catalina.core.StandardContext start SEVERE: Context [/opencms] startup failed due to previous errors
Аналіз логів привів до ще однієї загадки:
9 січ 2009 12:12:43 org.apache.catalina.startup.TldConfig tldScanJar
SEVERE: Exception processing TLD META-INF/c-1_0-rt.tld in JAR at resource path /var/lib/tomcat5.5/webapps/opencms/WEB-INF/lib/standard-1.1.2.jar in context /opencms
java.security.AccessControlException: access denied (java.io.FilePermission /usr/share/java/jsp-api-2.0.jar read)
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:342)
at java.security.AccessController.checkPermission(AccessController.java:553)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
at java.lang.SecurityManager.checkRead(SecurityManager.java:888)
at java.util.zip.ZipFile.
at java.util.jar.JarFile.
at java.util.jar.JarFile.
at sun.net.www.protocol.jar.URLJarFile.
at sun.net.www.protocol.jar.URLJarFile.getJarFile(URLJarFile.java:66)
at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:71)
at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:122)
at sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:150)
at org.apache.xerces.impl.XMLEntityManager.setupCurrentEntity(Unknown Source)
at org.apache.xerces.impl.XMLEntityManager.startEntity(Unknown Source)
at org.apache.xerces.impl.XMLEntityManager.startDTDEntity(Unknown Source)
at org.apache.xerces.impl.XMLDTDScannerImpl.setInputSource(Unknown Source)
at org.apache.xerces.impl.XMLDocumentScannerImpl$DTDDispatcher.dispatch(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
at org.apache.tomcat.util.digester.Digester.parse(Digester.java:1562)
at org.apache.catalina.startup.TldConfig.tldScanStream(TldConfig.java:514)
at org.apache.catalina.startup.TldConfig.tldScanJar(TldConfig.java:472)
at org.apache.catalina.startup.TldConfig.execute(TldConfig.java:307)
at org.apache.catalina.core.StandardContext.processTlds(StandardContext.java:4307)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:4144)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:760)
at org.apache.catalina.core.ContainerBase.access$0(ContainerBase.java:744)
at org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:144)
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:738)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:544)
at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:831)
at org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:720)
at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:490)
at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1217)
at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:293)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:120)
at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1306)
at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1570)
at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1579)
at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1559)
at java.lang.Thread.run(Thread.java:636)
Чергова перевірка прав доступу до файлів та правильності шляхів поставила в глухий кут. Однак на російськомовному форумі в останньому записі було знайдено рішення проблеми:
слід змінити політику доступу до ресурсів, внісши до файлу /etc/tomcat5.5/50user.policy наступний запис:
grant codeBase "file:${catalina.home}/webapps/opencms/-" {
permission java.security.AllPermission;
};
Не знаю наразі, наскільки це правильно з точки зору безпеки, але наразі працює. Буду пробувати колупати далі, однак скидається на те, що це не єдиний варіант вирішення проблеми.
пʼятниця, 14 листопада 2008 р.
Драйвери AMD/ATI 8.552
Так вже повелося, що AMD щомісяця в районі 15-го числа випускає нові драйвери. Не став винятком і листопад, а тому 14-го числа, себто сьогодні, було анонсовано про випуск нової версії.
Власне, причина, яка мене надихнула на перевірку пакунку є саме ядро 2.6.27, яке бачить мою бездротову картку від Atheros 6007 і бажання перевірити чи справді все так гладко.
Що ж нас чекає в новій версії:
- перша і дуже бажана річ - підтримка X.org версії 7.4 (для тих, в кого вони є, але хто не має Убунти).
- друга річ - це підтримка ядер серії 2.6.27 (у попередній версії вони не підтримувалися, хоча згідно документації все повинно було працювати).
Власне, причина, яка мене надихнула на перевірку пакунку є саме ядро 2.6.27, яке бачить мою бездротову картку від Atheros 6007 і бажання перевірити чи справді все так гладко.
Тому починаємо тестування із завантаження пакунку та створення на його основі пакетів для Debian.
З під адміністратора запускаємо генерацію пакунків для Дебіан:
# ./ati-driver-installer-8-11-x86.x86_64.run --buildpkg Debian/testing
та отримуємо перший глевкий шматок:
dpkg-shlibdeps: failure: couldn't find library libfglrx_gamma.so.1 needed by debian/fglrx-driver/usr/bin/fglrx_xgamma (its RPATH is '').
Note: libraries are not searched in other binary packages that do not have any shlibs or symbols file.
To help dpkg-shlibdeps find private libraries, you might need to set LD_LIBRARY_PATH.
dh_shlibdeps: command returned error code 512
Однак справжні лінуксоїди (вб'ю того, хто надумав обзивати їх гіками (англ. "придурки")) так просто не здаються ;) Тому розпаковуємо архів до теки ati_deb
# ./ati-driver-installer-8-11-x86.x86_64.run --extract ati_deb
Після цього, скориставшись порадою, переходимо до теки ati_deb/arch/x86/usr/X11R6/lib та копіюємо файл, змінюючи йому назву (кажуть можна створити символьне посилання, але то вже на любителя):
# cp libfglrx_gamma.so.1.0 libfglrx_gamma.so.1
Аналогічно робимо для 64-х розрядних бібліотек:
# cd ../../../../x86_64/usr/X11R6/lib64/
# cp libfglrx_gamma.so.1.0 libfglrx_gamma.so.1
Повертаємося до "кореневої" теки
# cd ../../../../../
і тут нас чекає найцікавіше. Скрипт ati-installer.sh не хоче запускатися, тобто він запускається, але не знає навіщо:
# ./ati-installer.sh --buildpkg Debian/lenny
==================================================
ATI Technologies Linux Driver Installer/Packager
==================================================
Unrecognized parameter 'Debian/lenny' to ati-installer.sh
Проблема в тому, що для розуміння наших бажань він готовий зробити все, що ми вкажемо в третьому параметрі (першим вважається файл ati-installer.sh). Тобто третім параметром має бути --buildpkg Debian/lenny, а другим, що забажаєте. Я запропонував вивести довідку по роботі з встановлювачем, і він мене зрозумів ;) :
# ./ati-installer.sh --help --buildpkg Debian/lenny
==================================================
ATI Technologies Linux Driver Installer/Packager
==================================================
Generating package: Debian/lenny
Package /home/distr/Drivers/ati/fglrx-driver_8.552-1_amd64.deb has been successfully generated
Package /home/distr/Drivers/ati/fglrx-driver-dev_8.552-1_amd64.deb has been successfully generated
Package /home/distr/Drivers/ati/fglrx-kernel-src_8.552-1_amd64.deb has been successfully generated
Package /home/distr/Drivers/ati/fglrx-amdcccle_8.552-1_amd64.deb has been successfully generated
Тепер встановлюємо пакунки:
# cd../; dpkg -i *.deb
завантажуємо асистента модулів (module-assistant, m-a) та встановлюємо необхідний модуль.
Перевіряємо доступність модуля:
# modprobe fglrx
fglrx: module license 'Proprietary. (C) 2002 - ATI Technologies, Starnberg, GERMANY' taints kernel.
[fglrx] Maximum main memory to use for locked dma buffers: 3556 MBytes.
[fglrx] vendor: 1002 device: 9612 count: 1
[fglrx] ioport: bar 1, base 0x5000, size: 0x100
pci 0000:01:05.0: power state changed by ACPI to D0
pci 0000:01:05.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
pci 0000:01:05.0: setting latency timer to 64
[fglrx] PAT is enabled successfully!
[fglrx] module loaded - fglrx 8.55.2 [Oct 28 2008] with 1 minors
Прописуємо модуль для встановлення:
# cat >> /etc/modules
fglrx
та вносимо зміни до налаштувань X сервера, з врахуванням можливості підключення другого монітору:
# aticonfig --initial=dual-head --screen-layout=above
Перезавантажуємось та насолоджуємось новим виглядом.
Згідно даних fgl_glxgears маємо наступну швидкодію:
$ fgl_glxgears
Using GLX_SGIX_pbuffer
2530 frames in 5.0 seconds = 506.000 FPS
2715 frames in 5.0 seconds = 543.000 FPS
2699 frames in 5.0 seconds = 539.800 FPS
3471 frames in 5.0 seconds = 694.200 FPS
У TuxRacer у повноекранному режимі (1280х800) з максимальними налаштуваннями маємо 68-73 кадри/сек.
Висновок: Незважаючи на невеличкі костилі, працює дуже добре. Наразі нарікань (за перші 5 хвилин запуску) немає.
Підписатися на:
Дописи (Atom)