Display Manager Policy

Полиси по упаковке Display Manager’ов

История

• Версия 1.0 (с бранча 5.1)
• Версия 2.0 (с бранча 10). Вынесена на обсуждение (переезд на стандарт Freedesktop; поддержка /etc/X11/wms-methods.d оставлена для DM, не соответствующих стандарту Freedesktop). metabug

поддержка выбора оконного менеджера (WM)/рабочей среды (DE)

DM, соответствующие стандарту Freedesktop

Ничего менять не требуется. Используется стандартный механизм, когда оконные менеджеры регистрируются в системе через .desktop-файлы в каталоге /usr/share/xsessions/.

Рекомендуется настроить DM так, что если существует файл $XDG_BASE_DIRS/xsessions/default.desktop, то он был установлен в меню DM как выбор по умолчанию.

DM, не соответствующие стандарту Freedesktop

DM, не соответствующий стандарту Freedesktop, не умеет читать .desktop-файлы в каталоге /usr/share/xsessions напрямую и вынужден пользоваться сторонними программами.

Обновление меню Display Manager’а

статическая конфигурация Display Manager

Если конфигурация Display Manager статическая, т.е. меню выбора WM/DE жестко прописано в его файлах конфигурации, то для обновления своего меню Display Manager должен предоставлять метод-файл /etc/X11/wms-methods.d/DMmethod. Метод-файл /etc/X11/wms-methods.d/DMmethod должен быть исполняемым.

Этот файл будет запускаться служебными скриптами каждый раз при установке, обновлении, удалении оконных менеджеров, а также при установке и обновлении самого Display Manager’а.

Служебный скрипт вызывается из файл-триггера пакета xinitrc автоматически.

динамическая конфигурация Display Manager

Если конфигурация Display Manager динамическая, т.е. пункты меню выбора WM/DE генерируются при запуске, метод-файл /etc/X11/wms-methods.d/DMmethod предоставлять не нужно.

Запуск оконного менеджера

Скрипты обновления меню для Display Manager'а может осуществлять парсинг файлов в /usr/share/xsessions/ и запуск оконного менеджера самостоятельно. Однако поскольку DM не соответствует стандарту Freedesktop, то он скорее всего не производит всех необходимых действий, требуемых стандартом, к примеру, не выставляет переменную окружения $XDG_CURRENT_DESKTOP. Поэтому для получения списка оконных менеджеров и запуска оконного менеджера рекомендуется пользоваться командой runwm.

Использование скриптов xinitrc и runwm для эмуляции стандарта Freedesktop

WMNAME для runwm

Согласно новому полиси по упаковке оконных менеджеров (Window Managers), последние декларируют себя в системе с помощью файлов /usr/share/xsessions/<name>.desktop.

Для каждого валидного и не скрытого (Hidden=true) desktop файла команда rundm --list выдаст уникальную не содержащую пробелов строку-название оконного менеджера WMNAME, которую можно отобразить в меню DE и при выборе пользователя передать в команду /etc/X11/Xsession.

