LINUX.ORG.RU

Релиз X.Org 7.4 перенесен на более позднее время

 , ,


0

0

Релиз X Server 1.5.0 / X.Org 7.4 вновь перенесен и теперь ожидается в течение мая, что, в свою очередь, блокирует выпуск Linux-дистрибутива Fedora 9, основанного на X.Org 7.4 и отложенного ранее до 13 мая (релиз X.Org 7.4 планировалось выпустить в марте, а потом в конце апреля).

В настоящее время неустраненными остаются около 40 блокирующих релиз ошибок, что может привести к дальнейшей череде переносов релиза на июнь или даже на июль.

К сожалению, релиз не только запаздывает более чем на два месяца, но и будет содержать существенно меньше новшеств, чем планировалось ранее. Так, поддержка Multi-Pointer X (MPX), XGE (X Generic Events), XKB 2, Glucose (новая архитектура акселерации, основанная на OpenGL) и RandR 1.3 будет реализована только в X.Org 7.5.

В X.Org 7.4 ожидаются:

  • переработанные (работа через инфраструктуру XACE) модули для SELinux и Solaris Trusted Extensions;
  • работа с PCI-устройствами через новую библиотеку libpciaccess;
  • оптимизация направленная на уменьшение времени загрузки X-сервера;
  • поддержка DRI2 Direct Rendering, пока только для карт Intel;
  • улучшение поддержки Mac OS X;
  • в x11perf добавлены тесты производительности композитного режима;
  • обновление драйверов, например, xf86-video-ati 6.8.0, xf86-video-intel 2.3.0, xf86-video-nv 2.1.8.
Новость взята с opennet.ru.

>>> Подробности

anonymous

Проверено: JB ()

таки ждём ебилдов. да

AnDoR ★★★★★
()
Ответ на: комментарий от anonymous

>PCI config space не адресуется через память. Он адресуется через порты. Либа же позволяет использовать /proc/bus/pci, /sys и прочие интерфейсы доступа к конфигу. Всё. К iomem и всему остальному - как и раньше, через /dev/mem. Или может сейчас тоже как-небудь через /sys - не знаю, что сегодня в моде. :)

на вменяемых архитектурах т.н. "портов" вообще нет. есть mmio (см википедию). порты - это пережитки говноi386. соотвественно, регистры на pci устройствах имеют с ОЗУ общее адресное пространство. и это правильно. нехрен отдельные контакты для трёх шин (адрес/данные/контроль) в процессоре прокладывать, чтобы реализовать эти самые "порты ввода-вывода".

соотвественно мы достигаем самый быстрый допуск к pci памяти из userspace, сделав mmap на /dev/mem. мы просто получаем указатель на нужное окно и прям туда и пишем. никакие sys, proc или dev по своей структуре не смогут достичь такой скорости, ибо будут постоянно копировать из/в userspace данные, что ведёт к большой потере производительности

swar0g ★★★★
()

А что драйверов radeonhd там не будет??? Вполне уже рабочие уже. Сколько ни тестировал - ни одного глюка.Ни одного пикселя не в нужном месте не видел (как это бывает на свободных драйверах). Лучше без 3D, чем висеть на vesa.

tommy ★★★★★
()
Ответ на: комментарий от tommy

Что, уже допилили? Когда пробовал в последний, не определился монитор...

Про 3D кстати ничего не знаешь, будет ли?

anonymous
()
Ответ на: комментарий от anonymous

Вопрос мне? Я меня 2 монитора на карте Сапфир 2400 PRO. Про 3D надо читать в новостях о выходе radeonhd 1.2 (последний - 1.2.1). Скажу только одно - скорость отрисовки 2D фантастическая. Проприетарному и не снилось.

tommy ★★★★★
()
Ответ на: комментарий от tommy

Заинтересовал, пойду делать git pull. :)

anonymous
()
Ответ на: комментарий от anonymous

И ещё в radeonhd пока нет xv. Но вывод через x11shm спасает. Нормально масштабируется тогда при например проигрывании видео. Скорость нормальная через x11shm.

tommy ★★★★★
()
Ответ на: комментарий от swar0g

> на вменяемых архитектурах т.н. "портов" вообще нет. есть mmio (см википедию). порты - это пережитки говноi386. соотвественно, регистры на pci устройствах имеют с ОЗУ общее адресное пространство. и это правильно. нехрен отдельные контакты для трёх шин (адрес/данные/контроль) в процессоре прокладывать, чтобы реализовать эти самые "порты ввода-вывода".

Не вижу чем это плохо. С точки зрения аппаратуры память и регистры - разные устройства с которыми и работать надо по-разному, ИМХО лучше бы их делали вообще на независимых шинах.

anonymous
()
Ответ на: комментарий от Stalwart

Да не будет никакого второго переноса Федоры из-за иксов. Там как был dev-релиз, так и останется...

