Вперед в будущее: Wayland против X11

Доброго времени суток, дорогие читатели! Сегодня я затрону одну интересную тему — графические дисплейные сервера и протоколы в Linux. В этой статье я расскажу вам о архитектуре X11 и Wayland, историю их создания и наконец-то сделаем вывод: Иксы на мороз, или вейланд на помойку?

Еще в далеком 2016 году вышла Fedora 25 с окружением GNOME 3.22 на базе дисплейного сервера Wayland. А в RHEL 10 выкинут X11 на мороз. Релиз RHEL 10 намечен на 2025 год, CentOS Stream 10 — на 2024 год. Для обеспечения работы приложений, требующих X11, будет использоваться XWayland. Таким образом, в 2029 году (к моменту окончания первого этапа поддержки RHEL 9) стоит ожидать появление первого аппаратного обеспечения, не поддерживающего X11.

И как я думаю — будущее за Wayland. Но пока X11 является стандартом. Давайте разберем это!

Итак, для начала разберемся с терминами:

• X Window System — Система оконного интерфейса X, создана в MIT в 1984 г. В X11 определен протокол, но сводить все к протоколу не надо. Протокол — это набор правил, по которому действует уже программа.
• X11 — последняя версия X, выпущенная в 1987 года. Изначально был создан XFree86 на основе X11, а после и X.Org.
• X.Org Server — Свободная каноническая реализация серверной части иксов, то что на сегодняшний день является X-сервером для Linux.
• Xlib — Каноничная реализация клиентской части X, хранилище огромного количества утилит для управления оконным интерфейсом. Очень большая библиотека, состоящая из несколько сотен тысяч строчек кода, и причем код плохо документирован и написан, мягко говоря, мутно
• XCB — X protocol C-language Binding, клиентская библиотека X написанная на C. XCB имеет массу преимуществ перед Xlib: прямой доступ к X11, проще и легче, потребление памяти ниже, поддерживает многопоточность и расширения, не блокирует приложение. Предполагалось, что XCB заменит Xlib, но инерция накопленной кодобазы тормозит это благое начинание.
• Wayland — это не сам дисплейный сервер, а протокол для организации графического сервера. Название происходит от города Вэйланд, когда Хогсберг ехал через этот город, ему пришёл в голову концепт системы. Протокол же, это документ в формате xml, в котором находятся правила отображения окон. Ну и Wayland не отвечает сразу за много функций, как X11. А также это монопольное использование десктопа одним пользователем, когда как X11 многопользовательский
• Libwayland — это самая популярная эталонная реализация Wayland.

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

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

X предоставляет базовую структуру, или примитивы, для создания таких графических сред: рисование и перемещение окон на дисплее и взаимодействие с мышью, клавиатурой или сенсорным экраном. X не определяет пользовательский интерфейс; этим занимаются отдельные клиентские программы. Программы могут использовать графические возможности X без пользовательского интерфейса. Таким образом, визуальный стиль сред на базе X сильно различается; разные программы могут представлять радикально отличающиеся интерфейсы.

В отличие от большинства более ранних протоколов отображения, X был специально разработан для использования через сетевые подключения, а не на встроенном или подключенном устройстве отображения. X обеспечивает прозрачность сети, что означает, что программа X, запущенная на компьютере где-либо в сети (например, в Интернете), может отображать свой пользовательский интерфейс на сервере X, запущенном на каком-либо другом компьютере в сети. X-сервер обычно является поставщиком графических ресурсов и событий клавиатуры/мыши для X-клиентов, что означает, что X-сервер обычно запускается на компьютере перед пользователем, в то время как клиентские приложения X запускаются в любом месте сети и взаимодействуют с компьютером пользователя, запрашивая рендеринг графики, создает контент и считывает события с устройств ввода.

Тот факт, что термин "сервер" применяется к программному обеспечению, находящемуся перед пользователем, часто удивляет пользователей, привыкших к тому, что их программы являются клиентами служб на удаленных компьютерах. Здесь вместо удаленной базы данных, являющейся ресурсом для локального приложения, графический дисплей пользователя и устройства ввода становятся ресурсами, предоставляемыми локальным X-сервером как локальным, так и удаленно размещенным X-клиентским программам, которым необходимо совместно использовать графику пользователя и устройства ввода для взаимодействия с пользователем.

Вообще, в современном мире линукса, X нужен только на Unix / Linux рабочих машинах, ибо ни на андроиде, ни на хромбуках они не нужны.

❯ X11: Архитектура и графический стек

X Window System (X11, или просто X) — это оконная система для растровых дисплеев, распространенная в Unix-подобных операционных системах.

X11 предоставляет графическую базу: создание, перемещение и удаление окон, взаимодействие с клавиатурой и мышью. X не определяет пользовательский интерфейс — этим занимаются отдельные программы. Таким образом стиль сред и оболочек, основанных на X, сильно различаются.

X был создан как часть проекта "Athena" в MIT в 1984 году. Протокол X имеет версию 11 (отсюда X11) с сентября 1987 года. Фонд X.Org возглавляет проект X с текущей эталонной реализацией, X.Org Server, доступный в виде открытого бесплатного программного обеспечения под лицензией MIT.

X11 (сам протокол) разрабатывался с целью быть расширяемым (т.е. с возможностью добавления новых фич без создания принципиально нового протокола и без потери обратной совместимости со старыми клиентами). Для примера, xeyes и oclock выглядят, скажем так, «нестандартно», из-за Shape Extension, которое позволяет использовать окна непрямоугольной формы. Если вам не очень понятно, с помощью какой магии эта функциональность появляется из ниоткуда, то вот ответ: магия тут ни при чём. Поддержка расширения должна быть добавлена на обеих сторонах — и у клиента, и у сервера. В базовой спецификации протокола есть специальный функционал для получения клиентами информации от сервера о доступных расширениях. С помощью этого функционала клиенты могут решать, что использовать, а что ­— нет.

X использует клиент-серверную модель. X-Сервер запускается на компьютере с графическим дисплеем и взаимодействует с различными клиентскими программами. X-сервер действует как посредник между пользователем и клиентскими программами, принимая запросы на TCP-порт 6000 + номер дисплея для графического вывода из клиентских программ и отображая их пользователю, а также получая ввод с клавиатуры или мыши и передавая его клиентам.

X-сервер запускается на компьютере пользователя, в то время как клиенты могут запускаться на удаленных машинах. Эта терминология меняет общее представление о клиент-серверных системах, где клиент обычно запускается на локальном компьютере, а сервер — на удаленном компьютере. Терминология X Window System исходит из того, что программа X Window находится в центре всей деятельности, то есть принимает все запросы и ввод.

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

На изображении выше отображен пример, когда X-сервер принимает ввод с клавиатуры и мыши и выводит на экран. Веб-браузер и эмулятор терминала запускаются на компьютере пользователя, а также сам эмулятор терминала запущен на удаленном сервере, но под управлением компьютера пользователя.

Сам X-клиент может эмулировать X-сервер, предоставляя услуги отображения другим клиентам. Это известно как "X-вложенность" (x nesting). Клиенты с открытым исходным кодом, такие как Xnest и Xephyr, поддерживают такую X-вложенность.

❯ Принципы X11

Боб Шейфлер и Джим Геттис изложили принципы X следующим образом:

• Не добавляйте новую функциональность, если разработчик не может завершить реальное приложение без нее.
• Решить, чем система не является, так же важно, как и решить, чем она является. Не удовлетворяйте все потребности мира; скорее, сделайте систему расширяемой, чтобы можно было удовлетворять дополнительные потребности совместимым образом.
• Единственное, что хуже обобщения на основе одного примера, — это обобщение вообще без примеров.
• Если проблема понята не до конца, вероятно, лучше вообще не предлагать никакого решения.
• Если вы можете получить 90 процентов желаемого эффекта за 10 процентов работы, используйте более простое решение. (Смотрите также, Чем хуже, тем лучше.)
• Максимально изолируйте сложность.
• Предоставьте механизм, а не политику. В частности, передайте политику пользовательского интерфейса в руки клиентов.
• Первый принцип был изменен во время разработки X11 следующим образом: Не добавляйте новую функциональность, если вы не знаете какого-либо реального приложения, которому это потребуется.

С тех пор X в основном придерживается этих принципов. Фонд X.Org разрабатывает эталонную реализацию с целью расширения и улучшения реализации, сохраняя при этом ее почти полную совместимость с первоначальным протоколом 1987 года.

Можно сказать, что эти принципы — это ответ на вопрос, как иксы дожили до наших дней.

❯ Основной протокол

Когда программа занимается отрисовкой, оно обращается к своей базовой библиотеке, а он уже переадресовывает вызов (или цепочку вызовов) в libX11, которая используя основной протокол X11 передает команды на X-сервер. X-сервер передает эти команды драйверам устройств вывода. Воздействие пользователя на устройства ввода считываются X-сервером через драйвера, после через протокол передаются клиенту, и только потом libX11 переводит команды протокола в события и передает их в тулкит, и уже он передает события программе.

За внешний вид программы отвечает библиотека-тулкит. Наиболее распространенные тулкиты на сегодняшний день — это Qt и GTK. Они примерно равны по возможностям, но GTK программы легче Qt-программ. Оба этих тулкита имеют поддержку сторонних тем внешнего вида.

Xlib (libX11) позволяет программе абстрагироваться и не связываться с низкоуровневыми функциями протокола, и благодаря этому появляется сетевая прозрачность X11.

Связь между сервером и клиентами осуществляется путем обмена пакетами по сети. Клиент устанавливает соединение, отправляя первый пакет. Сервер отвечает, отправляя обратно пакет, в котором указывается принятие или отказ от соединения, или запрос на дальнейшую аутентификацию. Если соединение принято, пакет подтверждения содержит данные, которые клиент может использовать при последующем взаимодействии с сервером.

После установления соединения клиент и сервер обмениваются четырьмя различными типами пакетов по каналу:

• Запрос: клиент запрашивает информацию у сервера или запрашивает его для выполнения действия.
• Ответ: сервер отвечает на запрос. Не все запросы генерируют ответы.
• Событие: сервер отправляет клиенту событие, например, ввод с клавиатуры или мыши, или перемещение, изменение размера или открытие окна.
• Ошибка: сервер отправляет пакет с ошибкой, если запрос недействителен. Поскольку запросы помещаются в очередь, пакеты ошибок, сгенерированные запросом, могут быть отправлены не сразу.

X-сервер предоставляет набор базовых служб. Клиентские программы реализуют более сложные функциональные возможности, взаимодействуя с сервером.

❯ Окна

То, что другие графические пользовательские интерфейсы обычно называют окном, является окном верхнего уровня в системе X Window. Окно может быть создано только как подокно родительского окна. Это приводит к иерархическому расположению окон в дереве. X-сервер автоматически создает корень дерева, называемый корневым окном. Окна верхнего уровня в точности являются прямыми подокнами корневого окна. Очевидно, что корневое окно, во первых, размером во весь кран, и во вторых, находится позади всех остальных окон.

На картинке выше вы можете увидеть возможное расположение некоторых окон: 1 — корневое окно, которое занимает весь экран; 2 и 3 — окна верхнего уровня; 4 и 5 — подокна 2. Части окна, которые находятся за пределами родительского, не видны.

❯ Идентификаторы

Все объекты в X имеют идентификатор. Это 32 битовое число, которое генерирует клиент и передает серверу, чтобы обозначить создаваемый объект. Например, окно, курсор, картинка и т.д.

X-сервер хранит все данные об окнах, шрифтах и т.д. Клиент знает идентификаторы этих объектов – целые числа, которые он может использовать в качестве имен для них при взаимодействии с сервером. Например, если клиент желает, чтобы было создано окно, он запрашивает сервер о его создании и (в случае успеха) получает взамен идентификатор сервера, связанный с вновь созданным окном. Этот идентификатор позже может быть использован клиентом для запроса, например, строки, которая будет отображаться в окне.

Идентификаторы уникальны для сервера, а не только для клиента; например, никакие два окна не имеют одинакового идентификатора, даже если они созданы двумя разными клиентами. Клиент может получить доступ к любому объекту, указав его идентификатор, даже если объект создан другим клиентом.

Другой тип идентификаторов это ATOM. Атомы это тоже 32 битовые числа, но их генерирует сервер. Клиент передает серверу какую-то символьную строку, а сервер в ответ дает число. Одинаковым строкам всегда соответствует одинаковое число. Это похоже на хеширование, но сделано по другому – сервер просто хранит список строк и присваивает им номера. Если какой-то клиент запросит атом для строки которая уже находится в списке, ему возвращают номер строки в списке.

Атомы используются прежде всего, чтобы разные клиенты могли обмениваться информацией друг с другом, используя стандартные текстовые идентификаторы.

А чтобы не грузить сетевой обмен длинными текстовыми идентификаторами, передаются собственно числа.

Чтобы снизить нагрузку на сервер, самые важные атомы определены в стандарте и всегда имеют одни и те же значения.

❯ Атрибуты и свойства

Каждое окно имеет предопределенный набор атрибутов и свойств, все они хранятся на X-сервере и доступны клиентам через вызовы (о вызовах мы поговорим позже). Атрибуты — это данные об окне, такие как его размер, цвет фона, положение и так далее. Свойства — это фрагменты данных, которые прикреплены к окну. В отличие от атрибутов, свойства не имеют значения на уровне основного протокола. Клиент может хранить произвольные данные в свойстве окна.

Свойство имеет имя, тип и значение. Свойства напоминают переменные в языках программирования — приложение может создать новое свойство с заданным именем и заданного типа и сохранить в нем значение. Свойства связаны с окнами: два свойства с одинаковым именем могут существовать в двух разных окнах, но иметь разные типы и значения.

Свойства в основном используются клиентами для клиентов. Например, свойство с именем WM_NAME хранит имя окна; оконные менеджеры могут считать это свойство и отобразить название окна.

Утилита xprop может отображать свойства окна. Например, xprop -root показывает свойства корневого окна, которые включают в себя X-ресурсы (параметры программ).

<code class="lang-bash"># Вот пример вывода xprop на моей машине - тайлинговый оконный менеджер XMonad на Arch Linux
 $ xprop -root

