Войти
 | |
 Weston, эталонная реализация сервера Wayland. | |
| Оригинальный автор (ы) | Кристиан Хогсберг |
|---|---|
| Разработчик (и) | freedesktop.org и др. |
| Первоначальный выпуск | 30 сентября 2008 г.; 12 лет назад (30.09.2008) |
| Стабильный выпуск | Wayland: 1.18, Weston: 8.0 / 11 февраля 2020 г.; 8 месяцев назад (2020-02-11) |
| Репозиторий |  |
| Написано на | C |
| Операционная система | официальная: Linux. неофициальная: NetBSD, FreeBSD, DragonFly BSD |
| Тип | |
| Лицензия | Лицензия MIT |
| Веб-сайт | wayland.freedesktop.org |
Wayland - это протокол связи, определяет связь между сервером отображения и его клиентами, а также реализацию этого протокола в библиотеке C. Сервер отображения, использующий протокол Wayland, называется компоновщиком Wayland, потому что он дополнительно выполняет задачу оконного менеджера композитинга.
Wayland разработан группой добровольцев, первоначально возглавляемой Кристианом Хогсбергом как бесплатный и проект с открытым исходным кодом, управляемый сообществом с целью замены X Window System современной, безопасной, более простой оконной системой в Linux и других Unix-подобных операционных системах. Исходный код проекта опубликован в соответствии с условиями лицензии MIT, разрешающей лицензии на свободное ПО.
В рамках своих усилий проект Wayland также разрабатывает эталонную реализацию композитора Wayland под названием Weston.
. Начиная примерно с 2010 года, графика рабочего стола Linux перестала иметь "кучу интерфейсов рендеринга... все разговаривают с X-сервером, который находится в центре вселенной «для установки ядра Linux и его компонентов (т.е. Direct Rendering Infrastructure (DRI), Direct Rendering Manager (DRM) ) «посередине», с «оконными системами, такими как X и Wayland... в углу». Это будет «значительно упрощенная графическая система, предлагающая большую гибкость и лучшую производительность».
Кристиан Хогсберг мог бы добавить расширение к X, как это делали многие недавние проекты, но предпочел » [вытолкнуть] X из горячего пути между клиентами и оборудованием "по причинам, объясненным в FAQ проекта:
Что изменилось сейчас, так это то, что большая часть инфраструктуры перенесена с X-сервера в ядро ( управление памятью, планирование команд, установка режима ) или библиотеки (cairo, pixman, freetype, fontconfig, pango и т. д.), и в процессе центрального сервера должно произойти очень немногое.... [X-сервер имеет] огромное количество функций, которые вы должны поддерживать, чтобы утверждать, что он говорит по X-протоколу, но никто никогда не будет использовать это.... Это включает в себя кодовые таблицы, растеризацию и кэширование глифов, XLFD (серьезно, XLFD!) И весь основной API рендеринга, который позволяет рисовать пунктирные линии, многоугольники, широкие дуги и многое другое. графические примитивы в стиле 1980-х. Для многих вещей нам удалось сохранить современный сервер X.org, добавив такие расширения, как XRandR, XRender и COMPOSITE... С Wayland мы может переместить X-сервер и все его унаследованные технологии на дополнительный путь кода. Достижение того момента, когда X-сервер является вариантом совместимости вместо базовой системы рендеринга, займет некоторое время, но мы никогда этого не добьемся, если [мы] не планируем это.
Wayland состоит из протокола и эталонная реализация с именем Weston. В рамках проекта также разрабатываются версии GTK и Qt, которые отрисовываются в Wayland, а не в X. Ожидается, что большинство приложений получат поддержку Wayland через одну из этих библиотек без модификации приложения..
Первоначальные версии Wayland не обеспечивали прозрачности сети, хотя Хёгсберг отметил в 2010 году, что прозрачность сети возможна. Это было предпринято в качестве проекта Google Summer of Code в 2011 году, но безуспешно. Адам Джексон предусмотрел предоставление удаленного доступа к приложению Wayland путем «очистки пикселей» (например, VNC ) или получения от него «потока команд рендеринга» по сети (как в RDP, SPICE или X11 ). По состоянию на начало 2013 года Хогсберг экспериментирует с прозрачностью сети, используя прокси-сервер Wayland, который отправляет сжатые изображения настоящему композитору. В августе 2017 года в GNOME была впервые реализована такая реализация VNC-сервера с парсингом пикселей в Wayland.
В архитектуре протокола Wayland клиент и композитор обмениваются данными через протокол Wayland с использованием эталонных библиотек реализации. Протокол Wayland следует модели клиент-сервер, в которой клиенты - это графические приложения, запрашивающие отображение буферов пикселей на экране, а сервер (композитор) - поставщик услуг, контролирующий отображение этих буферов.
Эталонная реализация Wayland была разработана как двухуровневый протокол:
В то время как низкоуровневый уровень был написан вручную на C, высокоуровневый уровень автоматически генерируется из описания элементов протокол, хранящийся в формате XML. Каждый раз, когда описание протокола этого XML-файла изменяется, исходный код C, реализующий такой протокол, может быть регенерирован для включения новых изменений, что обеспечивает очень гибкий, расширяемый и защищенный от ошибок протокол.
Эталонная реализация протокола Wayland разделена на две библиотеки : библиотеку для использования клиентами Wayland под названием libwayland-clientи библиотеку, которая будет использоваться Wayland Композиторы называются libwayland-server.
Протокол Wayland описывается как «асинхронный объектно-ориентированный протокол». Объектно-ориентированный означает, что услуги, предлагаемые композитором, представлены в виде серии объектов, живущих на одном и том же композиторе. Каждый объект реализует интерфейс, который имеет имя, несколько методов (называемых запросами), а также несколько связанных событий. Каждый запрос и событие имеет ноль или более аргументов, каждый из которых имеет имя и тип данных . Протокол является асинхронным в том смысле, что запросам не нужно ждать синхронизированных ответов или ACK, что позволяет избежать времени задержки приема-передачи и повысить производительность.
Клиенты Wayland могут сделать запрос (вызов метода) для некоторого объекта, если интерфейс объекта поддерживает этот запрос. Клиент также должен предоставить необходимые данные для аргументов такого запроса. Таким образом клиенты запрашивают услуги у наборщика. Компоновщик, в свою очередь, отправляет информацию обратно клиенту, заставляя объект генерировать события (возможно, также с аргументами). Эти события могут быть отправлены композитором в ответ на определенный запрос или асинхронно, в зависимости от возникновения внутренних событий (например, от устройства ввода) или изменений состояния. Состояния ошибки также сигнализируются как события композитором.
Чтобы клиент мог сделать запрос к объекту, ему сначала необходимо сообщить серверу идентификационный номер, который он будет использовать для идентификации этого объекта. В композиторе есть два типа объектов: глобальные объекты и неглобальные объекты. Композитор объявляет глобальные объекты клиентам при их создании (а также при их уничтожении), в то время как неглобальные объекты обычно создаются другими объектами, которые уже существуют как часть их функциональности.
интерфейсы, их запросы и события являются основными элементами, определяющими протокол Wayland. Каждая версия протокола включает набор интерфейсов, а также их запросы и события, которые, как ожидается, будут в любом композиторе Wayland. При желании композитор Wayland может определять и реализовывать свои собственные интерфейсы, поддерживающие новые запросы и события, тем самым расширяя функциональность за пределы основного протокола. Чтобы облегчить внесение изменений в протокол, каждый интерфейс помимо имени содержит атрибут «номер версии»; этот атрибут позволяет различать варианты одного и того же интерфейса. Каждый композитор Wayland показывает не только доступные интерфейсы, но и поддерживаемые версии этих интерфейсов.
Интерфейсы текущей версии протокола Wayland определены в файле protocol /wayland.xml исходного кода Wayland. Это файл XML, в котором перечислены существующие интерфейсы в текущей версии, а также их запросы, события и другие атрибуты. Этот набор интерфейсов - минимум, необходимый для реализации любым композитором Wayland.
Некоторые из основных интерфейсов протокола Wayland:
Типичный сеанс клиента Wayland начинается с открытия соединения с композитором с помощью объекта wl_display. Это специальный локальный объект, который представляет соединение и не находится на сервере. Используя свой интерфейс, клиент может запросить глобальный объект wl_registry у композитора, в котором находятся все имена глобальных объектов, и связать те, которые интересуют клиента. Обычно клиент связывает как минимум объект wl_compositor, откуда он будет запрашивать один или дополнительные объекты wl_surface для отображения вывода приложения на дисплей.
Композитор Wayland может определять и экспортировать свои собственные дополнительные интерфейсы. Эта функция используется для расширения протокола за пределы базовой функциональности, обеспечиваемой базовыми интерфейсами, и стала стандартным способом реализации расширений протокола Wayland. Некоторые композиторы могут добавлять настраиваемые интерфейсы для предоставления специализированных или уникальных функций. Эталонный композитор Wayland, Weston, использовал их для реализации новых экспериментальных интерфейсов в качестве испытательной площадки для новых концепций и идей, некоторые из которых позже стали частью основного протокола (например, интерфейс wl_subsurface, добавленный в Wayland 1.4).
Протокол XDG-Shell (см. freedesktop.org для XDG) - это расширенный способ управлять поверхностями под композиторы Wayland (не только Weston). Традиционный способ управления поверхностями (развертывание, свертывание, полноэкранный режим и т. Д.) Заключается в использовании функций wl_shell _ * (), которые являются частью основного протокола Wayland и находятся в libwayland-client. Напротив, реализация протокола xdg-shell должна быть предоставлена композитором Wayland. Таким образом, вы найдете заголовок xdg-shell-client-protocol.h в дереве исходных текстов Weston. Предполагается, что каждый композитор Wayland имеет собственную реализацию.
По состоянию на июнь 2014 года протокол XDG-Shell не поддерживался версией и все еще подвержен изменениям.
xdg_shell - это протокол, предназначенный для замены wl_shell в долгосрочной перспективе, но он не будет частью основного протокола Wayland. Он начинается как нестабильный API, предназначенный для использования сначала в качестве места разработки, и после того, как функции определены в соответствии с требованиями нескольких оболочек рабочего стола, его можно, наконец, сделать стабильным. Он предоставляет в основном два новых интерфейса: xdg_surface и xdg_popup. Интерфейс xdg_surface реализует окно в стиле рабочего стола, которое можно перемещать, изменять размер, увеличивать и т. Д.; он предоставляет запрос на создание дочерних / родительских отношений. Интерфейс xdg_popup реализует всплывающее меню / меню в стиле рабочего стола; xdg_popup всегда является переходным для другой поверхности, а также имеет неявный захват.
IVI-Shell является расширением основного протокола Wayland, нацеленным на в автомобиле информационно-развлекательные устройства (IVI).
Композитор Wayland и его клиенты используют EGL для рисования непосредственно в буфер кадра ; Сервер X.Org с XWayland и Glamour.Протокол Wayland не включает API рендеринга. Вместо этого Wayland следует модели прямого рендеринга, в которой клиент должен рендерить содержимое окна в буфер, доступный для совместного использования с композитором. Для этой цели клиент может выбрать выполнение рендеринга самостоятельно, использовать библиотеку рендеринга, такую как Cairo или OpenGL, или полагаться на механизм рендеринга библиотек виджетов высокого уровня с Поддержка Wayland, например Qt или GTK. Клиент также может дополнительно использовать другие специализированные библиотеки для выполнения определенных задач, таких как Freetype для рендеринга шрифтов.
Результирующий буфер с визуализированным содержимым окна сохраняется в объекте wl_buffer. Внутренний тип этого объекта зависит от реализации. Единственное требование - данные содержимого должны быть доступны для совместного использования клиенту и композитору. Если клиент использует программный (ЦП) рендерер и результат сохраняется в системной памяти, то клиент и композитор могут использовать совместно используемую память для реализации взаимодействия буфера без дополнительных копий. Протокол Wayland уже изначально предоставляет этот вид разделяемого буфера памяти через интерфейсы wl_shm и wl_shm_pool. Недостатком этого метода является то, что композитору может потребоваться дополнительная работа (обычно для копирования общих данных в графический процессор) для их отображения, что приводит к снижению производительности графики.
Наиболее типичный случай, когда клиент выполняет рендеринг непосредственно в буфер видеопамяти, используя API с аппаратным (GPU) ускорением, например OpenGL, OpenGL ES или Вулкан. Клиент и композитор могут совместно использовать этот буфер пространства GPU, используя специальный обработчик для ссылки на него. Этот метод позволяет композитору избежать дополнительного копирования данных через себя методом «клиент-композитор-графический процессор», что приводит к более высокой производительности графики, и поэтому является предпочтительным. Компоновщик может дополнительно оптимизировать композицию финальной сцены, которая будет отображаться на дисплее, используя тот же API аппаратного ускорения, что и клиент API.
Когда рендеринг завершен в совместно используемом буфере, клиент Wayland должен проинструктировать композитора представить рендеринг содержимого буфера на дисплее. Для этого клиент привязывает буферный объект, в котором хранится визуализированное содержимое, к поверхностному объекту и отправляет на поверхность запрос «фиксации», передавая эффективное управление буфером композитору. Затем клиент ожидает, пока композитор освободит буфер (о чем свидетельствует событие), если он хочет повторно использовать буфер для визуализации другого кадра, или он может использовать другой буфер для визуализации нового кадра, и, когда визуализация завершена, привязать этот новый буфер на поверхность и зафиксирует его содержимое. Процедура, используемая для рендеринга, включая количество задействованных буферов и их управление, полностью находится под контролем клиента.
Существует несколько различий между Wayland и X в отношении производительности, удобства обслуживания кода и безопасности:
Снимок экрана, показывающий xwayland XWayland, является X Server работает как клиент Wayland и, таким образом, может отображать собственные клиентские приложения X11 в среде композитора Wayland. Это похоже на то, как XQuartz запускает X-приложения в собственной оконной системе macOS. Цель XWayland - облегчить переход от системы X Window к средам Wayland, предоставив тем временем возможность запускать непортированные приложения. XWayland был встроен в X.Org Server версии 1.16.
Наборы инструментов для виджетов, такие как Qt 5 и GTK 3, могут переключать свой графический интерфейс обратно. конец во время выполнения, позволяя пользователям выбирать в время загрузки, хотят ли они запускать приложение через X или через Wayland. Qt 5 предоставляет для этого опцию командной строки -platform, тогда как GTK 3 позволяет пользователям выбирать желаемую внутреннюю часть GDK, устанавливая GDK_BACKENDПеременная среды Unix.
Типичные элементы окна. Ни Wayland, ни X11 не указывают, какое программное обеспечение отвечает за рендеринг оформления окна. Weston требует, чтобы они были нарисованы клиентом, но KWin реализует оформление на стороне сервера. Серверы отображения, реализующие протокол сервера отображения Wayland, также называются композиторами Wayland, потому что они дополнительно выполняют задача оконного менеджера композитинга.
Weston, работающего на postmarketOS Weston - эталонная реализация композитора Wayland, также разработанная в рамках проекта Wayland. Он написан на C и опубликован под лицензией MIT. Weston официально поддерживает только операционную систему Linux из-за зависимости Weston от некоторых функций ядра Linux, таких как настройка режима ядра, Graphics Execution Manager (GEM) и udev, которые не были реализованы в других Unix-подобных операционных системах. При работе в Linux обработка входного оборудования зависит от evdev, а обработка буферов зависит от Generic Buffer Management (GBM). Однако в 2013 году был анонсирован прототип порта Weston на FreeBSD.
Weston поддерживает High-bandwidth Digital Content Protection (HDCP).
Weston полагается на GEM для совместного использования буферов приложений между композитором и приложениями. Он содержит подключаемую систему «оболочек» для общих функций рабочего стола, таких как док-станции и панели. Клиенты несут ответственность за прорисовку рамок окон и их украшения. Для рендеринга Weston может использовать OpenGL ES или библиотеку pixman для выполнения программного рендеринга. Полная реализация OpenGL не используется, поскольку в большинстве современных систем установка полных библиотек OpenGL также приведет к установке GLX и других поддерживающих библиотек X Window System в качестве зависимостей.
Интерфейс удаленного доступа для Weston был предложен в октябре 2013 г. сотрудником RealVNC.
Рабочий стол Maynard в январе 2017 г. Maynard - это графическая оболочка и была написана как надстройка для Weston, так же как GNOME Shell была написана как надстройка к Mutter.
libinput была создан для объединения стека ввода для нескольких композиторов Wayland. Код Weston для работы с устройствами ввода (клавиатуры, указатели, сенсорные экраны и т. д.) был разделен на отдельную библиотеку под названием libinput, поддержка которой была впервые объединена в Weston 1.5.
Libinput обрабатывает устройства ввода для нескольких композиторов Wayland, а также предоставляет общий драйвер ввода X.Org Server. Его цель - предоставить одну реализацию для нескольких композиторов Wayland с общим способом обработки событий ввода, минимизируя при этом количество настраиваемых композиторов кода ввода, которые необходимо включать. libinput обеспечивает обнаружение устройства (через udev ), обработку устройства, обработку событий устройства ввода и абстракцию.
Версия 1.0 libinput последовала за версией 0.21 и включала поддержку планшетов, наборов кнопок и жестов сенсорной панели. Эта версия будет поддерживать стабильный API / ABI.
Поскольку GNOME / GTK и KDE Frameworks 5 внесли необходимые изменения, Fedora 22 заменит драйверы evdev и Synaptics от X.Org на libinput.
В версии 1.16 сервер X.Org получил поддержку библиотеки libinput в форме оболочки под названием xf86-input-libinput.
Модуль безопасности Wayland - это предложение, которое напоминает интерфейс Linux Security Module, который есть в ядре Linux.
Некоторые приложения (особенно связанные с доступность ) требуют привилегированных возможностей, которые должны работать с различными композиторами Wayland. В настоящее время приложения в Wayland, как правило, не могут выполнять какие-либо важные задачи, такие как создание снимков экрана или внедрение событий ввода. Разработчики Wayland активно ищут возможные способы безопасной работы с привилегированными клиентами, а затем проектируют для них привилегированные интерфейсы.
Модуль безопасности Wayland - это способ делегировать решения по безопасности в композиторе централизованному механизму принятия решений.
Протокол Wayland разработан так, чтобы быть простым, так что дополнительные протоколы и интерфейсы должны быть определены и реализованы для достижения целостной оконной системы. По состоянию на июль 2014 года эти дополнительные интерфейсы находились в стадии разработки. Таким образом, хотя наборы инструментов уже полностью поддерживают Wayland, разработчики графических оболочек сотрудничают с разработчиками Wayland, создавая необходимые дополнительные интерфейсы.
По состоянию на 2020 год большинство дистрибутивов Linux поддерживают Wayland из коробки, некоторые примечательные примеры:
Известный ранний последователь:
Toolkit, поддерживающий Wayland, включает следующее:
Рабочие среды, переносимые из X в Wayland, включают GNOME, KDE Plasma 5 и Enlightenment.
В ноябре 2015 года Enlightenment e20 был анонсирован при полной поддержке Wayland. GNOME 3.20 была первой версией, в которой была полнофункциональная сессия Wayland. GNOME 3.22 включает значительно улучшенную поддержку Wayland в GTK, Mutter и GNOME Shell. GNOME 3.24 поставлял поддержку проприетарных драйверов NVidia под Wayland.
Поддержка Wayland для KDE Plasma была отложена до выпуска Plasma 5, хотя ранее KWin 4.11 получил экспериментальную поддержку Wayland. Версия 5.4 Plasma была первой с сессией Wayland. В течение 2020 года Klipper был перенесен на Wayland, а следующая версия 5.20 в октябре 2020 года имеет целью улучшить трансляцию экрана и запись. По крайней мере, одна основная часть KDE: sddm еще не перенесена на Wayland по состоянию на сентябрь 2020 года.
Другое программное обеспечение, поддерживающее Wayland, включает следующее:
Мобильное и встроенное оборудование, поддерживающее Wayland, включает следующее:
Wayland использует прямой рендеринг поверх EGL.Кристиан Хогсберг, разработчик графики Linux и X.Org разработчик, который ранее работал над AIGLX и DRI2, начал Wayland в качестве свободного времени в 2008 году, работая в Red Hat. Его заявленной целью была система, в которой «каждый кадр идеален, под этим я подразумеваю, что приложения смогут достаточно контролировать рендеринг, чтобы мы никогда не увидели разрывов, задержек, перерисовки или мерцания». Хогсберг ехал через город Вэйланд, штат Массачусетс, когда основные концепции «кристаллизовались», отсюда и название.
В октябре 2010 года Wayland стал freedesktop.org проект. В рамках миграции прежняя Группа Google была заменена списком рассылки wayland-devel в качестве центральной точки обсуждения и развития проекта.
Клиентские и серверные библиотеки Wayland были первоначально выпущены под лицензией MIT, в то время как эталонный композитор Weston и некоторые примеры клиентов использовали Стандартную общественную лицензию GNU версии 2. Позже весь код GPL был повторно лицензирован под лицензией MIT, «чтобы упростить перенос кода между эталонной реализацией и реальными библиотеками». В 2015 году было обнаружено, что текст лицензии, используемый Wayland, был немного другой и более старой версией лицензии MIT, а текст лицензии был обновлен до текущей версии, используемой проектом X.Org (известный как Лицензия MIT Expat ).
Wayland работает со всеми Mesa-совместимыми драйверами с поддержкой DRI2, а также с драйверами Android через проект Hybris.
Разработчики Wayland в основном являются текущими разработчиками X.Org Server.
| Версия | Дата | Основные характеристики | |
|---|---|---|---|
| Wayland | Weston | ||
| Старая версия, больше не м aintained: 0.85 | 9 February 2012 | First release. | |
| Old version, no longer maintained: 0.95 | 24 July 2012 | Began API stabilization. | |
| Old version, no longer maintained: 1.0 | 22 October 2012 | Stable wayland-client API. | |
| Old version, no longer maintained: 1.1 | 15 April 2013 | Software rendering. FBDEV, RDP backends. | |
| Old version, no longer maintained: 1.2 | 12 July 2013 | Stable wayland-server API. | Color management. Subsurfaces. Raspberry Pi backend. |
| Old version, no longer maintained: 1.3 | 11 October 2013 | More pixel formats. Support for language bindings. | Android driver support via libhybris. |
| Old version, no longer maintained: 1.4 | 23 January 2014 | New wl_subcompositor and wl_subsurface interfaces. | Multiple framebuffer formats. logind support for rootless Weston. |
| Old version, no longer maintained: 1.5 | 20 May 2014 | libinput. Fullscreen shell. | |
| Old version, no longer maintained: 1.6 | 19 September 2014 | libinput by default. | |
| Old version, no longer maintained: 1.7 | 14 February 2015 | Support for the Wayland presentation extension and for surface roles. IVI shell protocol. | |
| Old version, no longer maintained: 1.8 | 2 June 2015 | Separated headers for core and generated protocol. | Repaint scheduling. Named outputs. Output transformations. Surface-shooting API. |
| Old version, no longer maintained: 1.9 | 21 September 2015 | Updated license. | Updated license. New test framework. Triple-head DRM compositor. linux_dmabuf extension. |
| Old version, no longer maintained: 1.10 | 17 February 2016 | Drag-and-drop functionality, grouped pointer events. | Video 4 Linux 2, touch input, debugging improvements. |
| Old version, no longer maintained: 1.11 | 1 June 2016 | New backup loading routine, new setup logic. | Proxy wrappers, shared memory changes, Doxygen-generated HTML docs. |
| Old version, no longer maintained: 1.12 | 21 September 2016 | Debugging support improved. | libweston and libweston-desktop. Pointer locking and confinement. Relative pointer support. |
| Old version, no longer maintained: 1.13 | 24 February 2017 | The ABI of Weston has been changed, thus the new version was named 2.0.0 rather than 1.13.0. | |
| Old version, no longer maintained: 1.14 | 8 August 2017 | Weston 3.0.0 was released at the same time. | |
| Old version, no longer maintained: 1.15 | 9 April 2018 | Weston 4.0.0 was released at the same time. | |
| Old version, no longer maintained: 1.16 | 24 August 2018 | Weston 5.0.0 was released at the same time. | |
| Old version, no longer maintained: 1.17 | 20 March 2019 | Weston 6.0.0 was released at the same time. | |
| Current stable version: 1.18 | 2 August 2019 | Weston 7.0.0 was released one month later. | |
| Legend:Old versionOlder version, still maintainedLatest versionLatest preview versionFuture release | |||
Free and open-source software portal 