Анонимус ссылку просто *ниасилил*...

ZloySergant
()
Ответ на: комментарий от anonymous

а каже блондинок переводить на линукс? они без этих свистелок-перделок работать не могут

anonymous
()
Ответ на: комментарий от swar0g

> сделав mmap на /dev/mem. мы просто получаем указатель на нужное окно и прям туда и пишем

Ошибка в вычислении адресов и кабздец вашей системе. :) Порты всё же ограничивают такие "промахи". Тут хотя бы попадёшь просто в другой регистр той же железяки, а не посреди слова в каком-нибудь совершенно чужом процессе.

anonymous
()

Почти обрадовался, что допилят федору, пока не согрешил и не пошел по ссылке.

Fedora 9 will not be shipping with X.Org 7.4 / X Server 1.5 final, but instead a development pre-release.

One ★★★★★
()

Интересно, когда же они наконец откажутся от клиент-серверной архитектуры, уж больно много проблем она доставляет. Кстати, а существуют ли другие другие реализации графической оболочки кроме Иксов?

anonymous
()
Ответ на: комментарий от anonymous

А есть аналог Х-ксов?

Или только это единственная альтернатива?

Windows - не предлагать!!!

:)

anonymous
()
Ответ на: комментарий от anonymous

"...Unlike previous display protocols, X was _specifically_ designed to be used over network connections rather than on an integral or attached display device. X features network transparency: the machine where an application program (the client application) runs can differ from the user's local machine (the display server)."

http://en.wikipedia.org/wiki/X_Window_System

на той же странице ответы и на другие вопросы

filin ★★
()
Ответ на: комментарий от tommy

>Лучше без 3D, чем висеть на vesa.

Это еще пол беды, а то на ноутах бывает что даже с vesa не работают ATI'шные видюхи.

TheMixa ★★★
()
Ответ на: комментарий от filin

>X was _specifically_ designed to be used over network connections rather than on an integral or attached display device.

Вот-вот, осталось узнать, когда появится графическая оболочка was _specifically_ designed to be used locally. Ибо сейчас такая возможность нужна лишь в очень ограниченном круге задач. Почему ради удобства единиц должны страдать все?

anonymous
()
Ответ на: комментарий от anonymous

>Почему ради удобства единиц должны страдать все?

а кто страдает от сетевой прозрачности иксов, дети в африке чтоль?

Muromec ☆☆
()
Ответ на: комментарий от Muromec

>а кто страдает от сетевой прозрачности иксов, дети в африке чтоль?

Страдают юзеры от тормознутости клиент-серверной архитектуры. Страдают разрабы тулкитов, которым приходится идти на всякие ухищирения, лишь бы свести к минимуму обмен данными между клиентом и сервером. Почитай хотя бы топик о выходе qt 4.4..

anonymous
()
Ответ на: комментарий от anonymous

>Вот-вот, осталось узнать, когда появится графическая оболочка was _specifically_ designed to be used locally.

Во первых, такая уже есть. Причем она даже не треует перекомпиляции приложений,поскольку повторяет abi иксов.

Но если она станет мейнстримом, то линукс потеряет довольно важное преимущество - сетевую прозрачность.

AVL2 ★★★★★
()
Ответ на: комментарий от AVL2

>Во первых, такая уже есть. Причем она даже не треует перекомпиляции приложений,поскольку повторяет abi иксов.

А можно линк на эту безымянную оболочку? :)

anonymous
()
Ответ на: комментарий от AVL2

>Но если она станет мейнстримом, то линукс потеряет довольно важное преимущество - сетевую прозрачность.

Не обязательно. Если abi этой оболочки полностью повторяет иксовый, то что мешает админам ставить у себя xorg вместо неё? А на обычном локалхосте такая прозрачность абсолютно не нужна.

anonymous
()
Ответ на: комментарий от anonymous

>Не обязательно. Если abi этой оболочки полностью повторяет иксовый, то что мешает админам ставить у себя xorg вместо неё?

во первых, один из них сразу перестанет развиваться, как тупиковая ветвь, а во вторых, когда будут нужны сетевые возможности, ставить xorg будет уже поздно.

AVL2 ★★★★★
()
Ответ на: комментарий от AVL2

>во первых, один из них сразу перестанет развиваться, как тупиковая ветвь

Вряд ли, особенно если учитывать, что у них несколько разные ниши. Вон xfree до сих пор развивается, хотя ни в одном известном дистре линукса он уже не используется.

>а во вторых, когда будут нужны сетевые возможности, ставить xorg будет уже поздно.

А почему будет поздно поставить xorg и заменить в запускаемых сервисах microxwin на xorg?

anonymous
()
Ответ на: комментарий от tommy

>и кернел модуль там вообще зачем.

Они засунули ядро гуи в кернел, как в винде. К тому же, насколько я понял, этот модуль ещё и закрытый..

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.