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, includingSSH_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 aseval $(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:
- define the necessary session
.desktop
file(s) inconfiguration.nix
(xserver.displayManager.sessionPackages
<=hyprland
HM module ?) - refer to those from the
greetd
config - 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 forsway
(which I assume actually work, not tested though)? - where/how is the
sessionWrapper
(of HMsway
) 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
’sExec
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 thesway
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