[Feature Request] Autologin

[DarkDefender]

The issue is as follows:
Greetd does already provide "initial_session" support, but it is very limited.
For example it only supports hard coding in a username a command to run.
This means that what ever the last user or login command was from tuigreet is not taken into account.

Previously I solved this is a hacky way by patching greetd to be able to read files. So the "initial_session" section would look something like this:

[initial_session]
user_file = /var/cache/tuigreet/lastuser
command_file = /var/cache/tuigreet/lastsession

However this doesn't work anymore as tuigreet has moved on to a better system of storing the last session data.
(So that when using .desktop files to login, the command is now always up to date)

So I was thinking, perhaps a better way of doing it would be to either:

1. Introduce a new API in greetd that could query the login client for the last user and what command to execute to login.
   In addition to that, it could also perhaps query if it should auto login in the first place (perhaps the user has unticked the "autologin" in the greeter interface).

2. Make the initial_session section be able to execute commands to query the user/commands to use:

[initial_session]
user = 'cat /var/cache/tuigreet/lastuser'
command = 'tuigreet --print-last-session-command`

I realize that this is more of a greetd, topic. But I wanted to start here as I think asking the developer of the greeter that I use might be a good start.

Note that I personally think that there probably needs to be some sort of hand off between greetd and the greeter as the current initial_session functionality is not that great as it skips setting environmental variables that for example tuigreet sets when logging in with Xorg/Wayland sessions.

[DarkDefender]

I've implemented a proof of concept where I added a new IPC command that can be used for autologin.
https://github.com/DarkDefender/greetd/tree/autologin
https://github.com/DarkDefender/tuigreet/tree/autologin

I'll add an option to disable this on the greetd side of things so if it is configured to not allow autologins, then it will return an error if you call this command. I will also hook up some logic so that we can only autologin once. (So we won't get logged in when you try to logout).

Does this seem like it is going in the right direction?

[DarkDefender]

I've updated my fork to now only allow using the autologin once per boot and the feature is now disabled per default.
To me, it is now feature complete.

[DarkDefender]

@apognu do you have any thoughts about the code changes?

[bb010g]

This feature would be useful for feature parity with non-greetd display managers in NixOS (see the services.displayManager.autoLogin option and services.displayManager.sessionData.autologinSession config value).

[DarkDefender]

I rebased my work and discussed this with kennylevinsen on IRC.
We came to the conclusion that it would probably be best if this is handled by greetd without any client involvement.

So if auto login is active, it will work like the initial_session option in greetd (but without hard coded user, env, command). While we could simply store the last enviroment and command used to login on greetd side, these might change with an desktop environment update (a Plasma 5 -> Plasma 6 update for example). This would lead to the same issues that tuigreet had previously with "remember session" before it was changed to simply store the path to the .desktop file instead.

To be able to do this properly, greetd would have to implement a lot of things that tuigreet already implements like .desktop file parsing and setting up the correct environment variables.
This would mean creating new APIs that clients can use so that greetd knows what .desktop file was used to create the session.

For this kennylevinsen wants to think a bit on how he would implement this in a way that is useful and easy to use for greetd client developers. This could in theory lead to clients not needing to implement .desktop parsing and doing environment setup themselves if they don't want to do it manually.

Shorter term, kennylevinsen is open to simply storing the last user and login on the greetd side even if we would run into some issues.

@apognu Do you have any opinions on this?
It could potentially mean that tuigreet won't have to do any .desktop file parsing and setup itself. But of course Kenny doesn't want to ruin any existing flexibility or workflows.

From my point of view it would be nice longer term to have this functionality in greetd itself so clients do not have to do their own implementations for using .desktop files.

(And when that happens, it would be trivial for greetd to handle auto login without having to start up any client first)

[apognu]

For the first proposal, meaning greetd remembering the last logged-in user and, if configured to do so, making it so the session starts, that makes total sense to me. I am a bit more skeptical about the session / .desktop part, but admittedly I have not spent a lot of time thinking about it.

As far as I know, the greeters do not communicate any information about .desktop files back to greetd, simply a command to run. Does Kenny mean to change the IPC in order for the greeters to add some context information on the session that is run? What happens for those sessions that do not have a desktop file?

Note that I do not have an alternative right now (or the alternatives that come to mind are at least as complex, such as the one you mention in your initial message), I am just thinking out loud (or rather in a written form).

Do you have a link to the greetd issue where this is being discussed?

[DarkDefender]

As far as I know, the greeters do not communicate any information about .desktop files back to greetd, simply a command to run.

Right, there is no API for this currently.

Does Kenny mean to change the IPC in order for the greeters to add some context information on the session that is run?

Yes, that is what he is thinking about how to introduce this in a nice way.

From my point of view, it might be best to just implemented the .desktop session handling in greetd so that the clients doesn't have to implement all the logic to setup the session correctly. (This way there is also less duplicate work going on between different clients)

What happens for those sessions that do not have a desktop file?

From what I gathered, he absolutely wants greeters to have the flexibility to still create sessions that doesn't have .desktop file attached to it.

The issue is basically that if greetd is going to do auto logins by itself, then it should also be able to correctly start up the session itself from scratch. If it doesn't do any .desktop parsing or environment setup, then the last manual login information will eventually be outdated and lead to issues.

Do you have a link to the greetd issue where this is being discussed?

I did not create anything yet. We simply discussed it in his IRC channel.
Kenny said that he wanted more time to think about this so he can form a more coherent and thought out solution (if there is any).

[apognu]

Thank you for your detailed answer, I will wait and see what is being decided.

I fail to see, yet, however, how that would offload the greeter from managing the desktop files. We would still need to list sessions, build the proper environment for a session, including différences between X11 and Wayland, handle wrapper scripts, etc. I find it surprising that Kenny would consider duplicating this bah of worms into greetd. 😁

[DarkDefender]

We would still need to list sessions, build the proper environment for a session, including différences between X11 and Wayland, handle wrapper scripts, etc.

I think the idea is that the greeter wouldn't need to do this if this is integrated in to greetd itself.

The APIs would look different for this of course.