Documentation on "How can I use Hyprlock as a login screen when I start my computer"

[sand4rt]

Description

First of all, thank your for you work!

Asahi Linux comes with Fedora+SDDM by default, and it took me some time to figure out how to set up a unified login. Would it be beneficial to add this info to the documentation? as i've seen several questions on this topic

What i ended up doing was configuring SDDM to auto login (also possible with greetd) and then exec-once hyprlock:

Add this to /etc/sddm.config.d/kde_settings.conf:

[Autologin]
Session=hyprland
User=MY_USER_NAME

NOTE: run whoami and replace the output with MY_USER_NAME

Add exec-once=hyprlock || hyprctl dispatch exit to ~/.config/hypr/hyprland.conf

[sand4rt]

There is a splash though as described in: hyprwm/Hyprland#5832 (comment) (even with a empty config + a color as background to minimize computation). Not sure if there is an solution to this?

[PaideiaDilemma]

A display manager has the difficult and nuanced task of creating and managing a user session.
The login method is just a very small part of it.

This method works ok, if you want to use hyprlock as a login screen when you start your computer.
But it does not replace the display manager.

If you think this should be in the wiki (I am not sure if it is necessary), feel free to create a pull request in https://github.com/hyprwm/hyprland-wiki yourself.

[PaideiaDilemma]

There is a splash though as described in: hyprwm/Hyprland#5832 (comment) (even with a empty config + a color as background to minimize computation). Not sure if there is an solution to this?

@sand4rt you can try the --immediate-render flag to start hyprlock. Could make this a bit smoother.

[sand4rt]

@PaideiaDilemma thanks for the replies

A display manager has the difficult and nuanced task of creating and managing a user session.
The login method is just a very small part of it. This method works ok, if you want to use hyprlock as a login screen when you start your computer. But it does not replace the display manager.

Good to know! I don't mind having SDDM installed, just wanted to have a single login screen and login once when i boot. Not sure how secure this is BTW?

you can try the --immediate-render flag to start hyprlock. Could make this a bit smoother.

It does make it a little bit smoother but the splash is still there unfortunately

[PaideiaDilemma]

Not sure how secure this is BTW?

I can think of two security relevant problems:

• SDDM autologin launches you into the session right away. This is a risk in and of itself.
• There is a timeframe where hyprlock has not locked the session yet and Hyprland accepts normal keybinds and input. That is obviously bad, as you could theoretically kill hyprlock before it actually locks.

[sand4rt]

I was already concerned about your second point. Is there a possibility that Hyprlock can deal with this?

[PaideiaDilemma]

No, the compositor would need to implement a way to basically start locked, which would be out of protocol.

It would also introduce relevant side effects for startup that might beak stuff.

[PaideiaDilemma]

EXPERIMENTAL:

I have been using hyprlock as a greeter for greetd for the last week or so.
The code for it is here: https://github.com/PaideiaDilemma/hyprlock/tree/greetdLogin

I even implemented a session picker : )

What you need to do to make it work:

1. A minimal hyprland config with an exec-once that launches hyprlock with the --greetd option. This config needs to be accessible for the greeter user.

[default_session]
command = Hyprland --config /path/to/hyprland_greeter_config.conf

2. A hyprlock config that is accessible for the greeter user. In that config configure login:user and add a session-picker widget if you need one. hyprlock will search in /usr/share/wayland-sessions and /usr/local/share/wayland-sessions for sessions. You can also add a additional sessions with the login-session keyword. See https://github.com/PaideiaDilemma/dotnix/blob/8fb95b325d1dc3c3bbd323c726716e52297bbd5f/host/sessions.nix#L161 for my setup on nixos.

Why is this more secure?

With this setup, hyprlock is launched by a separate user. So if something would go horribly wrong, you are not logged in yet. The race for locking the wayland session is also irrelevant, since you wont be able to do anything with Hyprland under the greeter user, not having any keybindings, etc.

If anybody has some feedback on it, please let me know!

[MalpenZibo]

There's any chance that this fork could reach the upstream repository?
It would be very nice to use hyprlock as a greeter for greeted and as a session locker.

[PaideiaDilemma]

There's any chance that this fork could reach the upstream repository?
It would be very nice to use hyprlock as a greeter for greeted and as a session locker.

I am going to send a pr once I am happy with the code.

The only real problem this solution has is that it's a bit tricky to set up.

• You need an additional Hyprland config (that one would be generic, so we can maybe provide it.)
• Hyprlock will run as the greetd user. That means all the label commands for example will run under a different user, which may not have access to some shell commands. It also means that your config for greetd login needs to be accessible by this user.
• You need to configure greetd to start hyprlock.

All in all it might not be that bad as long as the docs do a good job.
But any ideas that aid in setting this up would be appreciated. After all I think most users essentially would just want to use their current hyprlock config for a display manager login, but sadly those configurations need to be made somehow.