Всех приветствую, читатели Хабра! Решил попробовать себя в роли знатока-писателя и освятить для вас такую тему, как “Компоненты среды рабочего стола”, чтобы больше людей, хотя бы в основе, понимали, что там происходит в системе такого, благодаря чему мы можем, не тыкаясь в консоли, с ней взаимодействовать.
Ответы на какие вопросы мы получим:
Что такое окружение рабочего стола?
Какие окружения рабочего стола бывают?
Что из себя представляет каждый компонент окружения?
Как и в какой последовательности происходит запуск компонентов графической сессии? (на примере kde-plasma)
Полезные материалы
https://blogs.gnome.org/tbernard/2023/07/26/rethinking-window-management/ (общая информация про оконные менеджеры)
https://askubuntu.com/questions/1229060/what-exactly-is-the-gnome-shell-and-how-does-it-differ-from-a-desktop-environme (что такое gnome-shell)
https://mail.gnome.org/archives/commits-list/2011-March/msg03083.html (коммит, разделяющий исполняемый файл mutter и библиотеку libmutter)
https://www.xfce.org/projects (проекты окружения xfce)
https://www.reddit.com/r/linuxquestions/comments/12dgfea/are_distros_just_a_desktop_environments/ (разница между дистрибутивом и окружением рабочего стола)
https://wiki.archlinux.org/title/window_manager (оконный менеджер это)
https://jichu4n.com/posts/how-x-window-managers-work-and-how-to-write-one-part-iii/ (реализация взаимодействия клиент => оконный менеджер => оконная система X)
https://github.com/cdown/dwm/blob/master/dwm.c#L1782 (исходный код оконного менеджера dwm)
https://askubuntu.com/questions/356823/how-does-display-manager-know-which-wm-de-to-run (откуда dm понимает, какое окружение запустить)
https://github.com/KDE/plasma-workspace/tree/master/startkde (исходный код стартап модулей окружения kde-plasma)
Что такое окружение рабочего стола?
Окружение рабочего стола = среда рабочего стола = рабочий стол = Desktop Environment - это набор логически связанных приложений, который формирует полноценно работающий интерфейс для взаимодействия пользователя с системой. Репозитории некоторых дистрибутивов предлагают пакеты, с помощью которых, по мимо обязательного минимума, на систему ставятся приложения, которые хорошо интегрированы с определенным окружением. На примере Ubuntu, глобальный пакет окружения kde-plasma "kde-plasma-desktop", предоставляет "kde-baseapps". Такими приложениями могут быть: файловый менеджер, текстовый редактор, редактор изображений и другие утилиты, обеспечивающие полноценный пользовательский опыт. Одной из причин, почему дополнительные приложения предлагаются к установке, является стек технологий, на котором они разработаны - зачастую этот стек совпадает с тем, на котором написана графическая часть модулей конкретного DE, что способствует единому визуальному стилю. Вид некоторых виджетов GTK приложений сильно отличается от тех, которые предлагает QT, из-за этого желательно, чтобы системные приложения внутри определенного DE были написаны на том же графическом туллките, что и сами компоненты окружения.
Какие окружения рабочего стола бывают?
На сегодняшний день для GNU Linux существует множество окружений рабочего стола, таких как: GNOME, KDE Plasma, Xfce, Cinnamon, Deepin, Pantheon, LXDE, Mate, Unity. Каждое из них имеет свои особенности дизайна и функциональности. Допустим, для GNOME не предусмотрена возможность отключения композитинга - он встроен в библиотеку mutter, которую использует gnome-shell для менеджмента окон и композитинга. В то время, как в оконных менеджерах для Xfce (xfwm4) и KDE Plasma (Kwin), композитор можно отключить:
Добавить строку "exec xfwm4 --compositor=off" в файл "~/.xinitrc".
Выполнить команду "qdbus org.kde.KWin /Compositor suspend" в терминале.
Такая возможность позволит вам использовать сторонний софт, такой как picom для наложения графических эффектов на окна. Также, для примера, в GNOME отрисовка элементов интерфейса, на ряду с менеджментом окон и композитингом, выполняется внутри программы gnome-shell. Похожее архитектурное решение реализовано в отечественном AstraLinux - внутри этой ОС, согласно открытой информации про рабочий стол FLY “fly-wm — менеджер окон, рабочий стол, классическое меню "Пуск", панель задач, переключатель рабочих столов, блокировщик экрана. Не зависит от стороннего ПО;”.
В kde-plasma немного обратная ситуация: kwin является отдельным процессом, отвечающим только за композитинг и управление окнами. Если терминировать данный процесс, то рабочий стол все еще будет отображаться - будет потеряна возможность полноценно работать с окнами, т.к исчезнут декорации, с помощью которых окно можно перемещать, ресайзить, закрывать. Техническая пометка "слова про декорации являются правдивыми, если приложение не накладывает их за счет туллкита, на котором оно разработано (CSD - Client Side Decorations)". Также пропадет функционал наложения одного окна поверх другого - за все перечисленные манипуляции отвечает kwin. Если же убить процесс plasmashell, то пропадут все элементы интерфейса рабочего стола - все, что будет видеть пользователь - черный экран.
Что из себя представляет каждый компонент окружения?
Дисплей менеджер - приложение, которое запускается на этапе бута системы и выводит графический интерфейс для:
Выбора пользователя: для авторизации в системе может быть доступно несколько пользователей. Дисплей менеджер позволяет либо выбрать пользователя из списка, либо войти по логину/паролю. Выбор пользователей формируется исходя из содержимого файла "/etc/passwd", который хранит записи обо всех зарегестрированных пользователях, имеющих доступ к системе.
Авторизации пользователя: после ввода данных, по которым требуется идентифицировать пользователя, DM передает их аутентификационному сервису для проверки на соответствие. Примером такого сервиса может быть PAM (Pluggable authentication modules). Так, как реализовывать полноценную аутентификационную систему для каждого отдельного приложения тяжело и долго, необходимо было добавить программную прослойку, которую можно было бы независимо использовать. Такой прослойкой как раз и является PAM - состоит из набора библиотек и конфигурационных файлов, работая с которыми, приложение может аутентифицировать пользователя по запрашиваемым данным.
Выбора окружения рабочего стола: списки возможных для запуска окружений хранятся в "/usr/share/xsessions" (Xorg), "/usr/share/wayland-sessions" (Wayland). В этих директориях лежат .desktop файлы, в которых указано, какое приложение необходимо запустить для того, чтобы начать инициализацию окружения.
Также, дисплей менеджеры можно конфигурировать. Файлы конфигурации, в зависимости от DM, могут находиться в разны директориях - обычно пути следующие: "/etc/<dm>/" "/etc/X11/<dm>/" "/etc/<dm>.conf.d/" "/usr/share/<dm>/". В общем, функционал менеджеров может варьироваться, но его основной задачей является пустить выбранного пользователя в систему с тем графическим окружением и с таким функционалом, который требуется.Примеры DM:
LightDM - легкий дисплей менеджер с низким потреблением памяти и ресурсов. Предоставляет ту же функциональность, что и GDM, но отличается от него более простой кодовой базой и отсутствием зависимости от библиотек GNOME
SDDM - рекомендован для окружений (Plasma и LXQt), заменил KDM
FLY-DM - стандартный для Астровского окружения FLY
Оконный менеджер - программный компонент, отвечающий за управление окнами, размещенными на экране. Функционал оконного менеджера:
Декорирование окон (SSD - Server Side Decorations): оконный менеджер, для того, чтобы дать пользователю возможность управлять окном, должен наложить на него декорации, благодаря которым окно можно будет ресайзить, скрывать, закрывать и сворачивать в трей - декорации могут быть наложены на стороне туллкита, на котором приложение разработано (CSD), в таком случает, управление окном контролирует определенная библиотека - GTK/QT. Также, некоторые оконные менеджеры прорисовывают рамку по контуру окна - это тоже можно отнести к декорациям.
Отслеживание событий ввода: оконный менеджер отслеживает события ввода с различных устройств, благодаря чему становится возможным корректно переносить фокус с одного окна на другое, распознавать комбинации клавиш или жесты с трекпада.
Применение различных свойств к окнам (еще их называют атомами): оконный менеджер, обычно, для коммуникации между клиентами, может применять набор свойств к окнам - благодаря чему, стороннее приложение, допустим композитор, может считать свойство и как-либо на его наличие отреагировать. Например, при настройке "тень только для активного окна", композитор может проверять свойство _NET_ACTIVE_WINDOW и, если оно выставлено, накладывать на окно тень. Посмотреть список свойств, примененных к окну, можно через команду xprop.
Группировка окон и управление порядком наложения: оконные менеджеры реализовывают различные способы группировки окон, будь-то комбинации клавиш, либо перетягивание окна в угол или край экрана. Также, контролируется порядок наложения окон - окно в фокусе всегда будет выше остальных в очереди, только если для других окон не установлен особый приоритет.
Взаимодействие между клиентскими окнами и менеджером реализовано за счет ивентов - когда приложение запрашивает отображение окна (w), оконный менеджер получает сигнал MapRequest, после чего генерирует декоративную оправу, которая на системном уровне также является окном (f). Далее происходит reparenting и созданная менеджером оправа становится родителем для клиента. После чего, оконный менеджер вызывает метод XMapWindow для декораций (f) и клиента (w), Xorg обрабатывает запрос и выводит окна на экран. Таким образом, оконный менеджер должен контролировать события с двух сторон:
Со стороны клиента:
(Клиент) Эй, Xorg, отобрази окно.
(Оконный менеджер) Так, стой, сначала дай мне его обработать.
(Оконный менеджер) Все, готово! Xorg, отобрази 2 окна: клиента и мое, которое - декорации.
(Xorg) Понял, работаем.
Со стороны пользователя:
(Декорации: кнопка скрыть) Эй, оконный менеджер, на меня тут нажали.
(Оконный менеджер) Ага, понял! Xorg, скрой декорации и окно клиента, сделай его дочерним для root, очисти свою память от моих декораций.
(Xorg) Так точно, выполняю.
Взаимодействие клиента с менеджером окон Типы оконных менеджеров:
floating/stacking - обычный, узнаваемый пользователями винды тип оконных менеджеров: окна можно перемещать, присутствуют декорации, окна могут быть расположены одно поверх другого.
tiling - окна автоматически выстраиваются в сетку, отсутствуют декорации ⇒ нет возможности с помощью мыши управлять трансформацией окон, легковесны, не тратят иного ресурсов системы, присутствует широкий спектр кастомизации.
dynamic - совмещается функционал 2 предыдущих типов: окна можно перемещать, менять их размер (не используя декорации) + они могут быть выстроены по определенной сетке.
scrolling - не очень известный тип оконных менеджеров, обычно его приобщают к tiling. В таких менеджерах для окон предусмотрен 1 layout: окна выстраиваются в ряд, который можно скроллить по мере расширения.
Композитный менеджер - приложение, которое участвует в процессе наложения различных эффектов и анимаций на окна. Вкратце, композитный менеджер работает следующим образом:
Создает overlay окно, которое является контекстом для отрисовки графики. Overlay пропускает через себя события ввода, поэтому все окна, за которыми наблюдает Xorg, без проблем регистрируют события с мыши.
Перенаправляет изображения каждого окна в offscreen-buffer, что делает окна фактически невидимыми - они всё также зарегистрированы Xorg сервером, имеют определенные параметры и свойства, реагируют на события ввода.
Использует графическое API для наложения эффектов на окна и их рендера внутри контекста. Для того, чтобы получить актуальное содержимое окна, композитор регулярно обращается к offscreen-buffer и обновляет его текстуру.
Выбор и использование API, через который будет реализован алгоритм композитинга, определяет бэкенд. Бэкенд - это кодовая база, имплементирующая рендер всего, что мы видим на экране. Бэкенды бывают разные: egl, vulkan, xrender, glx и т.д. (в этой статье затронем xrender и glx).
Xrender является резервным вариантом и используется либо со слабым видеускорением, которое не сможет нормально тянуть рендер интерфейса или содержит в драйверах устаревшую версию OpenGL, либо с драйверами software rendering, такими как llvmpipe или softpipe.
Графическая отрисовка в xrender базируется на библиотеках из окружения X: xcomposite, xcb, xlib etc. Сейчас xrender потихоньку выпиливается из композиторов. Из того же kwin его убрали из-за отсутствия развития технологий и поддержки, в picom он все еще используется. Какие-то серьезные проблемы стараются допиливать, но основной приоритет стоит на glx.
GLX - бэкенд, который реализовывает все графические эффекты и рендер самих окон через вызовы расширения GLX и OpenGL. По приоритету запуска он выше xrender (обычно, в композиторах реализована проверка графических параметров системы и если по каким-то причинам glx не может быть использован, композитор стартует c xrender).
Многие композиторы, из соображений различных оптимизаций и совместимости, являются частью оконных менеджеров. Из тех немногих хороших композиторов, которые можно использовать в связке с чистым оконным менеджером, сейчас можно выделить, наверное, только picom и несколько его форков. Раньше можно было еще как-то надеяться на compiz-reloaded, но он, последнее время, слабо развивается и, в основном, для проекта выходят баг фиксы, нежели нововведения.
Пару слов на счет picom - это форк старого композитора compton. У picom есть постоянный мейнтейнер и широкая группа контрибьютеров. Композитор шустро развивается и регулярно дорабатывается. Из форков, самым интересным сегодня является версия разработчика Ft-Labs: в форке реализованы анимации + он периодически синхронизируется с мейнстримом и дорабатывается. Сейчас анимации в процессе разработки и для оригинального проекта, но, пока все это на стадии майлстоуна для следующей версии проекта.
Шелл - часть программного окружения, которая контролирует и создает такие вещи, как фон рабочего стола, панель задач, иконки рабочего стола, контекстные меню и, возможно, еще какие-нибудь интерактивные элементы на рабочем столе (зависит от реализации). Шелл, в зависимости от архитектуры de, может включать в себя такие вещи, как менеджер окон и композитор (gnome-shell), может быть частью менеджера окон (fly-wm), либо может быть абсолютно сепаратным процессом со своим спектром задач (plasmashell). Закроем gnome-shell, сломается весь рабочий стол, закроем fly-wm, сломается вся сессия, закроем plasmashell, сломается только функционал, за который отвечает процесс - исчезнет фон рабочего стола, иконки приложений и панель задач. Сессия все еще будет запущена, окна останутся интерактивными, с корректными декорациями и наложенными эффектами.
Какая последовательность запуска компонентов графической сессии?
Последовательность запуска компонентов графической сессии kde-plasma: Все начинается с того, что запускается тот самый процесс инициализации системы в пространстве пользователя с pid = 1. Сейчас этот процесс называется systemd, но, все равно, во многих системах вы будете видеть в списке процессов экземпляр с названием init, который является символьной ссылкой на исполняемый файл systemd.
init Сейчас, для понимания того, как стартует графическое окружение, вам необходимо знать только то, что этот процесс запускает пулл программ на этапе инициализации системы, в том числе, он запускает дисплей менеджер, точнее, он запускает сервис display-manager.service, который, в свою очередь, запускает исполняемый файл дисплей менеджера. Основные пути, по которым лежат сервисы: "/etc/systemd/system" "/run/systemd/system" "/lib/systemd/system". Для окружения kde-plasma, стандартным dm является sddm. При инсталляции пакета, сервис данного дисплей менеджера попадет в директорию /lib/systemd/system. На самом деле "/etc/systemd/system/display-manager.service" является всего лишь символьной ссылкой на сервис текущего основного dm. Соответственно, systemd, при запуске дисплей менеджера, будет работать именно с сервисом, который лежит в /lib/systemd/system - в эту директорию записываются сервисы, которые предоставляются пакетами после установки - в нашем случае, systemd обработает /lib/systemd/system/sddm.service, который, если заглянуть внутрь, запустит /usr/bin/sddm.
display-manager.service 
sddm.service После запуска, для того, чтобы вывести пользователю интерфейс, sddm запускает Xorg сервер, грубо говоря - приложение, которое реализовывает взаимодействие с клиентами по протоколу X. На пример, для того, чтобы отобразить окно, клиентское приложение должно вызывает метод XMapWindow, Xorg сервер принимает запрос, обращается к графическому оборудованию и выводит изображение на экран. Это довольно примитивное объяснение того, реализована оконная система X - общее представление ее компонентов выглядит довольно комплексно и заслуживает подробного разбора в отдельной статье.
Структура X Window System После того, как пользователь успешно себя идентифицировал и выбрал окружение рабочего стола plasma, sddm, в зависимости от типа сессии X11/Wayland, запустит либо startplasma-x11, либо startplasma-wayland. С этого процесса начинается инициализация пользовательской сессии: выставляются глобальные переменные окружения, запускается набор ключевых для сессии сервисов через dbus и приложений из директорий автостарта. В случае, если systemd не запущен, либо отсутствуют необходимые таргеты (юниты, которые позволяют запускать сервисы группами), startplasma-x11 запускает процесс plasma-session, который является резервным и запускает приложения без привязки к менеджеру systemd.
startplasma.cpp 
Дерево запуска процессов Далее, после того, как plasma определилась с тем, каким способом формировать костяк нашей сессии, происходит непосредственный запуск приложений и сервисов. Для приложений из директорий автостарта учитывается приоритет. В .desktop файлах можно указать фазу, на которой оно будет запущено. Для этого в kde-plasma существует переменная X-KDE-autostart-phase. Индексация идет с 0 до 2. Приложение с самым последним индексом будет запущено позже всего. Указывать приоритет запуска может быть полезно в случае, когда между приложениями происходит коммуникация (IPC). На этом этапе старта системы запускаются такие приложения как оконный менеджер (kwin), оболочка (plasmashell), менеджер сессии (ksmserver), сервис уведомлений, демон (kded5) и так далее: список всех запущенных процессов с демонстрацией вложенности вы можете посмотреть с помощью команды "ps -axjf". После того, как все готово, вы наконец-то входите в сессию, видите рабочий стол и все его графические компоненты.
Фуууух, на этом, наверное, можно закончить общее ознакомление с тем, из чего состоит "среднее по России" окружение рабочего стола. Надеюсь, вы почерпнули для себя что-то новое и сможете чуть более уверенно пользоваться системой. Если я где-то в технических разъяснениях допустил ошибку, не стесняйтесь меня править. Услышимся в следующих статьях!