AT_SPI_BUS(STRING) = "unix:path=/run/user/1000/at-spi/bus_0,guid=8d51abf2a6cc210a6e8ac62965c881f4"
GDK_VISUALS(INTEGER) = 1095, 1373
_NET_DESKTOP_VIEWPORT(CARDINAL) = 0, 0, 0, 0, 0, 0, 0, 0
_NET_SUPPORTING_WM_CHECK(WINDOW): window id # 0x600001
_NET_SUPPORTED(ATOM) = _NET_WM_STATE, _NET_WM_STATE_FULLSCREEN, _NET_SUPPORTING_WM_CHECK, _NET_WM_NAME, _NET_WM_STATE_HIDDEN, _NET_WM_STATE_DEMANDS_ATTENTION, _NET_NUMBER_OF_DESKTOPS, _NET_CLIENT_LIST, _NET_CLIENT_LIST_STACKING, _NET_CURRENT_DESKTOP, _NET_DESKTOP_NAMES, _NET_ACTIVE_WINDOW, _NET_WM_DESKTOP, _NET_WM_STRUT, _NET_DESKTOP_VIEWPORT
_XMONAD_LOG(UTF8_STRING) = "<fc=#ffffff> <box type=VBoth width=3 color=#d3869b> 1 </box></fc> <fc=#d5c4a1>  2 </fc> <fc=#d5c4a1>  3 </fc> <fc=#7c6f64>  4 </fc><fc=#7c6f64> • </fc>Tall<fc=#7c6f64> • </fc><fc=#d3869b>[ </fc><fc=#d3869b><raw=13:xprop -root ~/></fc><fc=#d3869b> ]</fc>"
_NET_ACTIVE_WINDOW(WINDOW): window id # 0x1200006
_NET_CURRENT_DESKTOP(CARDINAL) = 0
_NET_CLIENT_LIST_STACKING(WINDOW): window id # 0x1200006, 0x1800006, 0x1600003
_NET_CLIENT_LIST(WINDOW): window id # 0x1200006, 0x1800006, 0x1600003
_NET_DESKTOP_NAMES(UTF8_STRING) = " 1 ", " 2 ", " 3 ", " 4 "
_NET_NUMBER_OF_DESKTOPS(CARDINAL) = 4
RESOURCE_MANAGER(STRING) = "Xft.antialias:<span class="hljs-symbol">t</span>1<span class="hljs-symbol">n</span>Xft.hinting:<span class="hljs-symbol">t</span>1<span class="hljs-symbol">n</span>Xft.autohint:<span class="hljs-symbol">t</span>0<span class="hljs-symbol">n</span>Xft.hintstyle:<span class="hljs-symbol">t</span>hintslight<span class="hljs-symbol">n</span>Xft.rgba:<span class="hljs-symbol">t</span>rgb<span class="hljs-symbol">n</span>Xft.lcdfilter:<span class="hljs-symbol">t</span>lcddefault<span class="hljs-symbol">n</span>st.font:<span class="hljs-symbol">t</span>iosevka nerd font:pixelsize=14<span class="hljs-symbol">n</span>st.borderpx:<span class="hljs-symbol">t</span>10<span class="hljs-symbol">n</span>st.alpha:<span class="hljs-symbol">t</span>0.9<span class="hljs-symbol">n</span>*background:<span class="hljs-symbol">t</span>#1F2020<span class="hljs-symbol">n</span>*foreground:<span class="hljs-symbol">t</span>#ebdbb2<span class="hljs-symbol">n</span>*color0:<span class="hljs-symbol">t</span>#282828<span class="hljs-symbol">n</span>*color8:<span class="hljs-symbol">t</span>#928374<span class="hljs-symbol">n</span>*color1:<span class="hljs-symbol">t</span>#fb4934<span class="hljs-symbol">n</span>*color9:<span class="hljs-symbol">t</span>#fb4934<span class="hljs-symbol">n</span>*color2:<span class="hljs-symbol">t</span>#b8bb26<span class="hljs-symbol">n</span>*color10:<span class="hljs-symbol">t</span>#b8bb26<span class="hljs-symbol">n</span>*color3:<span class="hljs-symbol">t</span>#fabd2f<span class="hljs-symbol">n</span>*color11:<span class="hljs-symbol">t</span>#fabd2f<span class="hljs-symbol">n</span>*color4:<span class="hljs-symbol">t</span>#83a598<span class="hljs-symbol">n</span>*color12:<span class="hljs-symbol">t</span>#83a598<span class="hljs-symbol">n</span>*color5:<span class="hljs-symbol">t</span>#d3869b<span class="hljs-symbol">n</span>*color13:<span class="hljs-symbol">t</span>#d3869b<span class="hljs-symbol">n</span>*color6:<span class="hljs-symbol">t</span>#8ec07c<span class="hljs-symbol">n</span>*color14:<span class="hljs-symbol">t</span>#8ec07c<span class="hljs-symbol">n</span>*color7:<span class="hljs-symbol">t</span>#ebdbb2<span class="hljs-symbol">n</span>*color15:<span class="hljs-symbol">t</span>#dacaa2<span class="hljs-symbol">n</span>"
ESETROOT_PMAP_ID(PIXMAP): pixmap id # 0x800001
_XROOTPMAP_ID(PIXMAP): pixmap id # 0x800001
_XKB_RULES_NAMES(STRING) = "evdev", "pc105", "us,ru", "", "grp:alt_shift_toggle"
XFree86_has_VT(INTEGER) = 1
XFree86_VT(INTEGER) = 1
</code>

❯ События (ивенты)

События всегда точно имеют длину 32 байта. Что такое длина в запросах и сами запросы, мы поговорим позже.

События — это запросы, пакеты, отправляемые сервером клиенту для сообщения о том, что произошло что-то, что может заинтересовать клиента. Клиент может запросить сервер отправить событие другому клиенту; это используется для связи между клиентами. Например, когда клиент запрашивает выделенный текст клиенту, который обрабатывает окно с выделенным текстом, отправляется событие.

Содержимое окна может быть "уничтожено" при некоторых условиях (например, если окно закрыто). Всякий раз, когда область уничтоженного содержимого становится видимой, сервер генерирует событие Expose, уведомляющее клиента о том, что часть окна должна быть отрисована.

Другие события могут служить для уведомления клиентов о вводе данных с клавиатуры или мыши, о создании новых окон и т.д.

Некоторые виды событий всегда отправляются клиенту, но большинство видов событий отправляются только в том случае, если клиент ранее заявлял о своей заинтересованности в них, поскольку клиенты могут быть заинтересованы только в каких-то событиях. Например, клиент может быть заинтересован в событии, связанном с клавиатурой, но не в событиях, связанных с мышью.

Вот пример события (источник):

<code class="lang-cpp">   while(<span class="hljs-number">1</span>) {
     <span class="hljs-type">XNextEvent</span>(d, &e);
                        /* отрисовка окна */
     <span class="hljs-keyword">if</span>(e.<span class="hljs-keyword">type</span>==<span class="hljs-type">Expose</span>) {
       <span class="hljs-type">XFillRectangle</span>(d, w, <span class="hljs-type">DefaultGC</span>(d, s), 20, 20, 10, 10);
     }
                        /* выход на нажатие клавиши */
     <span class="hljs-keyword">if</span>(e.<span class="hljs-keyword">type</span>==<span class="hljs-type">KeyPress</span>)
       break;

     // Обработчик закрытия окна
     <span class="hljs-keyword">if</span>(e.<span class="hljs-keyword">type</span>==<span class="hljs-type">ClientMessage</span>)
        break;
   }
</code>

❯ Цветовые режимы

Большинство современных программ используют полноцветный режим (24 разрядный цвет, по 8 бит для каждого из красного, зеленого и синего), но некоторым старым и специализированным приложениями требуется другой цветовой режим. Из-за этого возникает путаница насчет цветов.

Протокол X11 фактически использует одно 32-разрядное целое число без знака (unsigned), называемое значением пикселя, для представления одного цвета в большинстве графических операций. При передаче интенсивности для каждого цветового компонента используется 16-разрядное целое число.

