Разработчики Alex Deucher и Michel Dänzer из компании AMD совместно с David Airlie из Red Hat планируют (http://lists.x.org/archives/xorg-driver-ati/2012-June/023104...) убрать поддержку устаревшего метода переключения видеорежимов на пользовательском уровне (UMS - User Mode Setting) из драйвера Radeon. Напомним, что ранее поддержка UMS была прекращена в драйверах Intel и Nouveau. Предположительно, начиная с версии xf86-video-ati-7.0.0 драйвер будет поддерживать переключение видеорежимов только через более современный интерфейс KMS (Kernel Mode Setting), работающий через модуль на уровне ядра ОС.
К сожалению, в настоящее время KMS-модули реализованы только для Linux. Пользвоатели других систем, таких как Solaris и *BSD, будут вынуждены пользоваться устаревшими драйверами, в которых ещё поддерживается UMS. Одним из главных недостатков UMS является необходимость наличия прав суперпользователя для работы драйвера, при KMS все привилегированные операции выполняются в отдельном модуле и поэтому X-сервер может быть изначально запущен с привилегиями обычного пользователя. Там не менее, фактически поддержка UMS оставалась в драйвере Radeon лишь формально, так как последнее время поддержка новых видеокарт добавлялась только в DRM/KMS модуль ядра и не была доступна через UMS.
URL: http://www.phoronix.com/scan.php?page=news_item&px=MTEyMDI
Новость: https://www.opennet.ru/opennews/art.shtml?num=34109
> Одним из главных недостатков UMS является необходимость наличия прав суперпользователя для работы драйвера, при KMS все привилегированные операции выполняются в отдельном модуле и поэтому X-сервер может быть изначально запущен с привилегиями обычного пользователя.Хорошо у вас там в Линуксе. Нам, BSDшникам, такое только сниться может
и другим альтернативщикам для альтернативы.
переползайте :)
> Хорошо у вас там в Линуксе. Нам, BSDшникам, такое только сниться можетУвы, слоупоки BSDшники. Нормальный вариант: всем кому не пофиг на десктоп допиливают KMS. Ибо семеро одного не ждут. Если разработчики дров решили что они хотят работать с вон тем интерфейсом - ну значит вот так вот.
Ты так говоришь, будто причастен к разработке KMS в Линуксе. Ну нравися человеку BSD, ты зачем бахвалиться перед ним чужими заслугами?
> Ты так говоришь, будто причастен к разработке KMS в Линуксе. Ну нравися
> человеку BSD, ты зачем бахвалиться перед ним чужими заслугами?*бахвалишься
Очевидно же - из-за подростковых комплексов.
> Ты так говоришь, будто причастен к разработке KMS в Линуксе.Я всего лишь выступаю Капитаном очевидностью. Про причастность вы сами домыслили.
> всем кому не пофигэто кто ж?
> это кто ж?А вот это мы как раз и "будем посмотреть". Кто не забьет - тому и не пофиг. Это же элементарно, Ватсон!
Ну то есть если разработчики дров решили, что будут поддерживать только WDK, то семеро одного не ждут, так?
А что такое - WDK?
> А что такое - WDK?https://www.google.ru/search?ix=acb&sourceid=chrome&client=u...
>Ну то есть если разработчики дров решили, что будут поддерживать только WDK, то семеро одного не ждут, так?так.
если это разработчики открытых(!!) дров для открытого(!!!) wdk.осталось только дождаться открытого wdk, убедиться что это действительно лучшая из имеющихся технологий реализаций дров для видео и потом портировать её в ядро и меса.
>> Одним из главных недостатков UMS является необходимость наличия прав суперпользователя для работы драйвера, при KMS все привилегированные операции выполняются в отдельном модуле и поэтому X-сервер может быть изначально запущен с привилегиями обычного пользователя.
> Хорошо у вас там в Линуксе. Нам, BSDшникам, такое только сниться можетНу да. :)) А купить видеокарту NVIDIA не судьба, если для новой чудо-интеграшки от AMD xf86-video-ati больше не подойдёт?
> Ну да. :)) А купить видеокарту NVIDIA не судьба,А потом обломаться, если это была openbsd, netbsd или что там еще, ага.
>А купить видеокарту NVIDIA не судьбаи как это поможет, цитата, "и поэтому X-сервер может быть изначально запущен с привилегиями обычного пользователя"?
оппонент то прямо сказал именно это, не чтобы хоть как-то заработало.
NVIDIA и AMD почему-то в проприетарных драйверах, которые работают более эффективно, нежели свободные, не делают поддержку KMS. Странно, почему? Контроль эффективности жизненного цикла софтверной составляющей? Чтобы качество открытых драйверов всегда было заведомо ниже, чем проприетарных для одного и того же оборудования?
> NVIDIA и AMD почему-то в проприетарных драйверах, которые работают более эффективно, нежели свободные, не делают поддержку KMS. Странно, почему?Я бы предположил, что из-за того, что в этом случае большую часть кода придется держать в модуле ядра, и нет простого способа его спрятать в блобе.
gplпроблемы же.
Проблемы не только с gpl, скорее даже они особо с gpl не связаны.Дело в том, что при использовании KMS весь код связанный с переключением видео-режимов работает в режиме ядра, так что необходимо учитывать вопросы связанные с распределением памяти (просто s/malloc/kalloc не сработает), поддерживать новые API drm.ko и drm_fb_helper/drm_crtc_helper/drm_kms_helper, и оперативно реагировать на изменение API/ABI (что меняется довольно часто, увы). Ну и, конечно, поддерживать интеграцию с framebuffer на более низком уровне.
В случае UMS - тот код, что работал раньше, продолжит работать и при обновлении ядра, так как он от ядра не зависит (сервер/ddx обращаются напрямую к графической памяти), и можно использовать все плюшки которые есть в userspace. Но он сломается когда поменяется X server (что в ближайшем будущем и произойдет, когда патчи от airlied войдут в иксы).
Так что для перехода на KMS придется переписать бОльшую часть кода связанную с modesetting, подготовить ее для совместимости с ядром (через #ifdef'ы и тому подобные вещи, чтобы учитывать различные внутренности drm/kms api), и открыть бОльшую часть кода чем сейчас - как минимум для работы с i2c и sysfs - которые для KMS-based драйверов весьма даже нужны). Увы, в закрытых драйверах этого не будет.
В случае с BSD наблюдаются похожие проблемы, разве что кода открывать можно меньше. Но все что связано с modesetting'ом придется переписывать в любом случае. И я бы даже предположил что шансы получить KMS в *BSD в закрытых драйверах даже меньше чем под линуксом, так как детали работы видео-режимов в них сильнее отличаются...
Он разбирается поболее тебя
> NVIDIA и AMD почему-то в проприетарных драйверах, которые работают более эффективно, нежели
> свободные, не делают поддержку KMS. Странно, почему?Потому что сильно переделывать закрытый блоб им лениво.
>NVIDIA и AMD почему-то в проприетарных драйверах, которые работают более эффективноэто что, такой поверхностный взгляд бздишнега?
открытые дрова уже давно работают лучше и безопасней.
другое дело что открытая реализация опенжл - меса - не дотягивает до проприетарных реализаций.
а опенжл ни разу не дрова.что это означает на практике - открытые дрова на десктопе ведут себя лучше, пока не запускаешь игры.
ты запускаешь игры, айзен?просто для примера - возьмите любой ливсд, где есть дрова нвидиа и новьё.
и те, и те рабоатют сносно из коробки, но.
если грузится с новьё, то грузится уже в нормальном графическом режиме, не переключает эти режимы, грузится быстрее и после загрузки ест озу на 25-30% меньше.
результат - комфортность работа в любой ДЕ - одинаков.
>>NVIDIA и AMD почему-то в проприетарных драйверах, которые работают более эффективно
> это что, такой поверхностный взгляд бздишнега?У меня интеграшка NVIDIA GeForce 6150 с проприетарным драйвером и интеграшка AMD 785G с открытым драйвером xf86-video-ati 6.14.3. Разницы межде ними не чувствую.
> открытые дрова уже давно работают лучше и безопасней.
Безопасность в чём выражается? Открытый драйвер для NVIDIA xf86-video-nouveau 0.0.10.20090728 ломает бинарную совместимость обновлённых и готовых к распространению на AMD-машине пакетов libdrm и dri. Они расходятся по версиям. С проприетарным драйвером ничего такого не происходит — можно держать для обеих машин одну и ту же пакетную базу.
> другое дело что открытая реализация опенжл - меса - не дотягивает до
> проприетарных реализаций.
> а опенжл ни разу не дрова.
> что это означает на практике - открытые дрова на десктопе ведут себя
> лучше, пока не запускаешь игры.
> ты запускаешь игры, айзен?Казуальные, разве что.
Когда стояла ОС с архитектурой [i386], то в WINE запускал Counter-Strike 1.6 и Comanche4. Вполне сносно работали в полный экран на проприетарном драйвере NVIDIA. На открытом драйвере не помню, чтобы сносно работало — разве что в окне 800x600 тянуло еле-еле.
>У меня интеграшка NVIDIA GeForce 6150 с проприетарным драйвером и интеграшка AMD 785G с открытым драйвером xf86-video-ati 6.14.3. Разницы межде ними не чувствую.цена таже. свежесть железа?
>Безопасность в чём выражается? Открытый драйвер для NVIDIA xf86-video-nouveau 0.0.10.20090728 ломает бинарную совместимость обновлённых и готовых к распространению на AMD-машине пакетов libdrm и dri. Они расходятся по версиям. С проприетарным драйвером ничего такого не происходит — можно держать для обеих машин одну и ту же пакетную базу.безопасность выражается в безопасности.
а в неспособности айзена скомпилить бздю под каждую систему.
ваш КО.
>Казуальные, разве что.именно.
>в WINE запускал Counter-Strike 1.6 и Comanche4. Вполне сносно работали в полный экран на проприетарном драйвере NVIDIA. На открытом драйвере не помнюпоставь в проприетарном драйвере nvidia в качестве opengl реализацию mesa и осознай разницу опенжл от драйверов.
хинт:
# eselect opengl list
Available OpenGL implementations:
[1] nvidia *
[2] xorg-x11
а дрова то сами по себе отличные.
>>У меня интеграшка NVIDIA GeForce 6150 с проприетарным драйвером и интеграшка AMD 785G с открытым драйвером xf86-video-ati 6.14.3. Разницы межде ними не чувствую.
> цена таже. свежесть железа?2006 и 2010 год, соответсвенно.
>>Безопасность в чём выражается? Открытый драйвер для NVIDIA xf86-video-nouveau 0.0.10.20090728 ломает бинарную совместимость обновлённых и готовых к распространению на AMD-машине пакетов libdrm и dri. Они расходятся по версиям. С проприетарным драйвером ничего такого не происходит — можно держать для обеих машин одну и ту же пакетную базу.
> безопасность выражается в безопасности.В чём-чём, простите?
> а в неспособности айзена скомпилить бздю под каждую систему.
> поставь в проприетарном драйвере nvidia в качестве opengl реализацию mesa и осознай разницу опенжл от драйверов.Как поставить? Куда поставить? У NVIDIA блоб подменяет собой реализацию OpenGL-библиотек Xorg. Без этого либо не загрузится графический режим, либо будет медленно и печально тормозить (случалось после установки NVIDIA Driver и пересборки пакетов Xorg с ключом "-f").
> хинт:
> # eselect opengl list
> Available OpenGL implementations:
> [1] nvidia *
> [2] xorg-x11
> а дрова то сами по себе отличные.Ни о чём.
>> цена таже. свежесть железа?
>2006 и 2010 год, соответсвенно.а цена - таже!
сейчас :D>Как поставить? Куда поставить? У NVIDIA блоб подменяет собой реализацию OpenGL-библиотек Xorg.
ДА!!!!!!!!!!!!!! :D
...................
>Ни о чём.понятно.
понятно что вам не понятно, что в ситеме может быть несколько реализаций опенжл.
зыж
>понятно что вам не понятно, что в ситеме может быть несколько реализаций опенжл.и их можно преключать по ходу. и даже без перезагрузки. :D
>случалось после установки NVIDIA Driver и пересборки пакетов Xorg с ключом "-f"небось перегружался? :D
iZEN, похоже что ты и во FreeBSD не разбираешься :)))
Конечно, не разбирается. Он обычный юзер, к-й думает что он умнее остальных
А в чем плюсы ? Система полностью не упадет если что заглючит при переключении ? Блымкание экрана пропадет ?
> А в чем плюсы ? Система полностью не упадет если что заглючит
> при переключении ? Блымкание экрана пропадет ?1. Можно запускать иксы не от рута.
2. Переключение на уровне ядра работает быстрее, чем за его пределами (user space)
Переключение чего?
> Переключение чего?Видео-режимов (т.е., с 1024x768@60 на 1920x1200@60 например).
>> Переключение чего?
> Видео-режимов (т.е., с 1024x768@60 на 1920x1200@60 например).Оно часто требуется? У вас пиксельное поле на мониторе резиновое или мониторы с различным разрешениями переподключаете постоянно?
> Оно часто требуется? У вас пиксельное поле на мониторе резиновое или мониторы
> с различным разрешениями переподключаете постоянно?Ну это мы вернулись практически к дискуссии о systemd. Нет, это нужно не часто, и компьютеры тоже достаточно перезагружать раз в год, и вообще одного разрешения более чем достаточно для всех программ и мониторов. Жаль только что многие пользователи с этим не согласны и все требуют и требуют и более быстрого запуска, и более быстрого переключения режимов.....
Хотя на будущих ips panels будет только одно разрешение, что не может не радовать :).
> Хотя на будущих ips panels будет только одно разрешение, что не может
> не радовать :).Век ЭЛТ поддерживающих произвольные разрешения давно закончился, а на LCD мониторах и сейчас одно стандартное разрешение, зачем его в процессе работы переключать на ухудшенный вариант с масштабированием пикселей?
Вся малтимедия требует переключения - под размер кадра
> Видео-режимов (т.е., с 1024x768@60 на 1920x1200@60 например).80*25*9*16@75 забыл, BIOS не вспомнил... //Ну, за МС и ЮЕФИ его, вздрогнем!
э ну теперь уже ни в чём это продолжение дел натвореных 2 года назад когда фактически прекратилась работа над умс.
Когда подключаю к ноутбуку телевизор по HDMI, оба экрана заполняются мусором. С параметром ядра nomodeset такого нет.Никогда не понимал, зачем понадобилось тащить бяку в ati из intel. Чтобы получить убийственное преимущество перед закрытым драйвером "зато у нас переключение в терминал без мерцания экрана!"?
> Никогда не понимал, зачем понадобилось тащить бяку в ati из intel.Ограниченность - она такая, да. Совет - почитай на досуге, зачем.
> параметром ядра nomodeset такого нет.Поэтому давайте из какого-то 1 бага конкретной конфигурации сделаем глобальные выводы?
> Никогда не понимал, зачем понадобилось тащить бяку в ati из intel.
У интела вообще-то один из наиболее симпатичных драйверов. И кстати в этом мире существует не только ваш ноут и вы, а ваше мнение о качестве драйверов не является истиной в последней инстанции. Рекомендую подумать над этим.
> Чтобы получить убийственное преимущество перед закрытым драйвером "зато у нас
> переключение в терминал без мерцания экрана!"?1) Разработчики не желают использовать устаревший интерфейс. Вы им будете диктовать как им и что программить? Попробуйте, а я посмотрю как это получится.
2) Натурально, переключение режима быстрее. И не только это. В целом тенденция такова что в ядре есть небольшие выноски обеспечивающие самые низкоуровневые и базовые операции с видяхами, которые дергаются из остальных мест. В принципе это довольно разумный вариант. Это и быстрее и прямее.
3) И это позволяет не держать здоровенный сервер иксов с правами рута. Учитывая размеры оного - то что в нем будут баги вполне ожидаемо. А баги в процессе работающем от рута - это плохо. Мелкие выноски обезжучить явно проще чем здоровенный процесс.
> 2) Натурально, переключение режима быстрее. И не только это. В целом тенденция
> такова что в ядре есть небольшие выноски обеспечивающие самые низкоуровневые и
> базовые операции с видяхами, которые дергаются из остальных мест. В принципе
> это довольно разумный вариант. Это и быстрее и прямее.
> 3) И это позволяет не держать здоровенный сервер иксов с правами рута.
> Учитывая размеры оного - то что в нем будут баги вполне
> ожидаемо. А баги в процессе работающем от рута - это плохо.
> Мелкие выноски обезжучить явно проще чем здоровенный процесс.вы не мелочитесь - переносите все видео в ядро. Ведь правильно - Windows не может же ошибаться ?
Это прямее и лучше - потому что это сделано в Windows!
> вы не мелочитесь - переносите все видео в ядро. Ведь правильно - Windows не может же ошибаться ?Это прямее и лучше - потому что это сделано в Windows!
Причем тут винда, клоун? Если это по какой-то причине сделано в винде, это повод полностью отказаться от этого метода, чтобы не быть похожими? К счастью, разработчики драйверов принимают объективные решения.
>вы не мелочитесь - переносите все видео в ядро. Ведь правильно - Windows не может же ошибаться ?
>Это прямее и лучше - потому что это сделано в Windows!Если делать как в венде, то надо иксы в ядро засунуть.
Так что запускать X под рутом идейно ближе к виндовз-вэй, чем переносить в драйвер низкоуровневый функционал, которому там и место.
> Когда подключаю к ноутбуку телевизор по HDMI, оба экрана заполняются мусором. С параметром ядра nomodeset такого нет.Тоже хотел написать, что на нескольких кофигурациях с ATI видео, правда видео старинные были R200 и К300 наблюдались видео глюки подобные описаному выше, и они пропадали когда radeon.modeset=0 включал...
ну это просто повод завести запрос в багтреккере и не более.
недавно приобрёл комп с видео от интеллект .HD 3000 все игры просто летают. а драйвера вкомпилированны в ядро. и кому эта проприетарщина теперь вообще нужна?
> недавно приобрёл комп с видео от интеллект .HD 3000 все игры просто
> летают. а драйвера вкомпилированны в ядро. и кому эта проприетарщина
> теперь вообще нужна?1) У интела кажется не было вообще никаких проприетарных дров под линукс :)
2) Так тут и рассказывается о открытом амдшном драйвере. У него тоже выносок в ядро есть - в общем та же история что и с интелем.А так да, драйвер у интеля вполне позитивный. Ну а второе место я с удовольствием отдаю АМД, у которых видеокарты явно мощнее.
> 1) У интела кажется не было вообще никаких проприетарных дров под линукс :)Были-были -- для недоразумения по имени poulsbo... и дискретная видеокарта у них тоже была :)
> А так да, драйвер у интеля вполне позитивный.
Только подламывают с завидной регулярностью (артефакты лезут), но чинят довольно быстро.