Что придет на замену X Window System?

Одним из знаменательных Linux событий прошлого года стал выход 25-й Федоры с графическим окружением Gnome 3.22 на базе дисплейного сервера Wayland, который призван заменить X Window System. Но зачем вообще после стольких лет возникла такая необходимость?

В последнее время экипаж МКС пересел с Windows на Linux.
— Хьюстон, у нас проблемы. Нас сносит на Юпитер.
— Вы что, опять возились с xorg.conf?
— Да. Хьюстон, за три последних дня у нас почему-то выросли бороды.

Далее, речь о том, почему Linux необходима новая графическая среда, хотя бы в 2017 г, а отдельным постом я расскажу про Wayland и Mir.

Номенклатура X

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

• X Window System — Система оконного интерфейса X, создана в недрах MIT летом 1984 г. В иксах определен протокол, но сводить все к протоколу не оправданно, хотя чисто технически так оно и есть. Дело в том, что протокол сам по себе окошки не рисует, а все то, что сегодня управляет графикой на Unix / Linux системах — это больше чем протокол.
• X11 — Одиннадцатая версия X, которая была выпущена в 1987 г. и в различных ипостасях благополучно дожила до наших дней. В частности, от нее отпочковался XFree86, из которого затем появился по настоящему свободный X.Org Server, с лицензией GPL, как положено. В данном тексте X11 будет обозначать протокол, в отличие от X, под которым подразумевается вся его совокупность компонент, ПО в целом.
• X.Org Server — Свободная каноническая реализация серверной части иксов, то что на сегодняшний день является X-сервером для Linux.

  (5:50)$ eix -c xorg-server
  [I] x11-base/xorg-server (1.18.4@19.09.2016): X.Org X servers

• Xlib — Каноническая реализация клиентской части X, хранилище огромного количества утилит для управления оконным интерфейсом. Это довольно громоздкая библиотека, состоящая из > 400 файлов, содержащих свыше 150 тыс. строк мутноватого кода, в основном 1980-х гг. Вызовы Xlib бывают синхронные, а иногда — асинхронные, что ставит в тупик неискушенных разработчиков, так как непонятно следует-ли затем очищать буфер обмена.
• XCB — X protocol C-language Binding, клиентская библиотека X написанная на C. XCB имеет массу преимуществ перед Xlib: прямой доступ к X11, проще и легче, потребление памяти ниже, поддерживает многопоточность и расширения, не блокирует приложение. Предполагалось, что XCB заменит Xlib, но инерция накопленной кодобазы тормозит это благое начинание.

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

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

Еще немного тезауруса о технологиях, благодаря которым современное графическое окружение Linux держит свою марку.

• Cairo — Библиотека, предназначенная для вывода 2D векторной графики на любые устройства. Приложения, например FireFox, могут использовать ее напрямую, или с помощью тулкитов, таких как GTK+.
• XRender — Расширение протокола X для реализации алгоритма композиции Портера-Даффа в X-сервере, который применяют для отрисовки примитивов с антиалиасингом.
• Pixman — Библиотека для выполнения операций по манипулированию областями пикселей, которая применяется для низкоуровневой отрисовки графики во многих открытых проектах, в том числе в X.Org, Cairo и Firefox.

• Mesa — Реализация OpenGL, OpenCL и Vulkan API для Linux и Unix, включающая в себя как программные библиотеки, так и набор драйверов видеокарт. Mesa имеет и умеет много чего, но в основном это открытая реализация OpenGL API, для трансляции которого в исполнительные команды используются программные:

  • swrast — устаревший и слишком тормознутый,
  • softpipe — средне,

  • lvmpipe — может и быстрый,

    и аппаратные бэкенды с помощью открытых драйверов intel, radeon и noveau.

  • r600g
  • r300g
  • nvc0

