After login, who takes over the desktop?

If you switch to a terminal-style login screen, do you also need to change how the desktop starts? Why can the desktop open while autostart and logout still misbehave? These two kinds of problems are often conflated because entering a password and reaching the desktop looks like a single action, but actually involves several handoffs of responsibility.

Separate the Login Service from the Login Interface#

In a greetd setup, greetd is the background login service, while the greeter is the interface the user sees and interacts with. greetd launches the greeter according to its configuration; the greeter collects the username and exchanges authentication prompts, user responses, and results with the service. The interface presents the interaction, while the service drives authentication and session handling.

Saying that “the greeter sends the command over after authentication succeeds” is therefore only shorthand. More precisely, the greeter requests a session, greetd sends back authentication messages requiring responses, and the greeter returns those responses until authentication succeeds. Only then does it request execution of the selected command. Authentication may involve more than one password prompt, so the interface cannot assume there is always just one question-and-answer exchange. [1]

The IPC start_session request carries a command-argument array, cmd, and an environment array, env. It is not three arbitrarily assembled pieces consisting of a command name, a separate args field, and an environment. Configuring a greeter usually does not require constructing protocol messages yourself, but understanding this boundary helps distinguish two checkpoints: whether authentication succeeded and whether the correct command was ultimately launched.

Which Layer Changes When You Change the Interface?#

greetd's default_session specifies the session started by default, usually the login interface. Its user is the account that runs the greeter, not the account you subsequently choose to log into through that interface. Confusing these identities leads to misreading the configuration.

The following structural example assumes tuigreet and sway are installed and that the system has correctly configured the account and service used to run the greeter. It illustrates the relationship between parameters; it is not an installation script that can overwrite an arbitrary distribution's existing configuration. On systems such as NixOS that manage these files, express the configuration through the corresponding modules. [2]

[default_session]
command = "tuigreet --cmd sway"
user = "greeter"

Here, greetd starts tuigreet, while --cmd sway supplies tuigreet's default session command. The former determines how the login interface appears; the latter determines what starts after login.

tuigreet can also read Desktop Entries in session directories to offer session selection. It supports distinct options for remembering usernames and sessions; for example, --remember and --remember-session do different things. Scan directories, cache permissions, and command-override behavior still need to be configured for the current version. Being based on greetd does not imply that another greeter behaves the same way. [3]

When choosing a setup, first distinguish two changes: keeping greetd and replacing the greeter changes the login-interaction implementation; switching to a different login manager that coordinates its own login process also replaces the background login service. The latter requires rechecking services, authentication configuration, session discovery, and recovery entry points. It is more than a new skin.

uwsm Takes Over the Graphical Session#

After login succeeds, the compositor handles windows and display, but a graphical session has other work to do: preparing the environment, placing programs in suitable systemd user units, coordinating autostart, and cleaning up according to dependencies on exit. uwsm is designed for standalone Wayland compositors and connects this work to the systemd user manager. It does not provide a password-login interface.

At least three objects are easy to confuse here: the login session tracked by systemd-logind, units in the systemd user manager, and the desktop displayed by the compositor. They are related, but are not three names for the same thing. A login session can start a graphical session, while some services in the user manager may exist before the desktop starts.

uwsm coordinates compositor units, environment preparation, and readiness, and integrates with graphical-session targets. Applications launched through uwsm app receive the corresponding systemd management. This process and resource management should not be mistaken for security isolation of untrusted programs. [4]

For a desktop environment that already has a complete session manager, do not assume it needs an additional uwsm wrapper. First follow that desktop's startup procedure, then determine whether a supported integration exists. Choose uwsm to supply session management missing from your current compositor setup, not because it happens to appear alongside a greeter in the same configuration tutorial.

The Real Integration Point Is the Startup Command#

The session name displayed by a login interface does not establish which layer it launches. What matters is what the selected entry's Exec ultimately executes. The official uwsm documentation describes display-manager integration through a Desktop Entry; the following retains that structure using generic names:

