В предыдущем посте мы узнали, почему 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, один из трех людей на земле, которые точно знают как работает привязка клавиатуры на X.
- Wayland навязывает 3D. Это не так, обязательна только компоновка. Об этом уже было сказано выше.
Использованные материалы и полезные ссылки
The Wayland Situation: Facts About X vs. Wayland
Статус разработки прослойки для обеспечения работы X11-приложений поверх Wayland
Документация Wayland
Комментарии (49)
kafeman
09.03.2017 19:27Странно, а я всегда считал, что композитный оконный менеджер — это тот, который рендерит во внеэкранный буфер (например, Compiz для иксов или DWM из Windows Vista+).
Lsh
09.03.2017 22:41+1А мне всегда казалось, что он собирает внеэкранные буферы и рендерит в свой, уже экранный. Но я могу ошибаться.
Надо в комменты какого-нибудь разработчика под Х-ы.kafeman
09.03.2017 23:14Я имел ввиду отличия от обычного, но да, ваша формулировка точнее. На самом деле, иксы тут даже ни при чем, эта терминология используется во многих графических программах.
NaHCO3
09.03.2017 21:08-4> Все крутится на медлительном синхронном Xlib, и выхлоп получается как с VNC, если не хуже.
Так VNC — это и есть X-сервер. Уйдут X-сервера, уйдёт и VNC.
Кстати, интересно, под вейланд есть аналог xpra?
Evengard
09.03.2017 22:22+7Вы что-то путаете. vnc — это совсем не X-сервер. Если бы это было так, как вы бы обьяснили vnc сервера на той же винде? Или x11vnc под линукс?
NaHCO3
09.03.2017 23:41-1Под линуксом интерфейсом vnc является x11. Приложение, которое запущено внутри vnc как бы видит x11 сервер, который так или иначе предоставляет vnc.
avost
10.03.2017 01:08+3Нет, конечно же нет. Вы неправомерно обобщаете одну из возможных реализаций vnc сервера.
Один вариант — это шаринг текущего рабочего стола, как в винде. Этот вариант предполагает граббинг экрана, что требует как определённых привелегий для приложения, так и наличия определённого набора библиотек в системе, которые позволяют это делать.
Другой вариант, это о чём говорите вы — vnc-сервер запускается как отдельная иксовая сессия и, собственно, её и представляет — просто отрисовка идёт не на экран, а в буфер vnc-сервера. Но это вовсе не значит, что всё так работает. Нет, vnc-сервер надо запускать отдельно и специально. И сетевой протокол vnc (он называется rfb) ничего общего с х-протоколом не имеет. Vnc просто передаёт пожатые битмапы в одну сторону, а события мыши и клавиатуры в другую.NaHCO3
10.03.2017 11:30-1> Один вариант — это шаринг текущего рабочего стола, как в винде.
Не слишком полезный вариант. Но в винде лицензионные ограничения не дают запускать отдельные сессии — так что там понятно.
> И сетевой протокол vnc (он называется rfb) ничего общего с х-протоколом не имеет
Я этого и не говорил. Меня интересует как будет происходить общение приложений с vnc. Если отказаться от X-сервера, сможет ли vnc эмулировать вейланд?avost
10.03.2017 13:06Один вариант — это шаринг текущего рабочего стола, как в винде.
Не слишком полезный вариант
Отнюдь нет. Распространённый вариант — хелпдеск рулит машиной клиента, помогает решить проблему.
Я этого и не говорил. Меня интересует как будет происходить общение приложений с vnc. Если отказаться от X-сервера, сможет ли vnc эмулировать вейланд?
Так, вроде, нет особых проблем запускать отдельную вейланд сессию у которой не настоящий экран, а vnc-шный фреймбуфер. Wayland сервер с virtual framebuffer же существует. Вот туда и приделываются vnc кодеки. Другое дело, что, возможно, ещё ни кто из разработчиков vnc-шек не сделал ничего такого, ну, так это дело времени и желания кого-нибудь оплатить работу.
andreymal
09.03.2017 21:19+3Сетевая прозрачность X. Да, это было-было, но прошло
Ну не знаю, ещё в прошлом году активно тыкал проброс иксов через ssh — отлично работает, скорость быстрая, прокрутка плавная, лагов нет, ни в какое сравнение с тормознутым vnc — и из-за этого отсутствие сетевой прозрачности в wayland меня сильно печалит
kafeman
09.03.2017 22:32Не знаю, что вы запускали, но во всяких GTK сейчас иксы только для создания OpenGL-контекста используются. Весь рендер идет внутри движка, так что в сетевой прозрачности нет никакого смысла.
andreymal
09.03.2017 22:33Именно GTK-приложения и запускал, да. Как GTK2, так и GTK3 — все летали. А вот Qt подлагивал, но, к счастью, большинство используемых мной программ используют нелагающий GTK)
Lsh
09.03.2017 22:33А через какую сеть это было?
По поводу отсутствия прозрачности, думаю, не стоит печалиться. Вроде уже что-то такое пилят. Можно на сервере гонять КОМ, который вместо экрана будет жать картинки и слать их по сети.andreymal
09.03.2017 22:36Через что-то с низким пингом, уже не помню точно. Иксы — они такие, скорость им почти не важна, зато важен низкий пинг, иначе начинает слоупочить (в частности, скорость прокрутки в sublime text через сеть ниже чем на локалхосте)
Lsh
09.03.2017 22:39скорость им почти не важна
Скорее это было так, когда использовались Х примитивы. Сейчас скорость очень даже важна, т.к. по сети летает картинка картинка.
А пинг важен, согласен.andreymal
09.03.2017 22:42Ну не знаю, я тоже вполне логично думал что скорость важна, однако скроллинг в gtk-приложниях абсолютно плавный даже на сетях меньше мегабита и evince рисует пдфки тоже шустро (хотя ощутимо медленнее чем на локалхосте, но на юзабельности не сказывается)
Lsh
09.03.2017 22:48Кстати, про скроллинг интересно, может ли контент скроллируемой области кешироваться на стороне Х-сервера?
ЕМНИП, в Х11 могут быть не только окна верхнего уровня, но и вложенные в них.
Есть ли там что-то вроде viewport для окна? Т.е. чтобы контент при скроле не пересылался от клиента, а сдвигался Х-сервером, клиент бы при этом только менял координаты сдвига.kafeman
09.03.2017 23:17Разумеется, в иксах есть дочерние окна. Можете поискать их через
xwininfo. Но в современных GUI-тулкитах от этой фичи изо всех сил стараются отказаться.Lsh
09.03.2017 23:37Да, что-то такое слышал, но не помню, почему отказываются.
Ещё всплыл вопрос про кеширование. Заметил достаточно давно.
Если программу на GTK или QT остановить, то содержимое окна повреждается и не регенерируется (если провезти другим окном поверх окна с остановленным приложением, композитинг отключён), а у приложений из состава GNUStep содержимое окна сохранялось.
Т.е. есть какое-то кеширование на стороне сервера. Интересно, почему не везде используется?kafeman
10.03.2017 01:31Да, что-то такое слышал, но не помню, почему отказываются.
Там было много проблем. Прозрачность, мерцание, производительность. Если вы загляните в исходники GTK/GDK, то найдете там класс GdkWindow, который инкапсулирует некоторую область для рисования и может реагировать на внешние события (например, если провести над ним курсор). Раньше этот класс был реализован через дочерние окна иксов, сейчас есть альтернатива в виде своей реализации. Также на Wayland, если я не ошибаюсь, нету такой возможности. Win32-реализация не использует нативные дочерние окна вообще и никак, потому что там творится полный «ад и Израиль» (даже сама Microsoft с начала 2000-ых не использует «нативный» API в приложениях вроде IE или офиса, гуглите на тему «win32 windowless controls»).
Т.е. есть какое-то кеширование на стороне сервера. Интересно, почему не везде используется?
Нет, это «фишка» GTK/Qt. Там на каждую свистелку-перделку приходится по отдельному буферу, в который реально рисуется содержимое. Когда вы инвалидуете какую-то область окна, то GTK/Qt восстанавливает ее из этого буфера. Хотя изначально это затевалось для избавления от мерцания…kafeman
11.03.2017 13:58Просто хочу уточнить свой ответ. В иксах все-таки есть «кеш», называется «backing store». Но его почему-то никто не использует и информация о нем почти не гуглится.
Lsh
09.03.2017 23:04Поставил сейчас на сервер (до которого 56 мсек) файловый менеджер thunar.
В принципе, пользоваться можно, но ооооочень не комфортно. Ощущения, как от игры в шутер на старом компе при 10 FPS.
При примерно таком же пинге (52) RDP с включенным RemoteFX работает ощутимо лучше. пару раз даже так графический редактор запускал для небольших манипуляций.andreymal
09.03.2017 23:05Завтра попробую повторить на чём-нибудь медленном
Lsh
09.03.2017 23:08Как бы это ещё объективно замерить? Понятие комфорта у всех разное. Кому-то и за обычным монитором не комфортно, 144 Гц надо (да, это немного из другой оперы, просто как пример).
andreymal
09.03.2017 23:10Ну я субъективно наблюдал 60фпс, и мысли не было о том что это может быть некомфортным) Завтра попутно видео запишу, там кадры посчитаю
andreymal
10.03.2017 14:32Хех, на 3G с пингом 60-100 мс и правда тормознутенько, но жить можно. А провод с пингом до 10 мс уже вполне юзабелен и даже в гимпе что-то порисовать можно (хотя кисточка иногда отстаёт, наверно из-за скорости всего мегабит)
kreon
09.03.2017 23:16А что с либами, на которых построены почти все X11 приложения ( gtk, qt, etc )? Они уже поддерживают Wayland или какие-то переговоры с ними идут? Или все только на уровне эмуляции X11-сервера ( какой оверхэд кстати? )
И что с коммерческими ( Стим & co ) продуктами, тоже через эмуляцию?kafeman
09.03.2017 23:19+3С разморозкой. GTK (точнее, GDK) уже давно от них не зависит. В Qt5 даже есть возможность запилить свой Wayland-сервер «из коробки».
glowingsword
10.03.2017 10:59Актуальные версии Gtk и Qt поддерживают wayland из коробки, у старых версий(к примеру GTK2) поддержка отсутствует, приложение запускается в режиме эмуляции X11-сервера. Про оверхэд не в курсе, субъективно он особо не осущащется, но это не значит что его нет...
amarao
10.03.2017 13:19+2У меня в отношении wayland'а есть одно пожелание. Сейчас я могу сказать ssh -XYC user@server и запускать на сервере приложение с рендерингом локально. Вот то же самое мне хочется и от wayland-приложений. Без запуска «локального десктопа» на сервере. Как именно оно будет сделано — дело десятое, но remote X application — пусть кривой и плохой, но всё же есть и работает в 90% случаев. Даже видео умеет играть.
maniacscientist
10.03.2017 13:25Одно окно — один битмап — это грустно на самом деле. Опять будут героически решать проблемы прокрутки. Хотя ещё в древних макосях всё было сделано правильно — вывод через OpenGL, одна текстура на окно, другая на прокручиваемый контент, либо полной длинны, либо в 3-4 экрана, и потом просто меняем UV-оффсет
robux
12.03.2017 17:25Я тоже не понимаю радости от постоянного и полного формирования битмапа окна.
Если окно видно на 10% (только краешек), так как на 90% перекрыто другими окнами, то зачем рендерить эти 90%, тем более если в эти 90% может входить какая-нибудь тяжёлая векторная графика (типа ГИС) или вывод видео.
Приложение бы могло не рендерить лишнее, если бы знало, что этот участок окна не виден. Но Wayland заставляет тратить лишние ресурсы и рендерить каждое окно на 100%. Поправьте, если я не прав.
andreymal
12.03.2017 18:13+1Однажды юзер альт-табнется в перекрытое окно, и тут битмап сильно поможет: без него все эти тяжёлые векторы начнут перерисовываться с нуля, и первое, что увидит юзер — не вектор, а серое окно, которое будет оставаться серым, пока вектор не отрисуется — такое часто можно было наблюдать в каких-нибудь WinXP или любых иксах без композитинга. Если же битмап с готовым вектором будет, то он отобразится сразу, что сильно повышает юзерфрендли. Плюс к этому если верхнее окно двигать поверх нижнего окна, то за окном будет оставаться серый след (или в запущенных случаях след из содержимого окна), так как нижнее окно будет не успевать перерисовываться. Лично мне не жалко небольшой нагрузки на проц и память ради того, чтобы подобного не происходило.
А держать запущенное видео в фоне вообще не надо, такое окно стоит хотя бы свернуть)
rkfg
10.03.2017 14:51Wayland навязывает 3D. Это не так, обязательна только компоновка. Об этом уже было сказано выше.
А без неё совсем никак? Дело в том, что при включенном композитинге всегда навязывается VSync, по крайней мере, из моей практики и из написанного в статье. А VSync даёт ощутимый input lag в шутерах, например. Играешь будто в киселе. Если никак нельзя его форсированно выключить, то это ставит крест на соревновательных FPS под линуксом.
splav_asv
10.03.2017 15:43Для полноэкранных окон компоновка может быть отключена.
rkfg
10.03.2017 16:03И VSync тоже отключится? Я немного не в курсе, но вроде бы есть какое-то различие между фулскрином и borderless windowed. В Windows слышал жалобы, мол, хотим borderless, чтобы Alt+Tab был то ли быстрее, то ли безболезненнее, не помню, а на Linux для меня «настоящий» фулскрин характеризовался захватом ввода, т.е. Alt+Tab или аналог из оконного менеджера не работал. Но скорее всего, там такое же окно размером с текущее разрешение экрана, а граббинг — просто побочный эффект организации ввода в конкретной игре.
Я почему спрашиваю — сам пользуюсь Compton именно для форсирования VSync, и хотя там есть опция unredirect fullscreen windows, это не влияет на VSync, он остаётся включен. Хоткеем можно включать/выключать Compton, когда нужно отсутствие тиринга или напротив, отсутствие input lag, так что тут не проблема. Но на Wayland просто так выключить его уже не получится.
splav_asv
10.03.2017 22:02Попробую проверить как время будет. Достоверных источников не нашел, но вроде бы способ есть. Похоже, что не все display server'а это умеют.
AllexIn
И когда же это счастье придет в основные дистрибутивы линукса?
kafeman
В «Федорином горе» уже давно.
Lsh
И как оно? Для повседневной работы уже гут?
kafeman
Иногда менюшки не в том месте появляются.
Lsh
В Х-ах с менюшками тоже какие-то траблы, они заграбастывают себе весь ввод.
BOPOHA
Да, без особых косяков.
Напрягает только этот баг https://bugs.freedesktop.org/show_bug.cgi?id=99235