• Gallium — API для создания в целом аппаратно-независимых графических драйверов, используя для этого напрямую объекты, в которых инкапсулирован набор ключевых функций видеокарты. Содержит программный растерайзер OpenSWR, в отличие от предыдущих трех, он на стероидах и значительно быстрее lvmpipe.
• DRI — Direct Rendering Infrastructure — интерфейс и свободная его реализация в X Window System, позволяющие пользовательским процессам оперативно и безопасно получать доступ к видеокарте без необходимости задействовать X server. Основное предназначение DRI — предоставить аппаратное ускорение для Mesa. С недавних пор получил распространение новый стандарт DRI3, в котором X-клиенты самостоятельно обращаются к буферу видеокарты, вместо того, чтобы полагаться в этом на X сервер. Также отпала необходимость взаимодействия с подсистемой GEM (Graphics Execution Manager), которая признана устаревшей и имеет проблемы с безопасностью.
• AIGLX — Accelerated Indirect GLX, открытый проект, разрабатываемый сообществами Red Hat и Fedora Linux для поддержки совместимого с X.Org и DRI драйверами прямого GLX рендеринга. Это позволяет удаленному X-клиенту получать полностью аппаратно ускоренный рендеринг через протокол GLX; эта разработка необходима для OpenGL менеджеров прозрачности (таких как Compiz и Beryl) для работы с аппаратным ускорением.
• GEM/TTM — Модули ядра управления видеопамятью, из них первый для интегрированных графических карт, а второй — универсальный. GEM более новый и имеет лучшую производительность, однако и проблемы с безопасностью, которые разрешены в DRI3.

Всемогущий X

Программирование на X — это как чтение французских философов, после этого начинаешь задаваться вопросом: что я на самом деле знаю?
Томас Турман.

Кому на сегодняшний день позарез нужны иксы? В Android телефонах, телевизорах, планшетах X Windows System не используется, Хромбуки тоже как-то без них обходятся. Значит речь идет только о Linux / Unix рабочих станциях, в основном по той причине, что тулкиты GTK+ и QT, долгое время не могли обходиться без X.

В этом году X11 исполняется 30 лет. Секрет живучести X Window System в следующих принципах, сформулированных в 1996 г.

• Добавляй новую функциональность только в том случае, если без нее нельзя завершить уже существующее приложение.
• Решить, чем система не является, столь же важно, сколь решить, чем она является. Не пытайся удовлетворить все мыслимые потребности; вместо этого сделай систему расширяемой, чтобы новые потребности могли быть удовлетворены совместимым образом.
• Хуже обобщения одного примера может быть только обобщение вообще без примеров.
• Если проблема не понята до конца, возможно, лучше не решать ее вовсе.
• Если ты можешь добиться 90 процентов нужного эффекта, затратив всего 10 процентов сил, используй более простое решение.
• Изолируй сложные места как можно тщательнее.
• Обеспечивай механизм, а не политику. В частности, клиент должен определять политику пользовательского интерфейса.

Сочетание этих принципов позволило X11 быть невероятно гибким и масштабируемым решением для столь разных графических оболочек Unix в течении долгого времени. Особенное место занимает последний — обеспечить механизм, для того, чтобы X-клиент смог реализовать все свои затеи. Обратной стороной такой всеядности и живучести стало невероятное нагромождение устаревших стандартов, методов и технологий. Можно вспомнить сервер шрифтов вместе с XLFD или движок для отрисовки многоугольников и разноцветных полос.

Изначально X был государством в государстве и подменял собой множество функции ядра ОС:

• Modesetting
• 2D/3D ускорение
• Ускорение рендеринга видео
• Напрямую взаимодействует с GPU как root
• Управление памятью
• Привязка клавиатуры
• Устройства ввода
• Clipping

Из все этого списка, пункт первый являлся корнем всех добродетелей и зол, так как ни одна другая графическая система с открытым ПО не сумела решить эту задачу для всех платформ. Сейчас почти весь этот список в ядре, в том числе и modesetting, но позади долгий этап планомерного принуждения иксов к миру, то есть к разумному сосуществованию в окружении GNU/Linux.

X.Org и принуждение к миру

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

Затем внезапно устройства стали более быстрыми, мощными и сложными: несколько GPU, мониторов, разношерстые устройства ввода. Рендеринг также стал более сложным, появился OpenGL. X Window system стала обрастать расширениями, однако ядро протокола по политическим мотивам осталось нетронутым. На все недостатки находились обходные пути, и пошло и поехало… BIOS видеокарты, порты I/O, подсистема питания. И всем этим хозяйством X управлял из рук вон плохо, превратившись в ОС внутри ОС, причем достаточно паршивую ОС.

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