• DirectColor: Значение пикселя разбивается на отдельные подполя red, green и blue. Каждое подполе индексирует отдельную цветовую карту. Записи во всех цветовых картах могут быть изменены.
  • TrueColor: То же, что и DirectColor, за исключением того, что элементы цветовой карты предопределены аппаратным обеспечением и не могут быть изменены. Как правило, каждая из красных, зеленых и синих цветовых карт обеспечивает (почти) линейный диапазон интенсивности.

• GreyScale: Значение в пикселях индексирует одиночную цветовую карту, содержащую интенсивности монохромного изображения. Элементы цветовой карты могут быть изменены.
  • StaticGray: То же, что и оттенки серого, за исключением того, что элементы цветовой карты предопределены аппаратным обеспечением и не могут быть изменены.

• PseudoColor (прерывистый, chunky): Значение в пикселях индексирует одну цветовую карту, содержащую значения интенсивности цвета. Элементы цветовой карты могут быть изменены.
  • StaticColor: То же, что и PseudoColor, за исключением того, что элементы цветовой карты предопределены аппаратным обеспечением и не могут быть изменены.
    Смотрите также: Названия цветов X11

❯ Запросы

Все запросы в X11 бинарные, с полями разной длины. По сути, здесь есть поля длиной в 1 байт, 2 байта и 4 байта.

Первые 4 байта запроса всегда присутствуют и всегда содержат одинаковую информацию:

Прочтя этот заголовок, сервер уже знает сколько байт (а точнее двойных слов) еще надо прочесть, чтобы забрать весь запрос.

❯ Графика в Linux

Как мы уже говорили, X11 не отвечает за всю графику в Linux. В этом помогают ему технологии, библиотеки, тулкиты.

Cairo

