From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa.local.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,RP_MATCHES_RCVD autolearn=ham autolearn_force=no version=3.4.1 DKIM-Filter: OpenDKIM Filter v2.11.0 zen.imath.kiev.ua 88C1A8114F84 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=imath.kiev.ua; s=hydra; t=1638470123; bh=zFF760PMyxLTwMiYzODjW/LzboCjN6NIqzBFAsKRGC8=; h=Date:From:To:Subject:From; b=T9+mvEeJknY8bT4MsY0RITc80CuWLTLK1m/f/sBczpXvroH3b7sDcoM8mnRk2TJ1E Zhv4LR59XAiKPcjgCjcL31ZnS8Hr/vJGXRzpY+VgvrOV4ORviRV6XamcKioZ8PH06M VYG17lQZUopKDkwP1uczO0qlgn+Zr8HNnPOCeI+A= Date: Thu, 2 Dec 2021 20:35:23 +0200 From: Igor Vlasenko To: devel@lists.altlinux.org Message-ID: <20211202183523.GA29870@dad.imath.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.9.1 (2017-09-22) Subject: [devel] RFC: wayland session wrapper script X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2021 18:35:30 -0000 Archived-At: List-Archive: List-Post: Уважаемые коллеги! Как показал #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) /profile.d. Хоть мы уже втянули /etc/profile.d, но для wayland session wrapper script нужен и свой отдельный /profile.d Смысл его существования в том, что ряд тулкитов и приложений поддерживают wayland, но без волшебного понуждения в виде магических переменных вида THIS_APP_PLEASE_DO_USE_WAYLAND=1 все равно по умолчанию запускаются под XWayland. Такие костыли можно как раз в /profile.d/ и сложить. Кстати, проявилась тенденция переходить на использование в качестве такого костыля XDG_SESSION_TYPE=wayland почему я и хочу форсить значение этой переменной в п.3. 5) /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, то придется дополнительно вводить каталог /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). Поэтому иметь /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-* и т. д. Поэтому имеет смысл иметь /init.d, который запускать и из wayland-session, и из /etc/X11/Xsession. Прошу обсуждать, дополнять, критиковать. P.S. Про "II/Часть два. Что где в каком каталоге расположить и как назвать". Специально не стал писать, так как сначала нужно определиться, что нам нужно, а что, вроде /init.d - нет. В зависимости от итога, можно будет сделать структуру каталогов проще или потребуется усложнять. -- I V