Wayland/greetd session env management (how to do it correctly *and* working?)

I recently switched to wayland using Hyprland, and I’m generally very happy with it.

Session env management is a huge mess, however. I know I could make life easy by using the “boxed” UX of sway and gdm, but I don’t want to. I want to use greetd-gtk and hyprland.

So what I want:

  • use HM modules where possible
  • have “correct” system/user separation, i.e. the available sessions are set in greetd, but their “implementation” with HM
  • I need Hyprland executed with a full HM environment, including SSH_AUTH_SOCK and HM-vars, etc., otherwise apps launched with e.g. rofi don’t work well
  • gnome-keyring unlocked on login (works already through setting security.pam.services.greetd.enableGnomeKeyring = true; => but the wayland session doesn’t seem to correctly inherit the necessary env.
  • use the HM service of gnome-keyring, so that it will actually behave the same to the session as eval $(gnome-keyring-daemon --start ...). While this partly works, it seems the env propagation (and possibly the correct starting order of the compositor) do not, resulting in a degraded session env.

I think the main issue is, that wayland compositors think they should exec apps that one considers to be “autostart”, which IMHO is contrary to HM, XDG (and also xsession) philosophy and not good practice for apps that the user wants to be “graphical session” related, regardless of which compositor is used.

So I guess the objective should be to:

  1. define the necessary session .desktop file(s) in configuration.nix (xserver.displayManager.sessionPackages <= hyprland HM module ?)
  2. refer to those from the greetd config
  3. define/override session-properties in HM => this would be through wayland.windowManager.hyprland, to convince it to “do the right thing” and inherit the HM env and perform “autostart”

If this is indeed the correct/idiomatic strategy (it seems that wayland.windowManager.sway provides some related mechanisms), then

  • does this mean that the best way is to “improve”/extend the hyprland HM module to support similar features as the one for sway (which I assume actually work, not tested though)?
  • where/how is the sessionWrapper (of HM sway) actually visible in the realised config? I.e. I couldn’t find where (apart from the session’s .desktop file) the actual wrapper is built from HM’s respective WM module? And would/should that lead to the wrapper script being called in the .despktop’s Exec instead of just the compositor executable?
  • I have no idea how passthru.providedSessions = ["hyprland"]; actually works (pointers/explanations?), but it seems additions I copied over from the sway module didn’t have any effect on the session (though it let me build my config with added options defined).

So long story short: who knows what the actual design objective of nixos/home-manager is w.r.t. graphical session management including a seamless dbus/systemd/env experience and how to achieve this “correctly”? Would this be limited to improving the hyprland HM module (and how??), or do other things need to be modified as well?

Edit: added gnome-keyring service topic

I know this might not help directly, but I have asked myself very similar questions. I wanted to do something very similar and settled for logging in on the cmd line and running sway (in my case) from bash manually. So I am also very interested in answers to any of your questions.

Since you’re using sway, you could actually try to use the HM-module’s “extra’s” that are missing from the hyprland HM module, and test whether indeed it gives you a proper session env. That would even “help the case” in that it could indicate whether it’s worth the hassle to extend the hyprland module similarly.

I’m talking about extraSessionCommands, extraOptions and wrapperFeatures here, but I’m not sure how the wrapper mechanism actually works though (while the concept is clear, I’ve no idea how it is supposed to be used and what it does to the session scripts, that’s part of the question).

P.S.: To use greetd-gtk idiomatically (reminding me that we need module options for assigning a gtk-theme from pkgs in the future as well), I borrowed from @fufexan 's (very helpful) configs: https://github.com/fufexan/dotfiles/blob/d37eb7e7e8ab731e8253cdbe0a6edaa265fc81f1/modules/greetd.nix