Cairo — библиотека для отрисовки 2D векторной графики, использующаяся как обычными приложениями, так и различными тулкитами по типу GTK или Qt. Например, модель отрисовки GTK3 и 4 полностью основана на cairo, даже при компиляции программы на GTK3/4 нужна будет библиотека cairo. Если вы работали с HTML-элементов , то вы имеете достаточно полное представление и о cairo. Несмотря на то, что изначально был представлен фирмой Apple, векторная графика родилась гораздо раньше (ещё начиная с модели отрисовки PostScript, которая нашла своё отражение в разных стандартах. Cairo может взаимодействовать с xlib-бекендом

В современное время cairo используется по умолчанию как обязательный компонент в GTK.

❯ Расширение XRender

Для поддержки отрисовки графических геометрических примитивов в протоколе X11 есть расширение XRender. Кроме отрисовки примитивов с антиалисингом, это расширение позволяет использовать градиенты.

pixman

X-сервер и cairo требуют работу с пикселями. Ранее они по разному реализовали работу с попиксельным доступам к буферам, градиентам и т.д. Теперь cairo и X-сервер делают все это через низкоуровневую разделяемую библиотеку pixman. Также у этой библиотеки нету API.

❯ OpenGL, mesa

Это интересная часть нашей статьи — она затрагивает аппаратное ускорение.

Я думаю, каждый слышал об OpenGL. Это не библиотека, и не набор исходников для сборки libGL.so. У каждого производителя своя собственная libGL.so, так или иначе совместимая со спецификацией OpenGL.

Если вы используете открытые драйверы, то реализация вашей libGL.so, скорее всего, основана на mesa. Mesa — это некий драйвер, а также часть графического стека, но основная тема — открытая реализация OpenGL. Внутри самой mesa за OpenGL API используются различные бэкенды для трансляции API в исполнительные команды.

❯ Шрифты

В X11 с самого начала разработки выводом шрифтов управлял X-сервер. Клиент, когда ему требовалось вывести текст, просто говорило X-серверу «отобрази этот текст этим шрифтов в этом месте». В ответ на это X-сервер выбирал шрифт, и использовал его. Изначально эти шрифты были растровыми.

Эта технология называется X Core Fonts, поддерживается в иксах и сейчас, поэтому в репозиториях любого дистрибутива чаще всего есть некоторые распространенные шрифты — fixed, helvetica, times, courier. При этом каждый шрифт имеет множество файлов, для каждого варианта размера (от 8 до 18), две ширины (обычный и жирный) и два начертания (стандартный и наклонный). Примерно получается 40 файлов.

Поскольку количество файлов получается очень большим, чтобы не устанавливать все эти шрифты на все компьютеры где запущены X-серверы, в систему X11 был введен такой объект как сервер шрифтов (font server). Системный администратор может настроить и запустить один сервер шрифтов для всей локальной сети, и указать X-серверу при запуске использовать шрифты с соответствующего сервера, что позволяет поддерживать на всех серверах один и тот же набор шрифтов с минимальными усилиями и избежать ситуации когда шрифт есть на одном компьютере, но его нет на другом.

В новейшей версии проекта Xorg сервер шрифтов уже призназ устаревшим и по умолчанию не используется.

❯ Заметки

Графическая подсистема X.Org Server состоит из двух частей.

DIX — Device Independent X, что переводится как X не зависящий от устройств, в основном это программный рендеринг.
DDX — Device Dependent X, что переводится как X зависимый от устройств, взаимодействие с графической картой, устройствами ввода.

❯ Общение между клиентами

Основной протокол X Window предоставляет механизмы для взаимодействия между клиентами: свойства окна и события, в частности события обмена сообщениями между клиентами. Однако в нем не указаны правила для таких взаимодействий. Вместо этого этими правилами управляет отдельный набор соглашений о взаимодействии между клиентами.

Руководство по соглашениям о взаимодействии между клиентами определяет протокол для обмена данными посредством выбора и взаимодействия приложений с оконным менеджером. Некоторые считают эту спецификацию сложной; согласованность внешнего вида приложения и взаимодействия обычно достигается путем программирования для данной среды рабочего стола

Протокол X Window core предоставляет механизмы для взаимодействия между клиентами: свойства окна и события, в частности события обмена сообщениями между клиентами. Однако в нем не указан какой-либо протокол для таких взаимодействий. Вместо этого этими протоколами управляет отдельный набор соглашений о взаимодействии между клиентами.

Спецификации freedesktop включают в себя новые соглашения, в том числе соглашение о перетаскивании Xdnd (используется для передачи данных путем их выбора и перетаскивания в другое окно) и соглашение о встроенных приложениях Xembed (в котором подробно описывается, как приложение может запускаться в подокне другого приложения).

❯ Реализации X11

X.Org является канонической реализацией X11. Благодаря либеральному лицензированию появился ряд вариаций, как бесплатных, так и с открытым исходным кодом и проприетарные расширения. Коммерческие поставщики Unix-систем берут эталонную реализацию и адаптируют ее для своего оборудования, обычно настраивая ее и добавляя проприетарные расширения.

До 2004 года стандартом был не X.Org, а XFree86. Он предоставлял самый распространенный вариант X в бесплатных Unix-системах. XFree86 начинался как порт X для ПК, совместимых с 386 процессором. К конце 90-х годов прошлого века он стал крупнейшим источником технических инноваций в X и стандартом разработки X.

Но после 2004 года форк XFree86 — X.Org — стал новым стандартом и популярнее XFree86.

Хотя принято ассоциировать X с Unix, серверы X также изначально существуют в других графических средах. Операционная система OpenVMS от VMS Software Inc. включает версию X с Common Desktop Environment (CDE), известную как DECwindows, в качестве стандартной среды рабочего стола. Первоначально Apple портировала X на macOS в виде X11.app, но это было отменено в пользу реализации XQuartz. Сторонние серверы под управлением старых операционных систем Apple 1990-х годов, System 7 и Mac OS 8 и 9, включали MacX от Apple и eXodus от White Pine Software.

Windows не поставляется с поддержкой X, но существует множество сторонних реализаций, таких как бесплатное программное обеспечение с открытым исходным кодом, такое как Cygwin/X, и проприетарные продукты, такие как Exceed, MKS X/Server, Reflection X, X-Win32 и Xming.

Существуют также Java-реализации X-серверов. WeirdX работает на любой платформе, поддерживающей Swing 1.1, и будет запускаться как апплет в большинстве браузеров. Android X Server — это Java-реализация с открытым исходным кодом, которая работает на устройствах Android.

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

❯ Менеджер окон

Оконный менеджер — это программа, которая управляет общим внешним видом окон и другими элементами графического интерфейса.

Оконный менеджер заботится о выборе положения окон, размещении декоративной рамки вокруг них, обработке значков, обработке щелчков мыши вне окон (на “заднем плане”), обработке определенных нажатий клавиш и т.д.

С точки зрения X-сервера, оконный менеджер работает как клиент, как и любой другой клиент. Начальное положение и декоративные границы вокруг окон обрабатываются оконным менеджером с помощью следующих запросов:

• приложение может запросить сервер не удовлетворять запросы на отображение подокон данного окна и вместо этого отправлять событие;
• приложение может запросить изменение родительского элемента окна.

Диспетчер окон использует первый запрос для перехвата любого запроса на сопоставление окон верхнего уровня (дочерних элементов корневого окна). Всякий раз, когда другое приложение запрашивает сопоставление окна верхнего уровня, сервер не выполняет этого, а вместо этого отправляет событие диспетчеру окон. Большинство оконных менеджеров перестраивают окно: они создают окно верхнего уровня большего размера (называемое окном фрейма) и перестраивают исходное окно как дочернее по отношению к нему. Графически это соответствует размещению исходного окна внутри окна фрейма. Пространство окна frame, которое не занято исходным окном, используется для декоративной рамки вокруг окна (“граница” и “строка заголовка”).

Оконный менеджер также обрабатывает значки и связанные с ними визуальные элементы графического интерфейса. Значки не существуют на уровне протокола X Window core. Они реализуются оконным менеджером. Например, всякий раз, когда окно должно быть “обозначено значком”, оконный менеджер FVWM отменяет отображение окна и создает окно для имени значка и, возможно, другое окно для изображения значка. Таким образом, значение значков и обработка с ними полностью определяются оконным менеджером: некоторые оконные менеджеры, такие как wm2, вообще не реализуют значки.

❯ Ограничения, проблемы и недостатки X11

Руководство Unix-ненавистников (Unix-Haters, 1994) посвятило целую главу проблемам X! Ну и я постарался собрать со всего интернета недостатки иксов, попутно добавляя своих.

Отсутствие рекомендаций по проектированию в X привело к появлению нескольких совершенно разных интерфейсов и приложений, которые не всегда хорошо работали вместе. Руководство по соглашениям о взаимодействии между клиентами (ICCCM), спецификация для взаимодействия с клиентами, имеет репутацию трудной для правильной реализации. Дальнейшие усилия по стандартизации, такие как Motif и CDE, не облегчили проблем. Это разочаровывает пользователей и программистов. Графические программисты теперь обычно добиваются согласованности внешнего вида приложения и взаимодействия с ним, создавая код для конкретной среды рабочего стола или для определенного набора инструментов виджетов, что также позволяет избежать необходимости иметь дело непосредственно с ICCCM.

В X также отсутствует встроенная поддержка пользовательских хранимых процедур на сервере X, что является новостью — нет возможности создания сценариев с полным набором по Тьюрингу. Таким образом, различные среды рабочего стола могут предлагать свои собственные (обычно взаимно несовместимые) возможности.

❯ Проблемы, связанные с доступом к компьютеру

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

Проект Orca добавляет поддержку специальных возможностей в систему X Window, включая реализацию API (AT-SPI). Это в сочетании с ATK от GNOME позволяет реализовать функции специальных возможностей в программах X с использованием API GNOME/GTK. KDE предоставляет другой набор программного обеспечения для специальных возможностей, включая конвертер текста в речь и экранную лупу. Другие основные настольные компьютеры (LXDE, Xfce и Enlightenment) пытаются быть совместимыми с ATK.

❯ Сеть

Клиент X, как правило, не может быть отсоединен от одного сервера и повторно подключен к другому, если это специально не предусмотрено его кодом (Emacs — одна из немногих распространенных программ, обладающих такой возможностью). Таким образом, перемещение всего сеанса с одного сервера X на другой, как правило, невозможно. Однако такие подходы, как виртуальные сетевые вычисления (VNC), NX и Xpra, позволяют осуществлять доступ к виртуальному сеансу с разных X-серверов (способом, аналогичным GNU Screen по отношению к терминалам), а другие приложения и наборы инструментов предоставляют соответствующие возможности. Также существуют обходные пути, такие как x11vnc (VNC :0 viewers), теневой режим Xpra и теневой режим nxagent от NX, чтобы сделать доступным текущий экран X-сервера. Эта возможность позволяет переключать пользовательский интерфейс (мышь, клавиатуру, монитор) запущенного приложения из одного места в другое без остановки и перезапуска приложения.

Сетевой трафик между X-сервером и удаленными X-клиентами по умолчанию не шифруется. Злоумышленник с анализатором пакетов может перехватить его, что позволяет просматривать все, что отображается на экране пользователя или отправляется с него. Наиболее распространенным способом шифрования X-трафика является создание туннеля Secure Shell (SSH) для обмена данными.

Как и во всех клиентах, при использовании X по сети ограничения пропускной способности могут препятствовать использованию приложений с интенсивным использованием растровых изображений, требующих быстрого обновления больших участков экрана с низкой задержкой, таких как 3D-анимация или редактирование фотографий. Даже относительно небольшой несжатый видеопоток 640×480×24 бит со скоростью 30 кадров в секунду (~211 Мбит/с) может легко превысить пропускную способность сети со скоростью 100 Мбит/с для одного клиента. Напротив, современные версии X обычно имеют расширения, такие как Mesa, позволяющие оптимизировать локальное отображение графики локальной программы в обход сетевой модели и напрямую управлять видеокартой для использования полноэкранного видео, рендеринга 3D-приложений и других подобных приложений.

❯ Тиринг

Тиринг, если в двух словах это “разрыв” картинки, который очень часто встречается на Линуксе. Все дело в устаревшей технологии дисплейного менеджера X.Org, который в ближайшие годы будет заменен полностью, на современную реализацию Wayland.

Чтобы минимизировать эффект тиринга в Linux/X11, нужно поддерживать частоту кадров как можно ближе к частоте экрана.

Также рекомендуется использовать OpenGL для полной ликвидации тиринга. Если же хочется использовать программную рендеринг, можно применить метод обновления грязных прямоугольников.

Тиринг очень большой недостаток X11. Исправить можно его, используя TearFree (но даже он не так хорош как следовало бы).

Как исправить тиринг на разных видеокартах

❯ Сложности работы двух мониторов с разным dpi или частотой обновления

Это практически невозможно заставить нормально работать в X11.

Вот топик на форуме Archlinux про это, а вот уже на форуме linux.org.ru

Неплавность анимаций

Об этом и говорить нечего. Такой же недостаток, как в прошлом пункте.

Устаревшая кодовая база, с которой сложно работать

Кодовая база иксов очень старая, и сложная. В коде полно философских комментариев по типу "никто не хочет рассказывать как это работает, или никто не знает...".

Код Xlib очень раздутый и старый, а его альтернатива XKB плохо продвигается.

Другие недостатки

Некоторые проблемы и критика может относиться не только к X11, но и ко всему линуксу

• Дробное масштабирование
• Задержка (latency) в несколько кадров
• Поддержка HDR (high dynamic range, 10bit/channel or more)
• Небезопасность (можно написать запросто написать кейлоггер или скрипт, который ворует пиксели с экрана, и все на простом баше)
• Поддержка переменной частоты развертки (vrr)
• Отсутствие поддержки новых версий GL в протоколе glx
• Автоподключение внешнего GPU
• Мультикасание, трансформация координат ввода
• Отсутствие поддержки множества слоёв (поверхностей) видеовывода
• Изоляция приложений
• Медленная работа (у меня лично wayland работал чуть быстрее чем иксы, но это мнение)

❯ История X

X был разработан как часть проекта Athena в недрах Массачусетского технологического института (MIT) летом 1984 года. А сам X11 был выпущен в 1987 году.

Когда-то всех устраивали простые программы с очень простым интерфейсом, но позже стали появляться более мощные и быстрые устройства: могло быть несколько GPU и мониторов, а также множество устройств ввода. Рендеринг стал сложнее, появился OpenGL, о котором мы говорили ранее.

Оконная система X стала обрастать расширениями, но ядро протокола осталось нетронутым. На любые нюансы находились обходные пути, костыли, велосипеды. Разработчики поняли, что иксы нужно менять в срочном порядке, но начались проблемы с лицензией XFree86. После того как дебаты по поводу лицензий утихли, разработчики иксов стали разделяться, и большинство из них выбрало X.Org на лицензии GPL. Разработчики вновь взялись за работу.

В итоге монолитный код иксов разбили на около 345 частей, правда половина из них оказалась не нужна. После код в иксах начали чистить и форматировать. Количество строк кода сильно уменьшалось. А все эти нюансы с управлением памятью, modesettings, устройствами ввода ушли в ядро.

Функции иксов значительно уменьшились после всего этого действия. Остались базовые, нужные вещи. Основная ведь работа иксов — это посредничать между X-клиентом и оконным менеджером.

Помимо этого остались ограничения, наложенные обратной совместимостью — эти архитектурные недостатки нельзя убрать или обойти, не ломая совместимость со старыми Motif-программами. Тиринг, неравномерная отрисовка, артефакты обновления, это все очень не может исчезнуть просто так. Из-за этого появляется превосходство Wayland.

Но ведь 37 лет назад все это сделало прогрессивный шаг для IT индустрии. Благодаря иксам Unix/Linux десктопы получили унифицированную графическую среду. Иксы обошли всех тогдашних конкурентов благодаря кроссплатформенности иксов, возможность запускать программы поверх стека TCP/IP.

Но явно разработчики иксов были еще-те любители овер-инжиниринга — они много где перемудрили. Принцип обеспечения механизмов, но не политики впоследствии сыграл злую шутку с экосистемой X.

Разработчики еще могли управлять старым поездом под названием X Window System, благодаря интеграции значительной части функций иксов в ядро, но уголь, ресурс, скоро закончится, если уже не кончился.

Кстати, до появления X существовали также несколько растровых дисплейных серверов. Из Xerox пришли Alto и Star. В Apple были разработаны Lisa и Macintosh. В мире Unix существовали терминал Blit и проект Andrew.

X получила свое имя как преемница W Window System (в латинском алфавите после W идет X).

В 1987 году, когда успех X11 стал очевидным, MIT отказался от дальнейшего управления иксами. Но однако на собрании поставщиков было решено, что нужна нейтральная сторона, которая бы предотвращала бы распад X на рынке. Этой стороной стала группа "Консорциум X MIT". После был сформирован преемник этой группы — некоммерческая корпорация X Consortum, Inc.

На текущее время последняя версия иксов — это X11R7.7, выпущенная 6 июня 2012 года.

❯ X.Org и XFree86

Проект XFree86 возник в 1992 году. Позже, в 1999 году был основан X.Org, форк XFree86.

Wayland как замена X11

Лишь один из протоколов, графических серверов дожил до наших дней и стал более-менее популярным и стабильным — это Wayland. Есть конечно Mir, но кому он нужен?

Для начала немного узнаем, что связано с вейландом:

• Композитор/Compositor — композитный оконный менеджер. Можно сказать, что он отвечает за анимации, прозрачность и все остальное, то есть создает композицию графических эффектов. Вот примеры композиторов в мире линукса:
  • Weston — эталонный композитный менеджер для Wayland
  • Muffin — композитор в cinnamon
  • Mutter — композитор в Gnome (поддерживает wayland)
  • Marco — композитор MATE
  • KWin — композитор KDE (поддерживает Wayland)
  • Sway – тайлинговый композитный оконный менеджер. Sway использует wlroots – модульную реализацию Wayland, которая функционирует как база для нескольких композиторов.

EGL — независимый от платформы аналог OpenGL GLX/AGL/WGL, разрабатываемый Khronos Group.

EGL в отличие от GLX/AIGLX умеет выполнять лишь direct rendering, в котором приложения через DRI2/DRI3 могут безопасно и быстро получать доступ к видеокарте минуя X-сервер.

Wayland — протокол взаимодействия между композитным оконным менеджером и клиентами, а также его библиотечная реализация в C.

• Цель: радикально упростить графическую среду Linux по сравнению с X11.
• Использует Unix Domain Sockets, сетевой прозрачности нет.
• Главным образом использует EGL и DRI.
• Устройства ввода-вывода управляются полностью из ядра.
• Распределение буфера и отрисовка полностью на стороне клиента.

На самом нижнем уровне протокола клиент и композитным оконным менеджером синхронизируют сообщения, обмениваются упорядоченными объектами, используя средства IPC библиотек libwayland-client и libwayland-server. На этом уровне не определены способы управления оконным интерфейсом — только сообщения, передаваемые через Unix Domain Sockets, объекты и события.

Протокол Wayland описывается как "асинхронный объектно-ориентированный протокол".  Объектно-ориентированный означает, что услуги, предлагаемые компоновщиком, представлены в виде серии объектов, работающих на одном и том же компоновщике. Каждый объект реализует интерфейс, который имеет имя, ряд методов (называемых запросами), а также несколько связанных событий. Каждый запрос и событие имеют ноль или более аргументов, каждый из которых имеет имя и тип данных. Протокол является асинхронным в том смысле, что запросам не нужно ждать синхронизированных ответов или подтверждений, что позволяет избежать задержки в оба конца и повысить производительность.

Клиенты Wayland могут сделать запрос (вызов метода) к некоторому объекту, если интерфейс объекта поддерживает этот запрос. Клиент также должен предоставить необходимые данные для аргументов такого запроса. Именно таким образом клиенты запрашивают услуги у составителя. Компоновщик, в свою очередь, отправляет информацию обратно клиенту, заставляя объект генерировать события (вероятно, тоже с аргументами). Эти события могут генерироваться компоновщиком в ответ на определенный запрос или асинхронно, в зависимости от возникновения внутренних событий (например, от устройства ввода) или изменений состояния. Условия ошибки также сигнализируются компоновщиком как события.

Чтобы клиент мог сделать запрос к объекту, ему сначала необходимо сообщить серверу идентификационный номер, который он будет использовать для идентификации этого объекта. В компоновщике есть два типа объектов: глобальные объекты и неглобальные объекты. Глобальные объекты объявляются компоновщиком клиентам при их создании (а также при их уничтожении), в то время как неглобальные объекты обычно создаются другими объектами, которые уже существуют как часть их функциональности.

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

Протокол Wayland работает путем выдачи запросов и событий, которые действуют на объекты. Каждый объект имеет интерфейс, который определяет возможные запросы и события, а также подпись каждого из них.

Проводной протокол представляет собой поток 32-битных значений, закодированных в порядке байтов хоста (например, в процессорах семейства x86 с прямым порядком байтов). Эти значения представляют следующие примитивные типы:

• int, uint: 32-битное целое число со знаком или без знака.
• fix: 24,8-битные числа с фиксированной запятой со знаком.
• object: 32-битный идентификатор объекта.
• new_id: 32-битный идентификатор объекта, который выделяет этот объект при получении.
  Помимо этих примитивов, используются следующие другие типы:
• string: строка с префиксом 32-битного целого числа, указывающим ее длину (в байтах), за которой следует содержимое строки и терминатор NUL, дополненная до 32 бит неопределенными данными. Кодировка не указана, но на практике используется UTF-8.
• array: блок произвольных данных с префиксом 32-битного целого числа, определяющего его длину (в байтах), а затем дословное содержимое массива, дополненное до 32 бит неопределенными данными.
• fd: 0-битное значение на основном транспорте, но передает дескриптор файла на другой конец, используя вспомогательные данные в сообщении сокета домена Unix (msg_control).
• enum: одно значение (или растровое изображение) из перечисления известных констант, закодированное в 32-битное целое число.

Проводной протокол представляет собой поток сообщений, построенный с помощью этих примитивов. Каждое сообщение — это событие (в случае сообщений от сервера к клиенту) или запрос (от клиента к серверу), который воздействует на объект.

Заголовок сообщения состоит из двух слов. Первое слово — это идентификатор затронутого объекта. Второе — два 16-битных значения; старшие 16 бит — это размер сообщения (включая сам заголовок), а нижние 16 бит — это код события или запроса. Далее следуют аргументы сообщения, основанные на подписи сообщения, заранее согласованной обеими сторонами. Получатель просматривает интерфейс идентификатора объекта и событие или запрос, определенный его кодом операции, чтобы определить подпись и характер сообщения.

Чтобы понять сообщение, клиент и сервер должны сначала установить объекты. Идентификатор объекта 1 предварительно назначается как одноэлементное изображение Wayland и может использоваться для начальной загрузки других объектов.

❯ Проблемы и недостатки Wayland

Несмотря на то, что противников Wayland становится меньше, и его постепенно добавляют в линукс, у него есть недостатки.

Фанфакт: Симон Петер, создатель формата самодостаточных пакетов AppImage и создатель BSD-системы HelloSystem призвал бойкотировать Wayland "так как он ломает все"

• Wayland обязывает рисовать битмапы окон, даже если окно полностью перекрыто другими окнами.
• Отрисовка окна вызывается на 100%, даже когда окно наполовину скрыто.
• Wayland плохо совместим с программами для записи экрана. Но судя по всему, этот недостаток постепенно убирают
• Wayland плохо совместим с программами для совместного использования экрана. Постепенно эта проблема тоже убирается
• Wayland несовместим с глобальным меню в GNOME и на базе Qt
• Wayland плохо совместим с пакетами AppImage без специального Qt-плагина.
• Wayland имеет XWayland, wlroots, waypipe, что значит неудобства. Для SDL2 приходится прописывать переменные окружения. Этот недостаток легко исправляется и не такой, на самом деле, недостаток.
• В Wayland нет замены Xembed
• Мало софта работает на Wayland, особенно без XWayland
• Проблемы с драйверами видеокарт (особенно NVIDIA)

Прошу в комментарии, если вы нашли еще минус, или наоборот, считайте что одна из перечисленных проблем надуманна.

Еще могу добавить — DWL, форк DWM для Wayland, плохо и криво работает. Компилировать надо с иконой в руках, еще и не факт, что нормально запустится. Также основа DWM — патчи, очень проблемно встают на DWL, если вообще встают. Хотя может быть это проблема DWL, а не Wayland.

Еще один нюанс — довольно мало DE и WM под Wayland есть, если у вас свои требования. Например, в XFCE, MATE нет поддержки Wayland, хотя это не самые последние DE. Также один из популярнейших WM — bspwm, также не работает под Wayland. А вообще, об оболочках и оконных менеджерах поговорим позже.

❯ Wayland или X11?

Решающий момент. Мой выбор — сегодня иксы, завтра вяленый!

Почему? Вяленый еще активно дорабатывается, есть нюансы в архитектуре, проблемы с драйверами, не везде они работают, проблемы с софтом. Скорее всего, в ближайшие лет 5 Wayland активно будет развиваться и большинство недостатков будет решено. А пока приходится использовать иксы, они пока стабильнее вейланда.

Но это мое мнение, вы можете думать по другому.

Различия

Здесь я приведу различия между Wayland и X11

Архитектура

Композитор является отдельной дополнительной функцией в X, в то время как Wayland объединяет display server и compositor в единую функцию. Кроме того, он включает в себя некоторые задачи оконного менеджера, который в X является отдельным процессом на стороне клиента.

Компоновка

Компоновка необязательна в X, но обязательна в Wayland. Компоновка в X является "активной"; то есть компоновщик должен извлекать все пиксельные данные, что приводит к задержке. В Wayland компоновка является "пассивной", что означает, что компоновщик получает пиксельные данные непосредственно от клиентов. 

Визуализация

Сам X-сервер способен выполнять рендеринг, хотя ему также можно дать команду отобразить отрисованное окно, отправленное клиентом. В отличие от этого, Wayland не предоставляет никакого API для рендеринга, но делегирует клиентам такие задачи (включая рендеринг шрифтов, виджетов и т.д.). Оформление окон должно отображаться на стороне клиента (например, с помощью графического инструментария) или на сервере. бок о бок (с помощью композитора) с включенным протоколом xdg-decoration, если композитор решит реализовать такую функциональность.

Безопасность

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

Коммуникация между запросами

X-сервер предоставляет базовый метод взаимодействия между X-клиентами, позже расширенный соглашениями ICCCM. Это взаимодействие X-клиент-клиент используется оконными менеджерами, а также для реализации X-сеансов, выбора и перетаскивания и других функций. Основной протокол Wayland вообще не поддерживает обмен данными между клиентами Wayland, поскольку соответствующая функциональность (при необходимости) рассматривается сообществом Wayland как нечто, что должно быть реализовано средами рабочего стола (такими как KDE или GNOME) или третьей стороной (например, с помощью встроенного IPC базового протокола). операционная система).