Кроме WMNAME-ов, полученных из файлов /usr/share/xsessions/*.desktop, существует специальное WMNAME «default» для сессии по умолчанию.

Реализация для WMNAME определена в runwm. DM не должен работать с WMNAME иначе, чем через runwm.

Текущая реализация WMNAME (может изменяться без предупреждения): Берется первое слово из поля Name= desktop файла. Если оно содержит юникод или не уникально, то берется имя desktop файла без суффикса DNS и префикса .desktop. Иначе берется имя desktop файла. Пример:

1) Пусть axewm имеет 1 desktop файл axewm-session.desktop с 'Name=AxeWM Session'. Тогда WMNAME будет 'AxeWM'.

2) Пусть axewm имеет 2 desktop файла org.axewm.axewm-session.desktop с 'Name=AxeWM Session' и org.axewm.axewm-classic.desktop с 'Name=AxeWM Classic look&Feel'. Тогда WMNAME будут 'axewm-session' и 'axewm-classic'.

получения списка оконных менеджеров командой runwm

Для получения списка всех WMNAME для установленных в системе оконных менеджеров можно воспользоваться командой runwm --list. Эту команду можно использовать в файле /etc/X11/wms-methods.d/DMmethod для обновления конфигурации DM, или напрямую вызвать из DM для получения меню выбора.

Запуск WM скриптами xinitrc

Для запуска оконного менеджера Display Manager должен вызывать команду /etc/X11/Xsession с параметром WMNAME.

Интеграция с системными темами branding-*

фон по умолчанию

Рекомендуется выставлять в настройках Display Manager фон (wallpaper) по умолчанию как

/usr/share/design/current/backgrounds/xpm.png

Чтобы файл /usr/share/design/current/backgrounds/xpm.png существовал бы в файловой системе, надо добавить в зависимости

Requires: design-graphics

Вопросы, оставшиеся не урегулированными в версии 2.0

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

На момент версии 2.0 этот раздел является заглушкой.

pam

Планируется провести стандартизацию конфигурации pam для DM на уровне дистрибутива. Для этого собрать пакет с набором стандартных конфигураций pam для dm

dm-systemd
dm-systemd-greeter
dm-systemd-autologin
dm-nosystemd
dm-nosystemd-autologin

и перевести DM на его использование

Известные исключения: gdm (собственный модуль pam).

d-bus session

Сейчас по умолчанию управлением пользовательскими сессиями dbus занимается systemd. Если DM поддерживает pam_systemd (выполняет его корректную настройку через переменные окружения) и DM по возможности использует pam_systemd (-pam_systemd прописан в pam-файле DM) то поддержка пользовательскими сессиями dbus выполняется прозрачно для DM: pam_systemd прозрачно для DM связывается с logind с сообщением о новой сессии, systemd запускает при необходимости пользовательскую сессию, pam_systemd устанавливает нужный DBUS_SESSION_BUS_ADDRESS в переменных окружения.

Но для систем без systemd, для альтернатив systemd, на случай других неожиданностей было бы хорошо, чтобы DM проверял, нет ли уже сессии dbus, и если нет, то запускал бы сеанс <xsession-script> (только для сеансов xsessions, но не для сеансов wayland-sessions) в обертке

dbus-launch --exit-with-x11 <xsession-script>

Так как для этого требовалось бы добавлять функциональность во все DM, такое требование не слишком реалистично. Вместо этого предлагается внести эту функциональность в runwm. Если нет DBUS_SESSION_BUS_ADDRESS - попробовать по системной шине dbus узнать у logind, есть ли уже пользовательская сессия; запустить при необходимости.

Тогда корректный запуск при необходимости пользовательской сессиями dbus будет работать для всех DM, есть systemd или нет, при условии, если они используют /etc/X11/Xsession (который и запускает runwm).

см. подробнее

• https://www.freedesktop.org/wiki/Software/dbus/
• https://en.wikipedia.org/wiki/D-Bus
• https://dbus.freedesktop.org/doc/dbus-run-session.1.html
• https://dbus.freedesktop.org/doc/dbus-tutorial.html
• https://wiki.archlinux.org/title/D-Bus
• https://archlinux.org/news/d-bus-now-launches-user-buses/

Wayland

Не наработана системная обвязка для сессий Wayland.

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

Отличия классической сессии X от сессии Wayland.

Сводная таблица отличий.

	сессия X	сессия Wayland
сервер	требуется уже запущенный X сервер.	не требуется. Приложение запускает его самостоятельно
ограничения	X приложение.	нет. Что угодно. wayland compositor, fb app, console app, X app (должна сама запускать себе X)
запуск	нет требований. Сойдет fork+exec в текущем VT	аналог openvt -s -- <wsession script>
обертка D-BUS	dbus-launch --exit-with-x11 <xsession-script>	dbus-run-session <wsession script>

Следствие. сессии Wayland в принципе не могут использовать старую схему с запуском /etc/X11/Xsession как посредника. Хотя бы потому, что /etc/X11/Xsession должен быть запущен в сеансе X-cервера, вызывает утилиты X и без X-cервера вылетит с ошибкой. Также почти все, что делает /etc/X11/Xsession, бессмысленно вне X. Исключение -

/etc/X11/profile.d

но там у нас по сути нет ничего конкретно для X. Можно ввести какой-нибудь

/etc/user-session/profile.d

и перенести бывшее в /etc/X11/profile.d туда (ssh-agent.sh xdg-user-dirs.sh ...).

В итоге гипотетический помощник ALT для сессии Wayland должен вызвать /etc/user-session/profile.d и проконтролировать наличие пользовательской сессии D-BUS, обернув при необходимости вызов сессии Wayland в dbus-run-session. Это может быть не только скрипт, но и, к примеру, специально написанный для ALT pam модуль.