Чем же так лучше Wayland ???

Так почему же разработчики решили поменять X window system?
Давайте разберемся...

X Window System — оконная система, обеспечивающая стандартные инструменты и протоколы для построения графического интерфейса пользователя. Используется в UNIX-подобных ОС.
X Window System обеспечивает базовые функции графической среды: отрисовку и перемещение окон на экране, взаимодействие с мышью и клавиатурой. X Window System не определяет деталей интерфейса пользователя — этим занимаются менеджеры окон, которых разработано множество. По этой причине внешний вид программ в среде X Window System может очень сильно различаться в зависимости от возможностей и настроек конкретного оконного менеджера.
В X Window System предусмотрена сетевая прозрачность: графические приложения могут выполняться на другой машине в сети, а их интерфейс при этом будет передаваться по сети и отображаться на локальной машине пользователя (в случае если это разрешено в настройках). В контексте X Window System термины «клиент» и «сервер» имеют непривычное для многих пользователей значение: «сервер» означает локальный дисплей пользователя (дисплейный сервер), а «клиент» — программу, которая этот дисплей использует (она может выполняться на удалённом компьютере).


Wayland — графический сервер для Linux и других UNIX-подобных операционных систем. Разработка Wayland была начата Кристианом Хогсбергом (англ. Kristian Høgsberg), членом «Центра открытых технологий Intel» (англ. Intel's Open Source Technology Center) и сотрудником Red Hat. Wayland является свободным ПО и распространяется под лицензией MIT.

Архитектура Wayland

Хороший способ понять wayland архитектуру и как это отлично X, состоит в том, чтобы следовать за случаем от входного устройства к сути, где изменение, которое это затрагивает, появляется на экране.
Это - то, где мы теперь с X:

1. Ядро получает случай от входного устройства и посылает это в X через входного водителя evdev. Ядро делает всю тяжелую работу здесь, ведя устройство, и переводя различные протоколы специфического события устройства к linux evdev вводят стандарт случая.
2. X серверов определяют, какое окно случай затрагивает и посылает им клиентам, которые выбрали для рассматриваемого случая на том окне. X серверов фактически не знают, как сделать это правильно, так как местоположение окна на экране управляется наборщиком и может быть преобразовано многими способами, которыми X серверов не понимают (сокращенный, вращаемый, колебание, и т.д).
3. Клиент смотрит на случай и решает, что сделать. Часто UI должен будет измениться в ответ на случай - возможно, флажком щелкнули, или указатель вошел в кнопку, которая должна быть выдвинута на первый план. Таким образом клиент отсылает запрос предоставления назад к X серверам.
4. Когда X серверов получают запрос предоставления, они посылают это водителю, чтобы позволить этому программировать аппаратные средства, чтобы сделать предоставление. X серверов также вычисляют область ограничения предоставления, и посылают это наборщику как случай повреждения.
5. Случай повреждения говорит наборщику, что кое-что измененное в окне и что у этого есть к пересоединению часть экрана, где то окно видимо. Наборщик ответственен за предоставление всего содержания экрана, основанного на его scenegraph и содержании этих X окон. Все же, это должно пройти X серверов, чтобы отдать этому.
6. X серверов получают запросы предоставления от наборщика и или копируют наборщика, назад буферизуют на передний буфер, или делает pageflip. В общем случае X серверов должны сделать этот шаг, таким образом это может составлять наложившиеся окна, которые могут потребовать обрыва и определить, может ли это пролистать щелчок. Однако, для наборщика, который всегда является fullscreen, это - другой ненужный выключатель контекста.

Как предложено выше, есть несколько проблем с этим подходом. У X серверов нет информации, чтобы решить, какое окно должно получить случай, и при этом это не может преобразовать координаты экрана к окну местные координаты. И даже при том, что X вручил ответственность за заключительную живопись экрана compositing менеджеру, X все еще средства управления передний буфер и modesetting. Большая часть сложности, с которой X серверов имели обыкновение обращаться, теперь доступна в ядре или сам содержавшие библиотеки (КМ/СЕК, evdev, столовая гора, fontconfig, freetype, Каир, Спокойна и т.д). Вообще, X серверов - теперь только средний человек, который вводит дополнительный шаг между заявлениями и наборщиком и дополнительный шаг между наборщиком и аппаратными средствами.
В wayland наборщик - сервер показа. Мы передаем контроль КМ/СЕК и evdev наборщику. wayland протокол позволяет наборщику посылать входные события непосредственно клиентам и позволяет клиенту посылать случай повреждения непосредственно наборщику:

1. Ядро получает случай и посылает это наборщику. Это подобно X случаям, которые являются большими, так как мы добираемся, чтобы снова использовать всех входных водителей в ядре.
2. Наборщик просматривает его scenegraph, чтобы определить, какое окно должно получить случай. scenegraph соответствует тому, что находится на экране, и наборщик понимает преобразования, что это, возможно, относилось к элементам в scenegraph. Таким образом, наборщик может выбрать правильное окно и преобразовать координаты экрана к окну местные координаты, применяя обратные преобразования. Типы преобразования, которое может быть применено к окну, только restriced к тому, что может сделать наборщик, пока оно может вычислить обратное преобразование для входных событий.
3. Как в X случаях, когда клиент получает случай, это обновляет UI в ответе. Но в wayland случае, предоставление случается в клиенте, и клиент только посылает запрос наборщику указать область, которая была обновлена.
4. Наборщик собирает запросы повреждения от его клиентов и затем пересоединений экран. Наборщик может тогда непосредственно выпустить ioctl, чтобы наметить pageflip с КМ/СЕК.

Предоставление Wayland

Одни из деталей, которые я не учел в вышеупомянутом кратком обзоре, - то, как клиенты фактически отдают под wayland. Удаляя X серверов из картины мы также удалили механизм, которым X клиентов типично отдают. Но есть другой механизм, который мы уже используем с DRI2 под X: прямое предоставление. С прямым предоставлением клиент и сервер разделяют видео буфер памяти. Клиент связывается с библиотекой предоставления, такой как OpenGL, который знает, как программировать аппаратные средства и отдает непосредственно в буфер. Наборщик в свою очередь может взять буфер и использовать его как структуру когда он соединения рабочий стол. После начальной установки клиент только должен сказать наборщику, которые буферизуют, чтобы использовать и когда и где она отдала новое содержание в это.
Это оставляет заявление с двумя способами обновить его содержание окна:

1. Отдайте новое содержание в новый буфер и скажите наборщику использовать это вместо старого буфера. Заявление может ассигновать новый буфер каждый раз, когда оно должно обновить содержание окна, или оно может держать два (или больше) буфера вокруг и цикл между ними. Буферное управление находится полностью под прикладным контролем.
2. Отдайте новое содержание в буфер, которому оно ранее сказало наборщику использовать. В то время как возможно только отдать непосредственно в буфер, которым разделяют с наборщиком, это могло бы мчаться с наборщиком. То, что может случиться, - то, что перекрашивание содержания окна могло быть прервано наборщиком, перекрашивающим рабочий стол. Если заявление будет прервано только после прояснения окна, но прежде, чем отдать содержание, то наборщик будет структура от чистого буфера. Результат состоит в том, что прикладное окно будет мерцать между декоративным окном или полуотдавало содержание. Традиционный способ избежать этого состоит в том, чтобы отдать новое содержание в обратный буфер и затем скопировать оттуда в поверхность наборщика. Обратный буфер может быть ассигнован на лету и только достаточно большой, чтобы держать новое содержание, или заявление может иметь в наличии буфер. Снова, это находится под прикладным контролем.

В любом случае заявление должно сказать наборщику, которого область поверхности держит новым содержанием. Когда заявление отдает непосредственно на общий буфер, наборщик должен быть замечен, что есть новое содержание. Но также и обменивая буфера, наборщик не принимает ничто измененное, и нуждается в запросе от заявления прежде, чем это перекрасит рабочий стол. Идея, что, даже если заявление передает новый буфер наборщику, только маленькая часть буфера может быть различной, как мерцающий курсор или прядильщик.

X как Клиент Wayland

Wayland - полная система окна сам по себе, но даже в этом случае, если мы мигрируем далеко от X, имеет смысл иметь пользу назад история совместимости. С несколькими изменениями сервер Xorg может быть изменен, чтобы использовать входные устройства wayland для входа и отправить или окно корня или отдельные высокопоставленные окна как wayland поверхности. Сервер все еще управляет тем же самым 2-ым водителем с тем же самым кодексом ускорения, поскольку это делает, когда это бежит прирожденно, главное различие - то, что wayland обращается с представлением окон вместо КМ/СЕК.