LINUX.ORG.RU

XDC: доклад о XMir и XWayland

 , ,


1

7

С 23 по 25 сентября проводилась очередная X Developers Conference, XDC2013. На ней было несколько докладов, полезных для широкой публики — и одним из них был доклад о XMir и XWayland. Автор — Chris Halse Rogers из компании Canonical, ранее занимавшийся сопровождением X-сервера в убунту и теперь привлечённый к разработке Mir и XMir. Здесь будет изложен краткий конспект этого доклада, взятый из PDF-слайдов и видеозаписи.

Прежде чем рассказывать про вложенные X-серверы внутри Mir и Wayland, следует рассказать о Mir — ведь на данный момент немногие подробно изучили его кодовую базу. Mir — это

  • Библиотека для создания сущностей, выполняющих задачи дисплейного сервера, композитора окон и оболочки рабочего стола
  • Библиотека для взаимодействия с созданными сущностями со стороны прикладного ПО
  • И примерно 90 тысяч LoC (осмысленных строк кода) на C++, включая заголовки и тесты. Тесты составляют половину общего числа LoC.

Дизайн Mir имеет отличия от дизайна Wayland

  • Это библиотечный API, а не межпроцессный протокол или механизм
  • Буферы цвета для окон создаются на стороне сервера (прим. — в трёхмерной графике есть множество других буферов, хрянящих не цветовые значения пикселей — потому и возникло понятие color buffers). Приложение получает буфер цвета на время рисования кадра и затем отдаёт его обратно в обмен на другой буфер, а владеет этими буферами сам Mir.

Цели, к которым идёт Mir, также отличаются. Wayland стремится быть полезным для всех, например, над ним активно работают разработчики Tizen и сообщество вокруг Rasberry Pi. В то же время Mir создан для достижения задач Canonical — но, как надеются его разработчики, может пригодиться и для решения более общих задач. Mir нацелен на улучшение работы Unity.

После этой части доклада Крису задали несколько вопросов, в том числе — о буферах цвета на стороне сервера. Wayland может сам владеть буферами и выдавать их приложениям по запросу, а может использовать буферы, переданные клиентом — в чём тогда различие между Wayland и Mir в управлении буферами цвета? Дело в том, что Rasberry Pi и все мобильные операционные системы стремятся передать владение буферами дисплейному серверу, потому что это позволяет забирать буферы у неактивных (suspended) приложений и тем самым получать серьёзную экономию памяти. Однако mesa оперирует только клиентскими буферами, и поэтому на десктопном компьютере не получится просто так получить буфер, которым владеет дисплейный сервер. Кроме того, разработчики тулкитов и приложений по сути могут сделать выбор так, как им захочется, ограничившись только одним из двух режимов работы wayland. (прим. — Крис вроде бы упоминал о способе обойти это с помощью «wayland shared buffer extension», но я не понял, о чём именно идёт речь).

Как XMir, так и XWayland запускают вложенный X-сервер, используя механизм расширений Xfree86. Через этот механизм обеспечивается вывод графики средствами Mir и Wayland, передача событий ввода X-серверу, drag&drop, управление окнами и остальные вещи, нужные для полноценной работы иксов. Когда Mir и Wayland встраиваются во вложенный X-сервер, они диктуют ему следующее:

  • Пожалуйста, не трогай реальный дисплей
  • Возьми буферы цвета
  • Дай нам реализовать RANDR самим
  • И несколько более сложным образом реализуется работа GLX

Есть различия в организации передачи изображения на реальный дисплей. Wayland для каждого окна использующего X приложения запускает отдельный вложенный X-сервер, и благодаря этому основанный на Wayland композитор захватывает буфер цвета окна (которым владеет X). Mir сам владеет всеми буферами цвета и к тому же всегда использует как минимум двойную буферизацию (т.е. для передачи изображения на дисплей обязательно придётся делать операцию swap buffers), поэтому он не может использовать аналогичный подход: ведь иксовые приложения, не использующие XGL, имеют один буфер и на каждом кадре просто рисуют нечто новое поверх старого. Поэтому Mir имеет два дополнительных буфера, эмулирующих двойную буферизацию — и на каждом кадре он отслеживает изменения, которые были сделаны в единственном буфере X-сервера, и копирует изменённые области в свой активный буфер; затем он делает swapBuffers.

Как показывают тесты Phoronix, подход Mir не приводит к существенному падению или увеличению производительности. Если рассматривать мелкие различия, то XMir работает чуть быстрее стандартного X-сервера на обычном многооконном десктопе в сочетании с композитным менеджером окна, и чуть медленнее — в полноэкранных играх. Замедление в полноэкранных играх, в свою очередь, можно исправить — ведь сам по себе XGL использует двойную буферизацию, как и Mir, и не нуждается в отслеживании и копировании изменённых областей. Единственным исключением из этих правил является KDE, работа которого чуть замедляется как на многооконном десктопе, так и в полноэкранных играх — дело в том, что оконный менеджер kwin сам по себе отслеживает изменённые области экрана и копирует только их; этот механизм используется в нём уже несколько лет. Это также объясняет, почему разработчики Kubuntu не хотят использовать XMir в Ubuntu 13.10 и 14.04.

Несмотря на различия в XWayland и XMir, часть кода может быть переиспользована в обоих проектах:

  • Для вложенного X-сервера с системой ускорения GLAMOR иксовый видеодрайвер может быть написан один раз и использоваться в обоих проектах, и такой драйвер уже написан в рамках Wayland.
  • Прокси для оконного менеджера (это не очень-то нужно для XWayland, который держит отдельный X-сервер для каждого окна, но полезно для XMir)
  • И, возможно, libxcwm — библиотеку, позволяющую запускать иксовые приложения на системах, где вообще нет X-сервера, таких как Mac OS X, Windows, Wayland и Mir. Подробнее...

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

После этого опять был перерыв на вопросы, и выяснилось, что подход XWayland (отдельный сервер на каждое окно) не только позволяет убрать прокси для оконного менеджера, но и делает управление окнами гораздо более простой задачей: поскольку каждое окно для Wayland представляет собой отдельный буфер, то композитор (он же оконный менеджер, в терминологии Wayland) может легко трансформировать окна по отдельности, и попытка сделать эффект волшебной лампы для сворачивающегося окна не приведёт к труднейшей задаче разделения окон, рисующих в один буфер одного X-сервера. С другой стороны, некоторые приложения начинают работать неправильно, если конфигурация предоставленного им X-сервера не соответствует реальной конфигурации мониторов, или если они не могут изменять конфигурацию мониторов, такую как разрешение экрана; в XMir такие приложения будут работать корректно.

>>> PDF-слайды доклада

★★★★

Проверено: Shaman007 ()
Последнее исправление: quiet_readonly (всего исправлений: 5)
Ответ на: комментарий от leg0las

Вяленый это протокол, а не его реализация. Нет вроде никакого libwayland. Есть weston - эталонная реализация части протокола, правда не планируемая к реальной жизни. Скоро kwin станет ещё одной реализацией. Потом глядишь ещё кто-нибудь.

zloelamo ★★★★
()
Ответ на: комментарий от zloelamo

Потом глядишь ещё кто-нибудь.

как кто? известно кто — gnome-shell :)

user_id_68054 ★★★★★
()
Ответ на: комментарий от zloelamo

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

no-dashi ★★★★★
()
Ответ на: комментарий от zloelamo

И протокола, и либы, и эталонной реализации композитора

kravich ★★★★
()
Ответ на: комментарий от zloelamo

А libwayland-server.so и libwayland-client.so — это что?

shimon ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.