Сеть

Система X Window — это архитектура, которая по своей сути была разработана для работы по сети. Wayland сама по себе не обеспечивает прозрачность сети; однако разработчик может реализовать любой протокол удаленного рабочего стола для достижения удаленного отображения. Кроме того, проводятся исследования в области потоковой передачи изображений Wayland и сжатия, которые обеспечили бы удаленный доступ к буферу кадров, аналогичный доступу VNC.

❯ Почему будущее за wayland

Почему все таки будущее за Wayland, а не за иксами или другим графическим сервером?

Первый плюс — отсутствие конфигурационного файла xorg.conf, ведь это неудобно. Конечно-же, если хорошо его отредактировать, то иксы похорошеют. Но кто станет это делать?

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

А работа с устройствами в Wayland — это XInput 2.2, но без легаси кода и улучшенным порядком между устройствами. Глобальный объект seat, т.е место определяет группу устройств ввода, включая мышь, клавиатуру и так далее. Та самая проблема с мультитачем исчезнет.

А также:

• Wayland не имеет API для отрисовки.
• Wayland минимален, нет никаких ненужных функций, все функции распределены между клиентами
• Обязательная компоновка (композитинг). Это удаляет тиринг, никаких проблем с кадрами.
• Никаких шрифтов на сервере
• Wayland пишут разработчики X, которые устали исправлять ошибки, удалять костыли, чинить и очищать код.

