В предыдущем посте мы узнали, почему X Window System — один из самых успешных проектов с открытым кодом в истории, пора заменить на новое решение для графического окружения Linux. В этой же статье мы узнаем, каков из себя Wayland — наиболее вероятный кандидат на замену X.
Глоссарий Wayland
Имеет смысл сначала разобраться с некоторыми определениями и терминологией.
Compositor — Композитный оконный менеджер является одним из центральных понятий Wayland и вокруг него. Нигде толком не определено, что это такое, но термин этот используется так, как будто все всё знают. Во всяком случае на русском языке никакого определения я так и не нашел. К счастью примеры-таки проясняют суть дела. Вот их список в контексте Wayland:
KWin— дисплейный сервер KDE,Mutter— дисплейный сервер GNOME,Weston— эталонный композитный менеджер для Wayland,Enlightenment— графическая оболочка рабочего стола,Marco— оконный менеджер MATE.
Как мы видим, это не что иное как знакомые нам оконные менеджеры, хотя на самом деле нет. Это дисплейные сервера, которые все-таки отличаются по своему функционалу от WM. Первые взаимодействуют с пользовательскими устройствами ввода-вывода, с железом, управляют потоком данных клиентских программ. Вторые же отвечают за отображение окон и их размещение в системе оконного интерфейса.
Иллюстрация со страницы в википедии.
Но сказать, что есть четкая смысловая и терминологическая граница между всему этими серверами, менеджерами и композиторами, было бы обманом. Например KWin является и дисплейным сервером и WM, точно так же как и Enlightenment. Для данной статьи композитный оконный менеджер (в сокращении КОМ) и дисплейный сервер будут эквивалентами термина Compositor.
$ eix -c enlightenment; eix -ce kwin
[N] x11-wm/enlightenment (1.0.17): Enlightenment Window Manager (e16)
[I] kde-plasma/kwin (5.8.5(5)@01.02.2017): KDE window managerКомпозитный менеджер, он же дисплейный сервер может обозначаться еще как композитный оконный менеджер.
$ eix -c mutter
[N] x11-wm/mutter (3.20.3): GNOME 3 compositing window manager based on ClutterWeston — Эталонный дисплейный сервер протокола Wayland. Недавно вышла вторая версия КОМ-а.
EGL — платформонезависимый эквивалент программных интерфейсов OpenGL GLX/AGL/WGL, разрабатываемый Khronos Group. EGL предоставляет инфраструктурный набор для быстрой настройки приложения и инициализации сцены.
- Механизмы для создания областей рендеринга (окно, пиксельная карта, пиксельный буфер), чтобы клиентские API могли на них рисовать и разделять их.
- Создание графического контекста для клиентских API.
- Синхронизация отрисовки клиентскими API а также родными API рендеринга платформы.
EGL в отличие от GLX/AIGLX умеет выполнять лишь direct rendering, в котором приложения через DRI2/DRI3 могут безопасно и быстро получать доступ к видеоаппаратуре минуя X сервер.
GLES — Подмножество OpenGL, разработанное специально для встраиваемых систем — мобильных телефонов, планшетов, компьютеров, игровых консолей.
Архитектура Wayland
Итак, что представляет собой Wayland? Так же как и в случает с X Window System, речь идет о протоколе и его реализации. Wayland — это протокол взаимодействия между и клиентами, а также его библиотечная реализация в Си. В роли клиента может выступать пользовательское приложение, X сервер или другой дисплейный сервер.
- Цель: радикально упростить графическую среду Linux по сравнению с иксами.
- Использует Unix Domain Sockets, сетевой прозрачности нет.
- Главным образом использует EGL и DRI.
- Устройства ввода-вывода управляются полностью из ядра.
- Распределение буфера и отрисовка полностью на стороне клиента.
На самом нижнем уровне протокола клиент и КОМ синхронизируют сообщения, обмениваются упорядоченными объектами, используя средства IPC библиотек libwayland-client и libwayland-server. На этом уровне не определены способы управления оконным интерфейсом — только сообщения, передаваемые через Unix Domain Sockets, объекты и события.
+-------------------+ +-------------------+
| | | |
| Client | | Compositor |
+-------------------+ +-------------------+
| libwayland-client | | libwayland-server |
+-------------------+ +--+----------------+
| |
| Wayland |
User space | protocol |
+---------------------------------------------------+
| Kernel space | +---+ | |
| +------>|IPC|<----+ |
| +---+ |
+---------------------------------------------------+Объекты создаваемые клиентом представлены структурой wl_proxy, содержащей идентификатор сообщения передаваемого серверу через сокет, void указатель данных и указатель на статичный объект wl_interface. Отправляются сообщения с помощью структуры wl_proxy_marshal.
static inline void
wl_surface_attach(struct wl_surface *wl_surface, struct wl_buffer *buffer, int32_t x, int32_t y)
{
wl_proxy_marshal((struct wl_proxy *) wl_surface, WL_SURFACE_ATTACH, buffer, x, y);
}Wayland — асинхронный протокол, объектно ориентированный и нацеленный на обработку сообщений. Сообщение, передаваемое от клиента серверу, есть вызов, а в обратную сторону — событие. Каждое сообщение состоит из 32-битных слов, значения представлены в порядке следования байтов хоста.
Иллюстрация с главной страницы Wayland.
Как взаимодействуют эти блоки?
- Ядро регистрирует событие и отправляет КОМ-у.
- КОМ в своем графе сцены находит окно, которому следует доставить данное событие и он точно знает какой тип трансформации следует применить к объекту. КОМ транслирует экранные координаты в локальные для данного окна путем обратной трансформации.
- Клиент, отрабатывает событие, обновляя область графического интерфейса, производит рендеринг и извещает КОМ об изменениях.
- КОМ собирает с клиентов все данные по территориям, в которых содержимое зависимого буфера отлично от участка поверхности, и затем перекомпонует экран. Далее, дисплейный сервер подгружает новую страницу, с помощью ioctl вызова адресованного KMS.
А как происходит рендеринг? Клиенты самостоятельно производят отрисовку своих окон в отдельном буфере, передавая информацию об обновлениях дисплейному серверу, который комбинирует содержимое буферов разных приложений для формирования итогового вывода с учетом возможных нюансов, таких как перекрытие окон и прозрачность.
Wayland vs. X
Так чем-же, все-таки отличается в лучшую сторону Wayland? Давайте пробежимся по основным пунктам, чтобы понять ради чего все затевалось. Для меня лично достаточно факта отсутствия файла настройки xorg.conf. Впрочем плодотворное влияние прямых рук на правку этого файла уже обсудили обсудили в комментариях к предыдущему посту.
- Версии пронизывают протокол сверху донизу. Каждый интерфейс имеет ту или иную версию, каждый объект протокола реализует определенную версию своего интерфейса. Это исключает ситуацию с постоянными конфликтами версий X из-за того, что согласование версий привязано к клиентам, а не к соединению. Если приложение поддерживает одну версию расширения, тулкит другую а X11 третью, то невозможно предсказать, что в итоге получает приложение.
- Работа с устройствами ввода в Wayland сильно похожа на
Xinput 2.2минус нагромождения отжившего свой век кода и Master/Slave порядком между устройствами ввода. Глобальный объектseat, т. е. место определяет группу устройств ввода, включая мышь, клавиатуру и сенсорный экран. Кошмарные проблемы с мультитачем исчезнут. - Wayland в отличие от X не имеет API для отрисовки, и соответственно не занимается художествами. Все что ему требуется — буфера полные клиентских пикселей, а дальше он ими дирижирует так, чтобы приложение А не напортачило чего-нибудь в буферах, содержащих картинки приложения Б. Клиенты определяют какие пиксели будет находится в буферах и в ответе за изображение, которое высветится на экране!
- Wayland минимален. Вспомним, чем был X — государством в государстве, с полным набором функций ядра ОС и даже имел свой сервер печати, после того, как кому-то в голову взбрела идея добавить поддержку печати для glxgears. Так вот, всего этого в Wayland нет и никогда не будет. Основную тяжесть тащат на себе клиенты и это словно, так как они сами не захотят загибаться под тяжестью совместимости элементов UI 30-летней давности.
- Обязательная компоновка (compositing). Это не значит, что 3D эффекты неизбежны. Компоновка означает, бесшовное изображение, которое не трясется и не прыгает. Девиз Wayland —
ни единого разрывакаждый кадр прекрасен. Каждый пиксель на своем месте, как клиент задумал и осуществил. Для сравнения, как работает расширение X Composite? Для эффектов рабочего стола, GL компоновка вполне тянет лямку, но во время просмотра видео в браузере сразу же начинаются проблемы. Окно браузера и подокно с флаш плеером никак не синхронизированы. Для них события обрабатываются независимо и остается только надеяться, что два потока не будут сильно разбегаться во времени. По этой причине во время прокрутки окна с активным видеороликом Youtube, изображение может прыгать и дергаться. - Никаких шрифтов на сервере, клиенты сами справятся. Уже справляются.
- X страдает беспамятством, из-за чего и нужен пресловутый
xfree86.conf/xorg.conf, чтобы запомнить настройки для двух и более мониторов, графических карт. Мы ведь не будем скучать без этих убойных фич в грядущей пост-X эпохе?
Ошибочные суждения об X и Wayland
Существует ряд устойчиво неправильных мнений на сей счет.
- X юниксвейный. Ну как сказать, принципу делай что-то одно, но делай это хорошо Unix громоздкая всеядность иксов явно противоречит.
- Сетевая прозрачность X. Да, это было-было, но прошло с тех пор как X пересел на
DRI2и разделяемую память, а работать по сети не умеют оба. Все крутится на медлительном синхронномXlib, и выхлоп получается как с VNC, если не хуже. - Wayland пишут те, кто не понимает X. Ничего нет более далекого от правды — его пишут те разработчики X, кто устал от постоянно латать дыры и чинить костыли. Хороший пример Daniel Stone, тот самый один из 3 людей на земле, которые точно знают как работает привязка клавиатуры на X.
- Wayland навязывает 3D. Это не так, обязательна только компоновка. Об этом уже было сказано выше.
Использованные материалы и полезные ссылки
The Wayland Situation: Facts About X vs. Wayland
Статус разработки прослойки для обеспечения работы X11-приложений поверх Wayland
Документация Wayland
Автор: temujin
