Дальше слово глаголет Кристофер.
Помимо архитектурных различий между проектами, Mir и Wayland так же имеют разные цели. Некоторые запутались, чем же по настоящему является Wayland. Взяв X11 за точку отсчёта, попытаюсь объяснить разницу в проектах.
X11 и X.org.
Всем знаком дружище X сервер. Именно он трудится сейчас под капотом большинства линукс машин. Для понимания проблем нужно сказать из чего состоит X.
Протокол X11.
Многие слышали об протоколе X11. Этот нежный зверь определяет как разговаривать с X сервером. Как посылать и получать сообщения в двоичном формате. Что ожидать от сервера при данном сообщении.
Есть множество расширений протокола, позволяющие в будущем добавить новые вещи, не изменяя "ядра" X сервера.
Клиентские библиотеки X11.
Сейчас никто не разговаривает с сервером X, посылая сырые бинарные данные в сокет. Обычно все используют клиентские библиотеки - современный XCB или старый Xlib (так же известный как libX11.so.6). Именно они делают всю грязную работу под капотом, работая с бинарными данными, чтобы всё выглядело более или менее цивилизованно и вы могли просто сделать XOpenDisplay(NULL).
Тут чуток приврано, так как сейчас разработчики не используют XCB и Xlib, а используются такие тулкиты как GTK+ или Qt, которые уже используют XLib или XCB.
Сервер Xorg.
Xorg - это реализация сервера X, который используется в большинстве линукс машин. Хотя есть и другие реализации сервера Иксов, достаточно вспомнить Mac OS X.
Но для большинства линуксоидов базовым стеком Иксов является Xorg и клиентские библиотеки вокруг него.
Как насчёт Wayland и Mir?
Протокол Wayland.
Wayland протокол, как и протокол X, работает с бинарными данными, которые можно отправлять и получать через Wayland сокет. Тут есть чуток различия от X11 протокола. Wayland использует XML, который обрабатывается "сканером" и превращается в код С. Есть техническая возможность не использовать "сгенерированный-код-Wayland'ом", но это крайне не рекомендуется.
Ещё отличием от X11 протокола является, что в Wayland всё рассматривается как расширение. Вы обращаетесь со всеми интерфейсами в ядре протокола так же, как с вашим созданным расширением.
И вы создаёте много расширений! Например, ядро протокола Wayland не имеет механизма передачи массивов (buffer-passing mechanism) кроме как SHM. Поэтому есть расширение для drm буферов в Mesa.
Weston, эталонная реализация Wayland композитинга, так же имеет кучу расширений. К примеру, для таких вещей как compositor <-> desktop-shell interface или для XWayland.
Клиентская библиотека Wayland.
Он же libwayland. Выполняет работу для Wayland, как XCB и Xlib для Иксов, но в отличие от них может использоваться Wayland'ом для взаимодействия сервер -> клиент.
Libwayland реально хорошая библиотека IPC (Inter-Process Communication), но, как и XCB и Xlib, вы не должны использовать её напрямую. Желательно использовать тулкиты EGL+, Qt или GTK+.
Сервер Wayland?
Нет Wayland сервера, в том смысле, как Xorg сервер. Есть эталонная реализация протокола Wayland - Weston и задуман он, как стенд для обкатки работы протокола.
Среды рабочего окружения (Desktop environments) должны писать свои собственные сервера Wayland, используя протокол и клиентские библиотеки.
Протокол Mir?
Мы как будто используем определённый IPC протокол, но это не так. Мы не намерены повторно реализовывать IPC протокол в библиотеках Mir. Кстати, наш формат для IPC это Google Protobuf.
Клиентские библиотеки Mir.
Какой инструментарий использовать разработчикам? Кто-то уже назвал его - mir_toolkit! Опять таки лучше не использовать напрямую низкоуровневые библиотеки, даже Mir'а. Используйте GTK, Qt или EGL + GL/GLES/OpenVG.
Сервер Mir?
Там где Wayland крутится около библиотеки IPC, Mir создаёт библиотеку, которая выполняет всю тяжёлую работу дисплейный-сервер-композитинг-и-ещё-штуки. Так что это ближе к Xorg, чем к Wayland.
Если быть более конкретным, то Mir движется в сторону создания библиотеки, которая позволит Unity делать интересные штуки и быть ей дисплейный-сервер-композитинг-в-одном-лице.
Мы не стремимся решить проблемы всех, но хотим реализовать свои задумки. Но наши запросы не являются слишком специфичными и, возможно, Mir будет полезен многим.
В какой-то степени именно из-за этого разработчики Gnome и KDE не в восторге от Mir. Они уже проявили заинтересованность в Wayland и создание нашего дисплейный-сервер-композитор-ещё-штучки для них малоценно. Но это сейчас.
Возможно в будущем, мы докажем свою состоятельность и разработчики Gnome и KDE обратят своё внимание на нас и их проекты будут работать с Mir, но до этого ещё слишком далеко.
А тем временем, Canonical создала отдельную страницу для проекта Mir - wiki.ubuntu.com/Mir.
Вы по-прежнему не любите новости про Мир? Писаете кипятком от сетевой прозрачности Иксов? Она уже не работает в нём на 100%.
Читаем:
Французский программист Julien Danjou, разработчик оконного менеджера Awesome, и его мысли вслух о протоколе X.
Jasper St. Pierre, разработчик GNOME Shell в статье Графический стек Linux.
Связанные общей мыслью:
Зачем Canonical создала Мир? 5 причин от Кристофера Роджерса.
Canonical представила дисплейный сервер Mir.
Графические оболочки Linux. Часть 2.
Немає коментарів:
Дописати коментар