❯ DE и WM на wayland

Wayland стал проникать в десктоп линукса. Уже есть довольно большое количество оболочек и оконных менеджеров для него, но конечно же намного меньше чем иксовых.

Давайте же узнаем, какие есть окружения рабочего стола и оконники на линуксе!

Gnome

Один из самых популярных DE. И по моему скромному мнению, один из лучших, если не лучший DE.

• Потребление ресурсов: примерно от 0.8 ГБ до 1.5 ГБ (Arch Linux) потребления ОЗУ. При оптимизации можно довести до ~600-700 мегабайт.
• Развитие, популярность: 4/5. Благодаря популярности DE, у него довольно большой бюджет. Например, он получал деньги и от Microsoft, и от немецких фондов. Сейчас весь бюджет Gnome Foundation около 12 миллионов евро, и это все при том, что это некоммерческая организация. Но развивается все равно, не так охотно, а точнее есть небольшие проблемы, как хотелось бы.
• Поддержка Wayland: есть, сессия Wayland обычно по умолчанию
• Моя личная оценка: 4/5

Также несомненным плюсом является проект Gnome Circle — разработчик может создать программу, ее могут принять в Gnome, и тогда разработчик получит славу и место в Gnome Foundation.

KDE Plasma 5/6

Популярный DE. Считается одним из лучших. Основан на Qt-фреймворке. Мне лично не нравится, кажется каким то перегруженным и нестабильным.

