[devel] RFC: wayland session wrapper script

Igor Vlasenko vlasenko на imath.kiev.ua
Чт Дек 2 21:35:23 MSK 2021


Уважаемые коллеги!

Как показал #40910
https://bugzilla.altlinux.org/40910
нам срочно нужен wayland session wrapper script.

Выношу на обсуждение, что туда хотелось бы запихнуть.

I/Часть один. Что хотелось бы иметь в таком скрипте.

1) Самый минимум такого скрипта - это

№!/bin/bash -login
# wayland session wrapper script.
exec "$@"

Этого минимума хватит, чтобы втянуть /etc/profile and /etc/profile.d
и закрыть #40910.
Но этого недостаточно по сравнению с нашей инфраструктурой над /etc/X11/Xsession.

Поэтому вот что еще хочу туда добавить:

2) обертки
SELINUX_WRAPPER=...
DBUS_WRAPPER=
# we already have user's dbus session or we are about to run it
[ -n "$DBUS_SESSION_BUS_ADDRESS" -o "$1" = "dbus-run-session" ] || DBUS_WRAPPER=dbus-run-session

exec $SELINUX_WRAPPER $DBUS_WRAPPER "$@"

DBUS_WRAPPER - для запуска на системах без systemd.

3) XDG_SESSION_TYPE.

принудительно устанавливать, если вдруг не установлен:
XDG_SESSION_TYPE=${XDG_SESSION_TYPE:-wayland}

То же самое, кстати, надо будет сделать и в /etc/X11/Xsession:
XDG_SESSION_TYPE=${XDG_SESSION_TYPE:-x11}

Это нужно для поддержки старых и кривых DM.

4) redirect stderr to a file

   Наверное, тоже надо.
   Куда-то, к примеру, в "$HOME/.local/share/wayland-session.log",
   имена предлагайте.

   Возможно, проверить сначала, что мы не запущены под GDM, sddm, ...
   которые сами делают stderr redirect
   и посмотреть в /proc/self/fd/2, это -f или -с

# redirect stderr to a file, if it is not yet redirected by DM
if [ ! -e /proc/self -o -c /proc/self/fd/2 ]; then
for errfile in "$HOME/.local/share/wayland-session.log"; do
	if install -m600 /dev/null "$errfile" 2>/dev/null; then
		exec &>"$errfile"
		break
	fi
done

4) <wayland>/profile.d.

Хоть мы уже втянули /etc/profile.d, но для
wayland session wrapper script нужен и свой отдельный

   <wayland>/profile.d

Смысл его существования в том, что ряд тулкитов и приложений
поддерживают wayland, но без волшебного понуждения в виде
магических переменных вида THIS_APP_PLEASE_DO_USE_WAYLAND=1
все равно по умолчанию запускаются под XWayland.
Такие костыли можно как раз в <wayland>/profile.d/ и сложить.

Кстати, проявилась тенденция переходить на использование
в качестве такого костыля
XDG_SESSION_TYPE=wayland
почему я и хочу форсить значение этой переменной в п.3.


5) <sessions>/profile.d.

Исторически сложилось, что у нас есть /etc/X11/profile.d
и в нем есть ряд скриптов.

Сейчас там 5 скриптов.

Из них только 1 X11 specific:
/etc/X11/profile.d/xapp-gtk3-module.sh

Остальные не совсем понятна логика, почему они в
/etc/X11/profile.d, а не просто в /etc/profile.d.

В случае
/etc/X11/profile.d/ssh-agent.sh
логика понятна, не хочется вызывать этот скрипт в
случае удаленного логина по ssh.
Но там вроде бы достаточно дополнительно проверить,
есть ли $SSH_CONNECTION, и с такой проверкой
можно смело переносить в /etc/profile.d
(поправьте, если не так, знающие люди!)

Что касается оставшихся скриптов
/etc/X11/profile.d/xdg-user-dirs.sh
/etc/X11/profile.d/zdg-user-dirs-install.sh
/etc/X11/profile.d/zdg-move-templates.sh
то мне не очень понятно, почему они не в /etc/profile.d.
(расскажите, знающие люди!)

Если их все же нельзя перенести в /etc/profile.d,
то придется дополнительно вводить каталог
<sessions>/profile.d,
Откуда будут читать и wayland-session,
и патченый /etc/X11/Xsession.

Если их можно перенести в /etc/profile.d, то перенести нужно,
и тогда они будут доступны и в wayland-session,
и в Xsession.

Также в /etc/X11/Xsession есть
TryXBrowser() and TryTextBrowser() stuff and
export BROWSER HELP_BROWSER

Этот кусок тоже логично выпилить и перенести в /etc/profile.d.

6. init.d
Для X есть /etc/X11/xinit.d.
Мне сначала показалось, что в 'wayland session wrapper script'
init.d не нужен. Напомню, что для xsession
DM __СНАЧАЛА__ запускает X, потом в запущенном X исполняется Xsession
и скрипты из xinit.d.

Для обертки wayland-session это не так. Во время его работы
wayland сервера еще нет и, возможно, никогда и не будет
(если, к примеру, запускается fbterm).
Поэтому иметь <wayland>/init.d бессмысленно.

Однако, анализ скриптов /etc/X11/xinit.d/ показал, что есть тема,
общая между Xsession, wayland compositor и fbterm, но не для
удаленного логина по ssh.

Это внесение пользовательских настроек в железо локальной машины,
на которой открывается сессия. Это может быть
* загрузка параметров alsa для не-pulse юзера,
* пользовательские настройки видеокарты
  #/etc/X11/xinit.d/nvidia-settings.sh     nvidia-settings
* пользовательские настройки для multiseat
  #/etc/X11/xinit.d/90-multiseat-*  setup-multiseat-*
и т. д.

Поэтому имеет смысл иметь <user-hardware>/init.d,
который запускать и из wayland-session, и из
/etc/X11/Xsession.

Прошу обсуждать, дополнять, критиковать.

P.S.

Про "II/Часть два. Что где в каком каталоге расположить и как назвать".

Специально не стал писать, так как сначала нужно определиться,
что нам нужно, а что, вроде <wayland>/init.d - нет.

В зависимости от итога, можно будет сделать структуру каталогов проще
или потребуется усложнять.

-- 

I V


Подробная информация о списке рассылки Devel