[Desktop Entry]
Name=Example compositor (UWSM)
Type=Application
TryExec=uwsm
Exec=uwsm start -- example-compositor.desktop
DesktopNames=example;

This assumes a separate example-compositor.desktop actually launches the compositor. The outer entry must have a different filename: it must not point to itself or reference an entry already wrapped in uwsm, which would duplicate the startup wrapper. Replace the example compositor name with an entry point that is actually installed and supported. [4]

Where to put the entry also depends on how the login frontend discovers sessions. A common location is wayland-sessions under a data directory, but an individual greeter may have configurable scan directories. Even if the file exists, a new login interface will not list it unless it scans that directory.

Thus, choosing a greeter and choosing uwsm independently reflects an architectural separation of responsibilities; it does not mean every combination is automatically compatible. After replacing the login interface, at minimum recheck whether entries are discoverable, command arguments are passed correctly, and the required environment is available.

The Desktop May Appear Before the Environment Handoff Is Complete#

Running export in a terminal affects child processes subsequently launched by that process. It does not automatically change the activation environment of a systemd user manager that is already running. An application working from a terminal but failing when launched as a service or through autostart is therefore a clue to investigate the environment propagation chain.

Some variables can be determined only after the Wayland compositor starts and must then be passed to later applications. The uwsm documentation specifically discusses WAYLAND_DISPLAY, DISPLAY when present, and readiness notification. Some compositors already provide the required integration; others need uwsm finalize at the appropriate point in their startup process. Do not import the entire environment again without understanding the existing integration. [4]

Starting a graphical session from kmscon adds a handoff between the terminal and the graphical session. This concerns terminal and display-resource handoff between the console and graphical programs, and cannot be explained solely by changing the greeter. When investigating a black screen, first establish the actual combination of login frontend, startup mechanism, and graphical components, then inspect the relevant logs. A blanket diagnosis such as “a black screen always means DRM master was not released” is not valid.

Autostart Is Not the Magic of a Single Target#

graphical-session.target expresses lifecycle relationships for a graphical session, but its active state alone does not prove that every application is ready. XDG autostart also involves entry generation, dependency activation, environment preparation, and entry conditions.

In the systemd-based path, systemd-xdg-autostart-generator converts eligible Desktop Entries into user services, which the desktop session then connects to xdg-desktop-autostart.target. Entry conditions such as Hidden, OnlyShowIn, NotShowIn, and TryExec can all affect whether an application starts. [5]

This is why concluding that “the input method did not autostart, so uwsm definitely was not used” is too hasty. The entry may not have been generated, it may have been generated but not activated, or the application may have started and then exited because of an environment or program error. Identify the failing step before deciding which component to change.

Read Configuration and Logs Along the Handoff Points#

The following commands are for observation and require the relevant tools and permission to read the logs. Unit names can vary with the installed setup. List the actual names first, then inspect the target's logs. Do not assume that the services named in the examples necessarily exist on your machine.

systemctl status greetd.service
journalctl -b -u greetd.service --no-pager

systemctl --user status graphical-session.target
systemctl --user status xdg-desktop-autostart.target
systemctl --user list-units --all 'wayland-*' 'app-*@autostart.service'
systemctl --user --failed

# 在列出的实际服务名上继续检查
journalctl --user -b -u example.service --no-pager

To exit a session managed by uwsm, follow its shutdown mechanism. uwsm stop stops graphical-session-related units and may also terminate the associated login session, so save your work before running it. It is not a read-only troubleshooting command and should not be placed in an automatic trial-and-error repair loop. [4]

Once this chain is clear, the choices become concrete: to change the login appearance, adjust the login interaction; to change session startup, inspect the Desktop Entry and startup command; to fix autostart or exit cleanup, inspect session dependencies and the environment. Each change then maps to a specific handoff point.