• Потребление ресурсов: примерно от 0.6 до 1.2 ГБ (Arch Linux)
• Развитие и популярность: 3.8/5. Как по мне, могли бы создать его получше. Большинство KDE-программ перегружены и неудобны. Но очень мне нравится файловый менеджер dolphin и его работа с архивами. Также не видно сильного развития.
• Поддержка Wayland: есть, сессия Wayland обычно по умолчанию
• Моя личная оценка: 3/5

Cinnamon (экспериментально)

Форк третьего гнома, разрабатывается Linux Mint. Имеет классический виндоподобный интерфейс.

• Потребление ресурсов: примерно от 0.6 до 1 ГБ (Arch Linux)
• Развитие и популярность: 3.5/5. Не сильно популярен, но постепенно развивается.
• Поддержка Wayland: экспериментально
• Моя личная оценка: 3/5

Есть момент, что виджеты и расширения могут уронить Cinnamon.

Mate (частично)

Форк второго гнома, создан одним аргентинским разработчиком. Названия программ чаще всего на испанский манер. Поддержка Wayland в нем частичная. Можно попробовать запустить mate-panel и wayland-композитор (например sway) и создать такое небольшое окружение.

• Потребление памяти: примерно от 0.4 до 0.8 ГБ (Arch Linux)
• Развитие и популярность: 3/5. Развивается постепенно, не спешат добавлять новые функции, но и не оставляют легаси код. Малопопулярен.
• Поддержка wayland: частичная и экспериментальная
• Моя личная оценка: 4/5

Sway

Композитный тайлинговый оконный менеджер, основанный на wlroots, замена i3wm для Wayland.

• Потребление памяти: около 200-300мб (Arch Linux)
• Развитие и популярность: 4/5. Активно развивается, довольно популярен
• Поддержка wayland: полная
• Моя личная оценка: 4/5

Hyprland

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

• Потребление памяти: около 300МБ (Arch Linux)
• Развитие и популярность: 4/5. Большая фанбаза, активно развивается.
• Поддержка wayland: полная
• Моя личная оценка: 4/5

Wayfire

Аналог Compiz на Wayland. Оконный менеджер.

• Потребление памяти: около 500мб (Arch Linux)
• Развитие и популярность: 2.5/5. Непопулярен, развитие нормальное.
• Поддержка Wayland: полная
• Оценка: 2/5

❯ Почему Wayland сырой

Было множество попыток поменять X.Org на другой графический сервер. Berlin, Fresco, Y Window System, Mir, Wayland — и это еще не все. Из всех этих проектов достиг признания только Wayland. Но это не изменяет дела — даже сейчас, когда всплыло множество недочетов X11, кодовая база иксов безнадежно устарела и активно популяризируется вяленый — иксы все еще стандарт. Никто кроме X, не смог пока собрать воедино разработчиков драйверов и софта. Но все-таки это вопрос времени, иксы — это поезд без тормозов, который стремится в пропасть. Он еще будет ехать, но совсем скоро упадет.

Пока Wayland — еще довольно сырой проект, бывают проблемы с драйверами, программами, часть софта не может запуститься без XWayland, но скоро он встанет на рельсы вместо X11.

У него есть множество проблем с софтом, который плохо работает без XWayland, драйверами.

❯ Вывод и заключение

Линукс десктоп популяризируется. Постепенно процент использования Linux на домашних и рабочих компьютерах растет. Тем временем возрастает потребность в качественном графическом дисплейном сервере. Иксы постепенно отмирают, их место занимает Wayland. Но это не значит что сразу же стоит бросать иксы и переходить в срочном порядке на Wayland. Вяленый активно дорабатывается, но пока он не готов полноценно заменить иксы из-за многих проблем, которые мы рассмотрели в этой статье.

Если вы энтузиаст, желательно без Nvidia, вы уже можете использовать wayland. Особенно если вы гордый пользователь оконный менеджеров — проблем будет вряд ли много.

Итог всего сказанного — Wayland — это будущее. Но именно будущее, надо подождать лет 5 до того, как он станет полноценным дисплейным сервером.

Я надеюсь вам понравилась эта статья, ставьте свои реакции, оставляйте комментарии. Эта статья отобрала у меня много сил, и она прошла сквозь огонь, воду и медные трубы, а также дистрохоп!

Благодарю за прочтение

Источники и полезные ссылки

UPD: Благодарю пользователей bogolt, sshmakov, Mingun, datacompboy за то, что указали не неточности.

Источники информации, которые я использовал, и другие полезные ссылки

• Основной протокол X11
• X Window System / Wikipedia
• X Window System protocols and architecture / Wikipedia
• X.Org Server / Wikipedia
• Работа протокола X11 на нижнем уровне
• Документация X Window System
• X11 и все все все
• Графический стек Linux
• Документация Wayland
• Wayland на замену X11
• Wayland Protocol / Wikipedia)
• Архитектура Wayland
• Протокол Wayland

---

Возможно, захочется почитать и это:

• ➤ Эльфы и пингвины: что такое ELF и как он работает в Linux?
• ➤ Инь-Ян консолидация для процедурной генерации границ
• ➤ Как распутать уроборос роутинга в Linux
• ➤ Развертывание GitLab CE в контейнерах Docker за обратным прокси
• ➤ Sacred: ностальгия, прошедшая проверку временем

Автор: Алексеев Бронислав

Источник