<html> <head> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> </head> <body> Hello everyone! As an experiment I wrote a session manager for standalone wayland compositors that utilizes systemd user-level daemon features for graphical sessions: <a class="moz-txt-link-freetext" href="https://github.com/Vladimir-csp/uwsm" moz-do-not-send="true">https://github.com/Vladimir-csp/uwsm</a> It can either manage targets by itself and launch wayland session in a scope, or launch wayland session as a service and fully rely on dependencies. I have some conceptual questions regarding where various user processes really should end up in. <pre>user-N.slice session-N.scope stuff launched in login console Xserver lanuched via startx goes here so are apps launched inside X session <a class="moz-txt-link-abbreviated moz-txt-link-freetext" href="mailto:user@N.service" moz-do-not-send="true">user@N.service</a> app.slice native in-session services XDG autostart derived services currently uwsm-managed units end up here so are all apps launched inside uwsm-managed wayland sessions. init.scope systemd internal stuff session.slice per-user important services </pre> Unlike the case of X session launched via startx, session-N.scope now only has "login" and "systemctl --user start --wait wayland-wm@${WM}.service" processes. Seems kinda barren. Intuitively I would expect to have apps launched in my session here. The whole graphical session (wayland-wm@${WM}.service or wayland-wm-${WM}.scope depending on uwsm mode of operation) and apps live in the app.slice. Which seems to be in accordance to app.slice description in systemd.special manual. But those apps know which session they sort-of belong to because $XDG_SESSION_ID (along with some other vars) is exported by uwsm to systemd activation environment during startup. It seems kinda hacky, but works. Also systemd.special manual recommends putting display servers into session.slice. But in case of a wayland compositor it is impossible to separate it from the apps, because the compositor handles keyboard shortcuts (which launch apps or launchers which launch apps). Is this recommendation even feasible for wayland? If the task at hand is to launch a wayland session after login, propely utilizing graphical-session-pre.target, graphical-session.target, xdg-desktop-autostart.target, am I going in the right direction? Which of the two startup modes I implemented is more correct? Any advice would be welcome. Thank you. </body> </html>