nixos/hypridle: hypridle does not actually start upon starting the graphical-session

[Atemu]

Describe the bug

A clear and concise description of what the bug is.

Discovering this bug was quite a doozy. hypridle.service is not actually wanted by graphical-session.service because it's not linked in /etc/systemd/user/graphical-session.target.wants/.

Steps To Reproduce

Steps to reproduce the behavior:

1. programs.hypridle.enable
2. systemctl --user list-dependencies graphical-session.target

Expected behavior

A clear and concise description of what you expected to happen.

hypridle.service should be wanted by graphical-session.target

Screenshots

If applicable, add screenshots to help explain your problem.

Additional context

Add any other context about the problem here.

The upstream intention appears to be that hypridle starts with graphical-session.target. This, however, is only useful if you want all of your sessions to have hypridle running which is likely not the case if you have any desktop session other than hyprland.

I personally solve this by introducing a hypr-session.target which wants graphical-session.target (you need something like this in order to even be able to start graphical-session.target anyways) but that requires me to configure hyprland to start and stop this target.

Honestly at this point, I think the hypridle option should simply be removed. Enabling hypridle is not something NixOS can reasonably handle for the user at this moment.

Perhaps we can get upstream to make such a hypr-session.target an official thing and add logic to the compositor to handle it so that the target works without any hyprland user config similar to the systemd env vars integration.

Notify maintainers

@fufexan @JohnRTitor @wozeparrot

Metadata

Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.

[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
output here

---

Add a :+1: reaction to issues you find important.

[JohnRTitor]

Looks like the same issue as https://github.com/NixOS/nixpkgs/pull/340874#issuecomment-2365302744

We just need to specify it manually like this: https://github.com/NixOS/nixpkgs/blob/c31898adf5a8ed202ce5bea9f347b1c6871f32d1/nixos/modules/programs/wayland/waybar.nix#L25

[Atemu]

That would indeed be the "fix" but please read the discussion in "additional context".

[JohnRTitor]

Perhaps we can get upstream to make such a hypr-session.target an official thing and add logic to the compositor to handle it so that the target works without any hyprland user config similar to the systemd env vars integration.

That would be a decision of @fufexan and Vaxry.

I think the hypridle option should simply be removed.

The NixOS option is pretty basic way of installing the package and enabling the service. Of course any customisation should be done via .config file by users.

Enabling hypridle is not something NixOS can reasonably handle for the user at this moment.

Nor other distros. A service depending on graphical-session will always be run in every DE that start the target.

Perhaps you might consider running the other DEs in specialisation so that they never conflict with each other.

[Atemu]

I'd appreciate if you didn't just merge a band-aid while we're still in the middle discussing the core of the issue.

[Atemu]

The NixOS option is pretty basic way of installing the package and enabling the service

That's the thing though: If enabling the service isn't something we can reasonably do from the NixOS side, all the module would do is add hypridle to systemPackages and we don't need a module for that; the user could just do that themselves.

Nor other distros. A service depending on graphical-session will always be run in every DE that start the target.

That's honestly just broken. I don't think we should ship/enable such a broken system in NixOS.

Users can decide to use it using simple tools but that's on them in that case.

[JohnRTitor]

Thanks for reopening this, didn't mean to close the discussion, forgot to unlink the issue before merging.

The PR was a valid fix so I did not think it would be right to stall it.

[Atemu]

The PR was a valid fix so I did not think it would be right to stall it.

My argument is that it's not a "valid fix". It adds a band-aid to enable a system that is fundamentally broken.

Perhaps you might consider running the other DEs in specialisation so that they never conflict with each other.

Forgot to reply to this:

Specialisations are never a good solution, especially to problems like this one that need to be handled dynamically.

[JohnRTitor]

That's the thing though: If enabling the service isn't something we can reasonably do from the NixOS side

The safest way of doing it would be from a distro-side Hyprland config file as mentioned in https://github.com/NixOS/nixpkgs/pull/335625#issuecomment-2296414172

exec-once = hypridle &

[JohnRTitor]

While we are waiting for that to be implemented, if this really needs to be dynamic right now, hypridle could just be added to systemPackages and then started from hyprland user config file instead.

[Atemu]

exec-once = hypridle &

This is in no way equivalent to a systemd service.

if this really needs to be dynamic right now,

I don't see any need for haste here.

[JohnRTitor]

My argument is that it's not a "valid fix". It adds a band-aid to enable a system that is fundamentally broken.

Issue title is that it didn't start with graphical-session, that part is fixed. I am not sure what else you want me to do here.

If a gnome service only wanted by graphical-session, it will be started even if a KDE session is running. Correct me if I am wrong, but I don't think we, as a distro, do not have a solution for this.

Running multiple DEs on a system will at some point cause a conflict. ie. GTK theme configured by KDE, will be applicable in GNOME as well because they modify the same config file.

Specialisations can isolate some part of it but that's it.

If a hypland-session.target is needed to better configure these type of services, that request should go to upstream, not here.

[fufexan]

Thoughts about the existing https://github.com/hyprwm/Hyprland/blob/main/example/hyprland-session.service? I was planning on configuring it through meson/cmake.

Perhaps we can get upstream to make such a hypr-session.target an official thing and add logic to the compositor to handle it so that the target works without any hyprland user config similar to the systemd env vars integration.

Will look into this.

[Atemu]

If a gnome service only wanted by graphical-session, it will be started even if a KDE session is running.

Indeed which is why GNOME has gnome-session@SESSION.target AFAIUI.

Making this a template target (didn't even know that was possible) strikes me as a good design too.

If a hypland-session.target is needed to better configure these type of services, that request should go to upstream, not here.

Right the problem is that we as NixOS chose to provide a hypridle user service that is fundamentally broken, that's the issue at hand here.

Thoughts about the existing https://github.com/hyprwm/Hyprland/blob/main/example/hyprland-session.service? I was planning on configuring it through meson/cmake.

Hm, not sure whether we should have the whole compositor in a service. This would require integration from the login managers right?

The target should exist independently of that though. The interesting part is that Hyprland would need to internally start and stop this target based on its internal state (start it after startup, stop it before shutdown).

Running it as a service could automatically start and stop the target but that seems most useful as a fallback to stop the session target when hyprland crashes. Not sure how other DEs handle this.

[Atemu]

GNOME appears to have a session-manager service which is somehow started by gnome-session-binary.

KDE has a plasmashell.service and a plasma-kwin_wayland.service which are somehow started by startplasma-wayland.

So it appears running the compositor as a systemd service isn't far fetched.