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

Help
1

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

2

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.

3

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

4

Hi @ppenguin , I know that this is an old post but I would like to know if you managed to find answers to your questions ?

I too am trying to understand what the best way is for HM to set env vars in my greetd/sway setup.
At the moment I am using this method that injects the vars in .profile but this doesn’t feel right and I wonder how the sway.wrapperFeatures would come into play as I haven’t been able to get it to work.

5

At the time I did a similar hack as I think yours is effectively (which means I log in from the terminal on tty1). I never felt the need to change it since, it feels hacky but works…

I have the following in my hyprland.nix:

  programs = {
    zsh.loginExtra = ''
      if [ "$(tty)" = "/dev/tty1" ]; then
        QT_QPA_PLATFORM=wayland
        NIXOS_OZONE_WL=1
        LIBSEAT_BACKEND=logind
        TERMINAL=alacritty
    '' + (lib.optionalString (config.i18n.inputMethod.enabled == "fcitx5") ''
      XMODIFIERS=@im=fcitx
      INPUT_METHOD=fcitx
      GLFW_IM_MODULE=fcitx
      QT_IM_MODULE=fcitx
      export XMODIFIERS INPUT_METHOD GLFW_IM_MODULE QT_IM_MODULE
    '') + ''
        export QT_QPA_PLATFORM LIBSEAT_BACKEND TERMINAL NIXOS_OZONE_WL INPUT_METHOD GLFW_IM_MODULE
        SSH_AUTH_SOCK=/run/user/$UID/keyring/ssh
        export SSH_AUTH_SOCK
        dbus-update-activation-environment --systemd --all
        echo "$(date -Is): starting Hyprland..." >> $HOME/.wsession.log
        Hyprland &> /dev/null
        echo "$(date -Is): Hyprland stopped" >> $HOME/.wsession.log
        systemctl --user stop hyprland-session.target
        logout
      fi
    '';
  };
1 Like
6

I see ! Sorry for the late reply.
Yes that is functionally the same I think too.

I must say that it hasn’t been giving me any problems since either :slight_smile: So I will just stay with this.

Thanks for replying!