Strangely, while I was testing, I’ve made a typo in the
displayManager.session.start and my session did not opened, so I have the feeling that what’s written in it was taken into account in my case. (btw, I’m running on
unstable maybe something changed since ?).
Well that is weird. I’ve checked, and both on
release-19.09 the display manager’s session script contains (because of the exec, if the test succeeds this will be the last command run by the script) :
# Allow the user to setup a custom session type.
if test -x ~/.xsession; then
eval exec ~/.xsession "$@"
If the test fails, this script goes on to execute the “selected session script”, which is the session script corresponding to the session selected by the user in the DM, and which contains
I believe that if the
.xsession file is created by home-manager, then the only needed thing is to provide a
xorg-session desktop file to simply execute it. It would be clean, and working as expected.
Well it is similar to what I’m doing (with a custom session as in your example, and a patch to home-manager to allow me to override the configured session):
- home-manager creates the
- on login, LightDM calls the system-level session script
- this script finds
~/.xsession, and executes it, whatever the session selected in LightDM
/.xsession runs the WM configured in
home.nix if the selected session was
xsession, otherwise it runs the script corresponding to the selected session.
(now it should be clear why I set
"" : it should never be executed, as it’s a fake session that defers to
I don’t understand what you mean by:
It just requires adding a helper to create it (and check it on evaluation time).
In order to create what ? The session in
I’m already running the setup you described, but I did not need such a helper. Just a few lines in the system config to configure the special session for xsession, and the two patches in NixOS+nixpkgs to allow overriding the session at runtime.