Представлен (http://lists.freedesktop.org/archives/wayland-devel/2014-Sep...) стабильный релиз протокола, механизма межпроцессного взаимодействия и библиотек Wayland 1.6 (http://wayland.freedesktop.org), а также развиваемого параллельно композитного сервера Weston 1.6. Ветка 1.6 обратно совместима на уровне API и ABI с выпусками 1.x, но дополнительно содержит порцию улучшений, расширяющих возможности протокола и композитного сервера Weston. Следующий выпуск 1.7 запланирован на 13 февраля.Основные новшества Weston 1.6:
- Усовершенствована поддержка протокола xdg-shell. К сожеланию, по сравнению с выпуском 1.5 наблюдается нарушение совместности в поддержке xdg-shell. Протокол xdg-shell предназначен для организации взаимодействия между приложениями и десктоп-окружением, в том числе востребованного для обеспечения полноценной работы GNOME Shell поверх Wayland;
- Добавлен механизм маскировки weston_layer;
- В DRM-бэкенде обеспечено извлечение информации о размере курсора из ядра;
- Поддержка управления частотой повторения ввода символов при удержании клавиши в нажатом положении;
- Реализация wl_display_add_socket_auto() избавлена от необходимости указания сокета при запуске Weston поверх другого экземпляра Weston;
- По умолчанию задействована библиотека
libinput (http://www.freedesktop.org/wiki/Software/libinput/), которая также используется в таких проектах, как Clutter и GNOME. Старый код для работы с устройствами ввода данных пока оставлен в качестве запасного варианта, но его поддержка будет прекращена в выпуске 1.7;
- Добавлены дополнительные настройки для desktop-shell;
- Из коробки обеспечена работа сборочного сценария "make distcheck", не требуя дополнительных манипуляций;- Обеспечено завершение работы Weston, в случае раннего завершения weston-desktop-shell, что позволяет решить проблемы с подвисанием с черным экраном;
- Добавлена опция для принудительного включения numlock при запуске с бэкендами DRM и fbdev;Основные новшества Wayland 1.6:
- В протокол wl_keyboard добавлена информация о частоте повторения ввода;
- В libwayland-client внесены дополнения для обработки ошибок, в частности, приложение теперь может запросить более детальную информации об ошибке протокола;
- В wl_surface добавлено перечисление ошибок;
- В wl_display_add_socket_auto() из состава libwayland-server обеспечен автоматический поиск свободного имени сокета;
- Реализована большая порция новых тестов для 'make check'. Подготовлен фреймворк для упрощения тестирования взаимодействия клиента с сервером;
- Проведена работа над ошибками в коде многопоточности и выставления блокировок;
- Добавлена функция wl_display_roundtrip_queue();
- Прекращено раскрытие глобальной переменной wl_display.Экспериментальная поддержка функционирования поверх Wayland уже доступна в свежих выпусках веток KDE 4 (http://www.opennet.ru/opennews/art.shtml?num=39586) и KDE 5 (http://www.opennet.ru/opennews/art.shtml?num=40206). В GNOME поддержка Wayland также пока носит экспериментальный характер, но в выпуске GNOME 3.14 (http://www.opennet.ru/opennews/art.shtml?num=40424) ожидается (http://blogs.gnome.org/mclasen/2014/09/16/a-wayland-status-u.../) реализация полноценного пользовательского сеанса на основе Wayland, пригодного для реальной работы. В частности, по сравнению с GNOME 3.12 в версии 3.14 появится поддержка раскладок клавиатуры, операций Drag-and-Drop и поддержка сенсорных экранов. За несколькими исключениями, практически решены (https://wiki.gnome.org/Initiatives/Wayland/Applications) проблемы с запуском типовых приложений GNOME при работе поверх Wayland.
В дальнейших выпусках проект GNOME планирует перейти на Wayland в качестве первичной платформы, а разработчики KDE намерены обеспечить работу поверх Wayland не хуже, чем X.Org. Более того, полноценная поддержка работы GNOME поверх Wayland будет обеспечена (http://www.opennet.ru/opennews/art.shtml?num=39738) уже в осеннем выпуске дистрибутива Fedora 21. Полный по умолчанию на Wayland произойдёт (http://www.opennet.ru/opennews/art.shtml?num=40129) не раньше выпуска Fedora 23.Поддержка Wayland также реализована в выпуске проекта Enlightenment E19 (http://www.opennet.ru/opennews/art.shtml?num=40591) и в панели Cairo-Dock (http://www.opennet.ru/opennews/art.shtml?num=40057), а также ожидается в одном из будущих выпусков (http://www.opennet.ru/opennews/art.shtml?num=39106) MATE. Wayland уже используется в мобильных платформах Sailfish (http://www.opennet.ru/opennews/art.shtml?num=38545) и Tizen 3 (http://www.opennet.ru/opennews/art.shtml?num=39930). Кроме существующих систем активно развиваются новые десктоп-окружения, работающее только на базе технологий Wayland - Hawaii (http://www.opennet.ru/opennews/art.shtml?num=38730) и Orbital (http://www.opennet.ru/opennews/art.shtml?num=38934). Для тестирования работы GNOME, KDE и Enlightenment, Hawai и Orbital поверх Wayland развивается (http://www.opennet.ru/opennews/art.shtml?num=39379) специальный Live-дистрибутив Rebecca Black Linux (http://sourceforge.net/projects/rebeccablackos/).
Wayland представляет (http://wayland.freedesktop.org/architecture.html) собой протокол взаимодействия композитного сервера и работающих с ним приложений. Клиенты самостоятельно выполняют отрисовку своих окон в отдельном буфере, передавая информацию об обновлениях композитному серверу, который комбинирует содержимое буферов отдельных приложений для формирования итогового вывода с учётом возможных нюансов, таких как перекрытие окон и прозрачность. Иными словами, композитный сервер не предоставляет API для отрисовки отдельных элементов, а оперирует только с уже сформированными окнами, что позволяет избавиться от двойной буферизации при использовании высокоуровневых библиотек, таких как GTK+ и Qt, берущих на себя работу по компоновке содержимого окон. В настоящее время поддержка прямой работы c Wayland уже реализована для библиотек GTK3+, Qt 5, SDL (начиная с выпуска 2.0.2 (http://www.opennet.ru/opennews/art.shtml?num=39269)), Clutter и EFL (Enlightenment Foundation Library).
В рамках проекта Weston развивается одна из реализаций композитного сервера. В роли композитного сервера также может выступать любой другой продукт, поддерживающий протокол Wayland. Например, в настоящее время ведётся работа по обеспечению поддержки Wayland в KWin. В текущем виде Weston уже вышел за рамки набора примеров для тестирования протокола Wayland, но продолжает позиционироваться как эталонная система, которая может обрастать функциональностью через плагины и дополнения. При этом Weston не будет развиваться как обособленное десктоп-окружение, а будет представлять собой ядро и плагинный API для создания таких окружений, по аналогии с тем, как сервер X.Org лежит в основе современных графических систем. Пользовательские оболочки и расширенные функций управления окнами предлагается реализовывать в форме внешних бэкендов к Wayland.Взаимодействие с аппаратным обеспечением в Wayland/Weston, например, проведение инициализации, переключение видеорежимов (drm modesetting) и управление памятью (GEM для i915 и TTM для radeon и nouveau) графических карт, может производиться напрямую через модуль, работающий на уровне ядра, что позволяет обойтись без привилегий суперпользователя. Композитный сервер Weston может работать не только с использованием DRM-модуля ядра Linux, но и поверх X11 или поверх другого композитного сервера Wayland. Кроме того, развиваются проекты (http://www.opennet.ru/opennews/art.shtml?num=36685) по обеспечению работы поверх графического стека платформы Android.
Для обеспечения выполнения обычных X11-приложений в окружении на базе Wayland используется DDX-компонент XWayland (http://cgit.freedesktop.org/xorg/xserver/tree/hw/xwayland) (Device-Dependent X), похожий по организации работы на Xwin и Xquartz для платформ Win32 и OS X. Поддержку запуска X11-приложений планируется встроить непосредственно в ком...
URL: http://lists.freedesktop.org/archives/wayland-devel/2014-Sep...
Новость: http://www.opennet.ru/opennews/art.shtml?num=40632
>В частности, по сравнению с GNOME 3.12 в версии 3.14 появится поддержка раскладок клавиатуры, операций Drag-and-Drop и поддержка сенсорных экранов.титанические инновации
Речь о гноме поверх вяленого, не о гноме или вяленом отдельно.
Неделю назад поставил на debian hamm- работает как часы, и анимации все офигенно плавные!
хлебом не корми, дай свистоперделки
а мне достаточно безукоризненно быстрой работы менюшек, ресайза окон и тп. Хотя бы на уровне ХР. Х-ы такого дать не могут.
чего? это с его тормозным gdi-й то?
пиндеть хватит.
владельцы свиньи ещё 10 лет назад слюни по компизу пускали.
вы явно не умеете готовить
>Неделю назад поставил на debian hamm- работает как часы, и анимации все офигенно плавные!Не лги, ты не мог этого сделать.
"Hamm is the code name for a former Stable Debian distribution. It was released on July 24th 1998 as Debian GNU/Linux 2.0, It was superseded by Debian/Slink on 09 Mar 1999. "
https://wiki.debian.org/DebianHammЗачем ты здесь лжёшь?
Так когда уже на нём что-то будет или он как EFL?
А где же тот самый скриншот с повернутым диагонально окошком? =) Я думал он есть в каждой новости про Wayland.
Можешь найти его в гуглокартинках.
А есть уже какой-нибудь тайловый wm под сабж?
https://github.com/michaelforney/swc
велосипед
А с блобом невидии это еще не работает?
думаю в момент когда Nvidia сделает поддержку Wayland (очевидно она это сделает поже всех, учитывая что и у RadeonSI и у Intel -- проблем нет) -- то она раструбит эту новость по всем каналам как невиданную инновацию :-)
А что там с миром?
Как всегда - мир в опасности.
Ждем реализацию Wayland на Java с поддержкой JavaFX! Вот тогда GTK с их vala точно на помойку отправится, вместе с Qt и их js :D
Ага, отправятся на помойку точно, но неторопливо, с частыми остановками на сборку мусора.
Прежде чем позорится ты бы хоть почитал о GC в Java,и о том что он там не один.
Это не изменяет факта его присутствия.
Быстрее Rust станет системным языком программирования чем Java захватит мир графики.
Ага расскажи это геймдевелоперам :D
А вы хоть одну нормальную игру на чистой Java видели? Я имею в виду игры уровня Starcraft 2 или Crysis 3, а не тот трэш который называют играми фанбои iPhone или Android. Я не видел ни одной игры, приличной игры, где хоть как-то используется java.
А я говорил не про игры на Java, я говорил про игры на C++ где геймдевелоперам приходится писать собственный GC со всем вытекающими костылями и проблемами с ним.Посмотрите на топовые движки...
> приходится писать собственный GCЗачем? В C++ же можно вставить Boehm GC.
А ты у них спроси, я просто констатирую факт. И более того в некоторых случаях в 3х разных компонентах одного движка есть 3 своих костыльных GC и сделано это не потому что там нужны разные реализации, а потому что он состоит из продуктов которые пилили по отдельности привет Havok и ProjectAnarchy. И эти костыльние GC частенько ведут себя неадекватнейшим образом.
> А ты у них спроси, я просто констатирую факт. И более того
> в некоторых случаях в 3х разных компонентах одного движка есть 3
> своих костыльных GC и сделано это не потому что там нужны
> разные реализации, а потому что он состоит из продуктов которые пилили
> по отдельности привет Havok и ProjectAnarchy. И эти костыльние GC частенько
> ведут себя неадекватнейшим образом.В игровых движка часто можно увидеть собственную реализацину менеджера памяти и как следствие зборщика мусора также. Это потому что С ++ дает достаточно широкие возможности по оптимизации работы с памяти. Стандартный менеджер не дает например такой же скорости поиска свободного сектора в памяти и его последующего резервирования для данных как специализированный.
Идеология плюсов такова "что мы не используем за то не платим".
Может быть нужда геймдевелоперов в GC и есть(хотя учитывая какой треш из багов в играх получается тут скорее проблема качества разработчиков этих игр, а не движков), но не весь код нуждается в GC.
В случае с Java помимо GC мы получаем и оверхед от всего остального добра которое есть в Java. :)
Ок, покажи аналог Eclipse написанного на C++ который имет такой же объем функционала и работает быстрее, хотя о чем я говорю покажи аналог который имет хотя 40% функционала Eclipse. Или аналог Gradle для С++? Да долго можно продолжать, то что С++ работает быстрее с простейшими задачами ничего не значит, ты еще попробуй напиши на нем сложный проект без утечек, гигатонны багов и просаживания производительности на пустом месте. С++ подходит для узкого круга задач где реально нужен низкоуровневый доступ и это явно не про гуй и прочую прикладную хню!И незабывай про JNI, критические моменты всегда можно вынести в С.
>> критические моменты всегда можно вынести в СА можно сделать лучше - всё сделать на C и получить ускорение в несколько процентов.
>> Быстрее Rust станет системным языком программированияАга, да скорей ассемблер станет высокоуровневым, чем Rust станет системным
А вы его каким считаете? Асемблером? Высокоуровневым? Что-то он не тянет не на первого ни на второго.
Вообще время покажет, но как по мне Rust довольно интересен.
Вы правы. Rust слишком высокоуровневый, чтобы быть на ровне с обычными высокоуровневыми языками. Если бы я не знал, что он ещё и компилируется, первым делом бы подумал, что работает или на вм, или на интерпретаторе, ибо синтаксис у него слишком страшный для реального программирования=)
Потрачено.
Я не совсем понимаю трудоёмкость работы и медленность внедрения этого Wayland.
По-сути, это же ПРОТОКОЛ, т.е. соглашение - там не нужно писать простыни кода. Weston - тоже неахти какой монстр (судя по функциям) - берёт уже отрисованное и комбинирует с декорациями window manager'а. Главная-то работа - вот эти "отрисовки" - всякие прямоугольники, шрифты, градиентики...
Такое ощущение, что над тривиальной идеей "юзер-окошки-система" опять навешали кучу абстракций, которые через 10 лет окажутся никому не нужные.
> Я не совсем понимаю трудоёмкость работы и медленность внедрения этого Wayland.Трудоёмкости особой нет, просто Wayland никому по-хорошему не нужен. Что он даст - ну теоретически некоторое увеличение скорости граф. системы за счёт убитой совместимости, изгаженного десктопа (см., например, везде разные заголовки окон, да и другие косяки есть).
Ну и тут ни для кого, кроме RH, где это vendor-lock-in аля systemd, овчинка не стоит выделки. Людей, которым нужны разные оконные менеджеры и совместимость не с 2-мя библиотеками (Qt 5+/Gtk 3+), а с уже давно наработанным и отлаженным софтом этот Wayland не устраивает.
Конечно, можно использовать XWayland, но зачем, если есть просто Xы, а граф. скорость более чем устраивает? Красивая анимация при передвигании окон? Так на мозаичных WM его просто нет. Да и на немозаичных это кроме маргиналов никому не нужно.
> см., например, везде разные заголовки окон, да и другие косяки естьДаже сейчас при иксах убрать декорации окон и нарисовать свои вполне может любое приложение. А даже если каким-то образом насильно запретить сокрытие системных декораций, то приложение такое нормально выглядеть не будет.
Это я так уточнить.
Так как особо не знаю технической стороны, то ни иксов, ни вяленого не поддерживаю.
> Даже сейчас при иксах убрать декорации окон и нарисовать свои вполне может
> любое приложение. А даже если каким-то образом насильно запретить сокрытие системных
> декораций, то приложение такое нормально выглядеть не будет.Может, только это не приветствуется. :-) А в Wayland наоборот. И вот это приветствуется/не приветствуется составляет существенную разницу.
Ну кто же запретит разрабам вырубить декорации? :)
А вообще хромиум вроде как это и делает.Вообще я не вкурсе кто сейчас на самом деле рисует декорации окон, иксы или всё таки оконный менеджер ДЕ, но в случае с вяленым этим должен заниматься композитный менеджер. Что как бы не значит что в вяленом предпочтительнее отбирать возможность рисовать декорации и рисовать их самому.
Плюс как я понимаю в GTK приложениях как и раньше считается правильным использование глобальной темы GTK(хотя это с самого начала выбор разработчика приложения), что в свою очередь позволяет GTK приложения запускаемые в KDE окружении стилизировать как полагается в KDE.Вообще посмотрим что будет.
> Ну кто же запретит разрабам вырубить декорации? :)Никто. Но вам, скажем, тоже на тротуар плевать никто не запрещает. Однако обществом это не приветствуется, поэтому тротуар относительно незаплёванный. Так и с Хами - одно дело, свои декорации возможны, но не приветствуются, поэтому заголовки одинаковы за исключением Хрома, xmms и ещё пары уродов.
> что в вяленом предпочтительнее отбирать возможность рисовать декорации и рисовать их
> самому.Результат-то известен - 5 окон, 3 разных заголовка. См., например, даже последние скрины Enlightenment на Wayland'е.
> Вообще посмотрим что будет.
Унылый пилёжь кода W и засирание кодовой базы Xorg'а всякими кусками от Wayland'а. Мы же на это уже года 3 смотрим. :-)
> Унылый пилёжь кода W и засирание кодовой базы Xorg'а всякими кусками от Wayland'а. Мы же на это уже года 3 смотрим. :-)Я говорю про результат. Который пока отсутствует. Все текущие запуски чего либо поверх вяленого это только девелопмент запуски. Появится релиз чего либо, вот тогда можно будет начинать готовить помидоры и кирпичи, кому что по душе, для запуска в разрабов. :)
> Результат-то известен - 5 окон, 3 разных заголовка. См., например, даже последние скрины Enlightenment на Wayland'е.
Я если честно в своё время не смог найти репозитория в котором бы был этот самый Enlightenment более менее свежей версии. Нагуглить скринов не смог, но полагаю это проблема того что попросту нет дистрибутива который бы поставлял Enlightenment нормально настроеным и с возможностью доставить нужные стили для тулкитов. Иначе говоря в случае с ним в любом случае нужен напильник для приложений на сторонних тулкитах.
> Я говорю про результат. Который пока отсутствует.Как же отсутствует? Кодовая база Xorg'а уже засрана XWayland'ом.
>> Результат-то известен - 5 окон, 3 разных заголовка. См., например, даже последние скрины Enlightenment на Wayland'е.
> Я если честно в своё время не смог найти репозитория в котором
> бы был этот самый Enlightenment более менее свежей версии.Ну посмотрите практически любой скрин Wayland'а - если запущено несколько программ, то обязательно какие-то заголовки будут различаться по стилю.
Скорее бы уже допилили его до юзабельного состояния. Хочется поскорее соскочить с иксов.
> Скорее бы уже допилили его до юзабельного состояния. Хочется поскорее соскочить с
> иксов.Win32 и Quartz в вашем распоряжении. :-)
> Скорее бы уже допилили его до юзабельного состояния. Хочется поскорее соскочить с
> иксов.Для меня звучит, увы, как очередное сезонное обострение...
В общем-то, лучше бы изначально не вскакивать (и не гарцевать верхом на) то(м), с чего теперь так хочется побыстрее соскочить... Вот уже пятое или шестое по счету межсезонье, кажется мне, бравые разработчики Вейландов и Вестонов все не могут дать подобным страдальцам желанного избавления от кошмарных мук с устарелыми иксами. Когда же свершится, да и придет ли вообше долгожданное избавление?
Слушайте, а чем всех не устраивает собственно всех x11 ну кроме сотен зависимостей? какую проблему вообще решает вестон и вайланд?
Большинство x11 как раз устраивает - иначе бы давно поменяли.
Ребята, кто пробовал - можно уже юзать или нет?
И как по скорости? Быстрее LXDE?
> Быстрее LXDE?Кернел самый быстрый.
Wayland compositor -- быстрая прорисовка окон, меньшая потребность в видеопамяти, меньшая нагрузка на видеоплату, большая производительность за счет более быстрого взаимодействия между графическим приложением и дисплейном сервером.