После 6 месяцев разработки анонсирован (http://lists.x.org/archives/xorg-announce/2013-March/002179....) релиз X.Org Server 1.14, который содержит в основном незаметные для конечного пользователя внутренние оптимизации и исправления.Наиболее заметным новшеством является реализация расширения X Input 2.3 (http://who-t.blogspot.ru/2012/12/whats-new-in-xi-23-pointer-...), в котором появилась поддержка определения границ для указателя (pointer barriers) и генерации событий ввода при их пересечении (Pointer Barrier Events). Границы указателя позволяют приложению определять дополнительные ограничения или привязать действия к перемещению курсора в определённую область, что может быть использовано композитными менеджерами и десктоп-окружениями при выводе фиксированных элементов интерфейса в определённой области экрана или для реализации "горячих" углов и краёв экрана, реагирующих на движение (вход или выход) указателя через границы области. Например, В GNOME через определение границ указателя в левом верхнем углу обеспечена возможность быстрого вызова меню, даже при использовании многомониторных конфигураций. В будущем выпуске GNOME 3.8 через использование событий пересечения границ указателя будет обеспечена возможность вызова области сообщений через скользящее касание от края сенсорного экрана, без перемещения курсора в угол.
Вторым важным улучшением является поддержка расширения RandR 1.4 (http://cgit.freedesktop.org/xorg/proto/randrproto/tree/randr...), в котором добавлены свойства для регулировки края области вывода (например, можно задать область вывода меньше актуального размера экрана для компенсации забегания развёртки). В RandR 1.4 также реализованы объекты для выноса на дополнительные GPU операций рендеринга и формирования вывода. Например, обеспечена возможность горячего перенаправления вывода на другое устройство (например, на подключенный видеоадаптер с интерфейсом USB), или в конфигурациях с несколькими GPU использование первого GPU для вывода, а второго для рендеринга, или организации совместного рендеринга на нескольких GPU.
Из других улучшений можно отметить заметное ускорение программного рендеринга, благодаря использованию библиотеки pixman (http://pixman.org/). К сожалению, в состав X.Org Server 1.14 не вошел компонент XWayland (http://www.opennet.me/opennews/art.shtml?num=34118), позволяющий обеспечить запуск обычных X11-приложений поверх Wayland. Интеграция XWayland отложена до выпуска 1.15, который ожидается в сентябре.
URL: http://lists.x.org/archives/xorg-announce/2013-March/002179....
Новость: http://www.opennet.me/opennews/art.shtml?num=36314
Стало быть, X.Org 1.15 будет в следующем релизе Slackware? Ну что же, хорошо-с :)
Слакваристы желают wayland? Wtf? oO
а почему XWayland должен входить в х-сервер если судя по тому что он делает он должен быть в вайленде ? "запуск обычных X11-приложений поверх Wayland"
Чтобы оставшиеся создатели x.org сами там обновляли этот компонент, а Wayland только на него ссылался бы,
Потому что XWayland является X-сервером. X-серверы Xorg, Xnest, Xephyr, Xdmx, Xwayland отличаются, по сути, только способами ввода-вывода.
> Потому что XWayland является X-сервером. X-серверы Xorg, Xnest, Xephyr, Xdmx, Xwayland
> отличаются, по сути, только способами ввода-вывода.А XDirectFB включён в Xorg? DirectFB же, по-сути, аналог Wayland.
>> Потому что XWayland является X-сервером. X-серверы Xorg, Xnest, Xephyr, Xdmx, Xwayland
>> отличаются, по сути, только способами ввода-вывода.
> А XDirectFB включён в Xorg? DirectFB же, по-сути, аналог Wayland.Видимо, команда Xorg по каким-то причинам не хочет его принимать или команда разработчиков XDirectFB не хочет этим заниматься. А вейланд разрабатыавют те же самые люди, что занимаются Xorg-ом. Зачем им себе дополнительный геморрой разводить с поддержкой отдельного патчсета к иксам (XDirectFB, например, таковым и является).
Сложно сказать. Вот вывод в DirectFB вроде бы не включён в Xorg.
Ну? Когда уже наконец можно будет пользоваться всеми этими наворотами типа "горячего перенаправления" или рендеринг на нескольких GPU?
Сколько уже пишется, анонсируется, а всё-равно бамбылбями на примусах пользоваться приходится. А ещё, хотельсь бы наконец заюзать вторую карточку на лаптопе с Hybrid SLI. Пробовал через VirtualGL, но не понравилось. А вот две карточки бы рендерили бы одну картинку бы!
Или это несбыточные мечты?
Не знаю, насколько это готово в открытых дровах, по крайней мере интель пилит. В закрытых - увы...
Как раз таки в закрытом драйвере nvidia утверждает что поддержка уже обеспечена...
... только лицензия не позволяет ...
Если поверить phoronix, это не проблема http://www.phoronix.com/scan.php?page=news_item&px=MTMwMjI
Хм, интересно-интересно. Ещё бы KMS :3
У нвидии всегда был свой собственный KMS с блекджеком и шлюхами, к тому же им ядерный не разрешают использовать - GPL-only.
А кстати, Нвидия везде говорит о примусах. Следовательно на простом компе переключиться на другую карту "на лету" (или объединить две в одну) не получится.
> А кстати, Нвидия везде говорит о примусах. Следовательно на простом компе переключиться
> на другую карту "на лету" (или объединить две в одну) не
> получится.Скоро их PRIME примут в ядро (3.9 вроде обещали) и будет работать.
SLI в Linux вообще-то есть. И всегда был. И Crossfire есть.
окей ждём когда можно будет рендерить на двух видеокартах и инструкций как это сделать
На FreeBSD портировали xorg-server 1.14.
http://blogs.freebsdish.org/graphics/2014/11/19/xserver-1-14.../