Add a generic Wayland session wrapper script for login managers

[primeos]

To properly initialize graphical sessions we'd need something like the xsession-wrapper for Wayland. Ideally we'd just modify that script by inserting X11/Wayland specific parts via conditionals (so that we have a generic abstraction that can be used for both X11 and Wayland).

The current xsession-wrapper script can be found here: nixos/modules/services/x11/display-managers/default.nix#L31

Note: I'm simply opening this as a tracking issue because this was already requested multiple times. If someone would be interested in working on this that'd be very welcome (I'm not using a graphical login/display manager so it's unfortunately unlikely that I'll find time to work on this. I'll try my best to answer questions and review PRs though.).

cc #57602 and #109542

[matthewbauer]

I'm not sure how much can be shared, but the cage module does this:

https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/services/wayland/cage.nix

It's not completely useful for sway because cage intentionally avoids a login manager (it just automatically logs in as the demo user).

[primeos]

@matthewbauer I think we might be talking about two different things here. Or I'm missing something in the cage module.

My issue description is unfortunately pretty brief but the purpose of the session wrapper would be something like:

• Setup the environment (source /etc/profile, etc.)
• Use systemd-cat for logging
• Maybe set some Wayland specific environment variables (e.g. XDG_CURRENT_DESKTOP, https://github.com/swaywm/sway/wiki/Running-programs-natively-under-Wayland)
• Run systemctl --user import-environment for relevant environment variables (e.g. $DBUS_SESSION_BUS_ADDRESS but unfortunately we likely cannot set and import $WAYLAND_DISPLAY before running the compositor)
• Run systemctl --user start graphical-session.target

The main challenges are likely to create a good abstraction, find good defaults, and make everything as overridable/configurable as possible (without overdoing it).

[peterhoeg]

Here is one way to handle things for KDE Plasma: https://github.com/NixOS/nixpkgs/pull/117102/files?w=1

[gdamjan]

ideally the greeter would start systemctl start --user wayland-session.service and then the user decides what service is an alias for wayland-session.service (or another name).

this can be made (I've had a sway setup like that on another distro)

[ppenguin]

ideally the greeter would start systemctl start --user wayland-session.service and then the user decides what service is an alias for wayland-session.service (or another name).

this can be made (I've had a sway setup like that on another distro)

Maybe you could elaborate a bit? I guess if one would combine this with the .desktop mechanism used by both X display managers and "agnostic" loginmanagers (like greetd), would this then look like a simple wrapper script for the session that contains the --systemctl --user start ... stuff and is referenced in the share/sessions/mysession.desktop's Exec=sessionwrapper?

In this way one might have the best of both worlds: adherence to existing standards but a definition method that is largely session-type agnostic. One could probably even decouple the display manager from the session better, so it's unimportant whether a wayland compositor is started from an X-DM (e.g. lightdm) or vice versa? (Though probably one would need to handle running/stopping Xorg (which traditionally runs as root) before getting into the user sesion handling.)

[kira-bruneau]

ideally the greeter would start systemctl start --user wayland-session.service and then the user decides what service is an alias for wayland-session.service (or another name). this can be made (I've had a sway setup like that on another distro)

Maybe you could elaborate a bit? I guess if one would combine this with the .desktop mechanism used by both X display managers and "agnostic" loginmanagers (like greetd), would this then look like a simple wrapper script for the session that contains the --systemctl --user start ... stuff and is referenced in the share/sessions/mysession.desktop's Exec=sessionwrapper?

In this way one might have the best of both worlds: adherence to existing standards but a definition method that is largely session-type agnostic. One could probably even decouple the display manager from the session better, so it's unimportant whether a wayland compositor is started from an X-DM (e.g. lightdm) or vice versa? (Though probably one would need to handle running/stopping Xorg (which traditionally runs as root) before getting into the user sesion handling.)

Yep! I think that's what @gdamjan was saying. I was actually looking into this a bit earlier today and the systemd special unit docs recommend that you create a service that BindsTo=graphical-session.target, instead of starting/stopping graphical-session.target manually.

I think instead of making wayland-session.service an alias though, it might be helpful to have more specific targets (eg. sway-session.service, i3-session.service, gnome-session.service, ...) that either bind to a wayland-session.target or xsession.target. That way, if you have multiple DEs installed, you can scope services to only start on specific DEs.

[ibrokemypie]

Any updates on this? I am running into an issue with my own setup where waybar, which has systemd.enable=true and systemd.target="sway-session.target" tracking the sway target created by wayland.windowManager.sway.systemd.enable = true;, gets stuck in a bootloop if I exit sway, and eventually gives up relaunching, causing a second boot of sway to get no waybar.

This issue is described over here https://github.com/Alexays/Waybar/issues/1371 and relates to sway not closing its session.

Of note is the suggestion to use uwsm https://github.com/Vladimir-csp/uwsm which sounds like it could solve this issue entirely if it were used by nix?

Also, referencing https://github.com/NixOS/nixpkgs/issues/169143#issuecomment-1864855055 as it is related

[Vladimir-csp]

Of note is the suggestion to use uwsm https://github.com/Vladimir-csp/uwsm which sounds like it could solve this issue entirely if it were used by nix?

After the recent round of improvements I consider it pretty stable. Bug reports and feature requests are welcome ;)

[JohnRTitor]

Of note is the suggestion to use uwsm https://github.com/Vladimir-csp/uwsm which sounds like it could solve this issue entirely if it were used by nix?

I support the idea but I lack the expertise in implementing this in Nixpkgs, would be nice if someone could pick this up!

[JohnRTitor]

Let's add the package to get started. https://github.com/NixOS/nixpkgs/pull/329582

[SuperSandro2000]

I think instead of making wayland-session.service an alias though, it might be helpful to have more specific targets (eg. sway-session.service, i3-session.service, gnome-session.service, ...) that either bind to a wayland-session.target or xsession.target. That way, if you have multiple DEs installed, you can scope services to only start on specific DEs.

That is nothing we should really support as it will create a lot of issues like #333747 and incompatibilities like what ssh askpass program or gpg agent pop up to use which we cannot generically solve.

• Setup the environment (source /etc/profile, etc.)
• Use systemd-cat for logging
• Maybe set some Wayland specific environment variables (e.g. XDG_CURRENT_DESKTOP, Wiki: Running programs natively under Wayland (swaywm/sway))
• Run systemctl --user import-environment for relevant environment variables (e.g. $DBUS_SESSION_BUS_ADDRESS but unfortunately we likely cannot set and import $WAYLAND_DISPLAY before running the compositor)
• Run systemctl --user start graphical-session.target

Those are all only really relevant to self-built display managers like sway. Plasma 6 does all of that without us doing it ourselves.

Also this already exists at https://github.com/NixOS/nixpkgs/blob/745bed037145214b3c1612fabbbe26a3758f1fcb/nixos/modules/programs/wayland/wayland-session.nix

So I think there is not much left here to do other than cleaning some little bits up.