• Монолитный X разбили на несколько частей. Ну как несколько… 345 git модулей. Правда большая часть из этого в итоге оказалось не нужна.
• Затем пошла зачистка кода. Xserver 1.0.2: 879,403 строк кода, в 2013-м уже осталось 562,678. По оценке же Кита Пакарда выпилено аж 500 тыс. строк кода. Кто-нибудь из-за этого огорчился?
• Modesetting, управление памятью, поддержка устройств ввода, все ушло в кернел. Привязка клавиатуры, правда, все еще в иксах из-за своей невероятной сложности. Кто-то советовался с Джа, когда придумал это.

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

Точно так-же при обновлении содержимого экрана иксы не при делах. Приложение рисует что-то, данные через DRI попадают в область off-screen buffer памяти видеокарты. Приложение затем оповещает сервер о том, что буфер изменился, а X-сервер передает это сообщение WM, и тот через DRI рисует новую картинку.

Помимо этого остаются архитектурные ограничения, которые невозможно обойти, не ломая совместимость с древними Motif приложениями. Да-да, не смейтесь, несколько лет назад я сам с такими работал и даже сопровождал. К таким ограничениям относится ужасный IPC, полный захват устройств ввода, в результате чего скринсейвер не запускается при открытом меню, кнопки управления звуком блокированы скринсейвером и pop-up сообщениями. Дерганое изображение, неравномерная отрисовка, артефакты обновления, это все никуда не денется, как бы ни старались иксовые программисты, а они стараются все меньше и все больше перестраиваются на Wayland. Ах, да и еще имманентное состояние гонки.

Состояние гонки

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

1. Пользователь щелкает левой кнопкой мыши.
2. Сервер посылает событие ButtonPressприложению.
3. Приложение вызывает MapWindow для показа меню.
4. Сервер открывает окно с меню приложения.
5. Сервер посылает приложению событие Expose.
6. Приложение рисует картинку с меню.

На диаграмме видно, что произойдет, если пользователь отпустит левую клавишу раньше события 4. Если натренированный на действие пользователь заранее переместился на место предполагаемого пункта меню до того момента, пока там возникло новое окно, то тогда произойдет состояние гонки mouse ahead. Событие ButtonRelease придется на еще не занятую новым окном область экрана. Это вполне вероятно на удаленных X-сессиях по медленной сети.

Server                           Client
+-------+                        +-----+
Left Button Down
               |
               +----------------> Map menu
Left Button Up                     |
      |                            |
      +-------------------------------> No menu operations visible
                                   |
Map Window <-----------------------+

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

Промежуточные итоги

Тридцать лет тому назад Unix сервера и рабочие станции благодаря X Window System получили унифицированную графическую среду, что было довольно прогрессивным и важным шагом для ИТ индустрии. Кто сейчас восхищается давнишними конкурентами — Sun NeWS, Amiga, или ругает их? Тогда иксы обошли их во за счет кросс-платформенности, возможности запускать приложения поверх TCP/IP, что было сравнимо с http доступом для веб приложений сегодня.

Вместе с тем создатели иксов явно где-то перемудрили. Принцип обеспечения механизмов, но не политики впоследствии сыграл злую шутку с экосистемой X и она обросла всем тем, чем обросла. За десятилетия ландшафт компьютеров, устройств и ПО радикально изменился, а X Window System проникла на лаптопы и даже смартфоны Нокиа. До сих пор разработчикам вполне удавалось держать проект на плаву, благодаря миграции значительной части функционала в ядро. Этот ресурс уже тоже исчерпан, и в силу вступил неумолимый закон убывающей отдачи. Наконец-то есть возможность начать с чистого листа, догнать и перегнать тренд, вместо того, чтобы плестись за ним. Я также связываю с этим давно обещанный прорыв Linux на десктопы. Закономерность или случайность, но Linux имеет полное доминирование на устройствах, где нет X сервера.

Как должна происходить замена X Window System на Wayland или Mir? Нельзя так просто дать готовый рецепт, но можно сказать как не должно поступать. Чтобы без хейтеров и фанбоев, без шоковой терапии и подозрительных двадцати раундов голосования с итоговым перевесом в один голос. Без раскола сообщества. Словом, без всего того, что имело место при замене систем инициализации на systemd. А вы как считаете?

Ссылки по теме

1. Kernel Recipes 2014 The Linux graphics stack and Nouveau driver
2. X and the future of Linux graphics
3. Linux.conf.au 2013 The real story behind Wayland and X
4. The X Windowing System
5. Explaining X11 for the rest of us
6. Thoughts about DRI.Next

Автор: temujin

Источник