tuigreet Review: Configuring a greetd Graphical Console Greeter

Why tuigreet Fits a greetd Login Stack

tuigreet is a graphical console greeter for greetd, but its interface is rendered in a terminal rather than as a conventional mouse-oriented desktop window. It is intended for administrators who configure Linux login sessions, especially on systems using greetd under Wayland or Xorg. The application presents the authentication prompt, lets a user select a session, and exposes power controls from the login interface.

The project targets a specific part of the login stack. It does not replace greetd or PAM. Instead, the README describes tuigreet as a greeter built for greetd, and the Nix configuration presents tuigreet as greetd's `default_session` command. That boundary matters during deployment: authentication policy still belongs to the surrounding greetd and PAM setup, while tuigreet handles the interface through which a user enters credentials and chooses a session.

The feature set is aimed at practical variations in Linux installations. A system administrator can display `/etc/issue`, add a clock, replace the issue text with a one-line greeting, widen the form for long PAM challenge messages, and adjust component padding. Users can select desktop sessions discovered from system session declarations, retain a successful username, remember a command and session, or store a separate session choice for each user. These controls make the project more relevant than a fixed login prompt, although its usefulness still depends on the sessions and services already installed on the host.

Authentication, Sessions, and Remembered State

The core flow begins when greetd starts tuigreet as its configured session command. tuigreet renders a prompt over either its plain terminal surface or an optional animation. A user enters authentication information, selects or confirms a session command, and asks greetd to open that session. The exact PAM exchange is not documented in the README, so its stages, prompts, and failure messages should not be inferred from the interface alone.

Session selection is data-driven rather than limited to one hard-coded desktop command. The README says that `F3` lists sessions declared by the system and can include custom sessions. `F2` opens an editor for the command that will run after login, while `F12` exposes power options. This creates three distinct controls: session discovery, manual command editing, and system power actions.

Persistence is deliberately divided into three behaviors. `--remember` prefills the username after a successful login. `--remember-session` retains command and session configuration between runs, although a manual selection overrides the value supplied by `--cmd`. `--remember-user-session` records the selected session for each user and saves it only after successful authentication. That final condition is significant because rejected authentication does not change the stored per-user selection.

The README does not identify the exact persistence files or directories. It also does not document rollback for remembered state. Operators who need reproducible provisioning or controlled cleanup should therefore inspect the files created by the selected version rather than assume that a documented reset command exists.

Installing tuigreet Through AUR or Nix

The README identifies Nix as the primary installation and development method, but it also lists prebuilt release binaries, two AUR packages, Nixpkgs integration, and Nix flakes. Tagged binaries are linked from the releases tab. The workspace is written in Rust, and `Cargo.toml` declares Rust `1.95.0` as its minimum version, so a source build also requires a compatible Rust toolchain.

On Arch Linux, the README distinguishes a precompiled package from a package compiled from the latest commit. The command below uses `yay`, although an operator using another AUR helper would need to follow that helper's interface. The first command installs `greetd-tuigreet-fork-bin`; the second installs `greetd-tuigreet-fork-git` and depends on the Rust toolchain.

# Install the built binary from the AUR. This uses tuigreet's own releases.
$ yay -S greetd-tuigreet-fork-bin

# Alternatively, use the -git version to build from source. This depends on
# the Rust toolchain.
$ yay -S greetd-tuigreet-fork-git

For NixOS, the documented first-use path configures `services.greetd`, enables the service, and sets `default_session` to a command from `pkgs.tuigreet`. The commented configuration also indicates that `--config` can be passed to the executable, although the README does not provide a complete configuration file in this example.

{
  services.greetd = {
    enable = true;
    settings = {
      default_session = {
        user = "greeter";
        command = getExi' pkgs.tuigreet "tuigreet"; # you may pass `--config` here
      };
    };
  };
}

The project also supports Nix flakes. The README identifies the package as `inputs.tuigreet.packages.${prev.hostPlatform.system}.tuigreet` and describes a development-version override using `overrideAttrs`. Because the README example is truncated, this article does not reproduce the incomplete override. A production operator should instead pin an explicit release or revision and review the resulting derivation before applying it.

Starting with Issue Text, Time, and Prompt Width

The default interface is intentionally sparse. According to the README, it contains the authentication prompt and a small status area. A first real deployment can add system identity and time without replacing the default session structure. For example, `--issue` prints the host's `/etc/issue` above the prompt, while `--time` adds the current date and time. The latter accepts a format through `--time-format`.

If the site distributes its own notice, `--greeting` can replace `/etc/issue` with one line of text. This is not an addition to the issue output in the documented usage. Choosing between the two options keeps the header predictable, which is useful when the login screen must remain compact.

PAM challenge text can be wider than tuigreet's default 80-column prompt container. `--width` changes that container width, while the README notes a family of `*-padding` options for spacing. The exact available padding flags are deferred to `tuigreet --help`; the README excerpt does not enumerate them, so naming an unconfirmed flag would be misleading.

A sensible first review after installation is to open every `F2`, `F3`, and `F12` menu on the actual terminal size used by greetd. The README documents those hotkeys and their functions, but it does not define every available power action or custom session format. That direct inspection establishes whether commands and labels fit the target environment before administrators make the settings part of a standard image.

Animated Background Rendering and Its Cost

tuigreet can paint an animated backdrop behind the login form. The feature is disabled by default and can be selected by name with `--background <name>`, or through `kind` in the `[background]` configuration section. `F4` opens an in-session animation menu that includes every available animation and a `None` entry. The documented default hotkey can be changed through `--kb-background` or the `background` field in `[keybindings]`.

Two animations are documented. `doom` renders a fire effect controlled by `--doom-height`, `--doom-spread`, and `--doom-colors TOP,MIDDLE,BOTTOM`. Its color values may use `#RRGGBB`, `0xRRGGBB`, or named colors. `matrix` renders falling digital rain controlled by stream length, fall speed, and three color bands. Selecting an animation through the `F4` menu rebuilds it with that animation's default options, so custom command-line parameters are not described as being carried over into menu-based selection.

The rendering model addresses legibility directly. The login form clears the terminal cells beneath it before drawing the prompt, so background movement does not remain visible through form content. When an animation is active, the documented default frame rate is 30 FPS, compared with a 2 FPS UI tick when no animation is running. With `--background none`, or with the option omitted, the README says the feature is disabled entirely and incurs no per-frame animation cost.

This does not establish terminal GPU behavior or performance on every compositor. Those details are silent in the README. Administrators should verify the animation path on each Wayland or Xorg configuration rather than treating the stated default frame rate as measured system performance.

Maintenance, Packaging Choices, and the GPL Boundary

The repository is not archived, its last push was on 2026-10-14, and tagged releases include `0.11.0`, `0.11.1`, and an earlier `0.9.1`. These dates indicate recent repository and release activity, but they do not guarantee compatibility with every Linux distribution. A production upgrade should also account for greetd, PAM prompts, session definitions, terminal capabilities, and Rust package changes outside tuigreet itself.

Packaging creates a deliberate upgrade trade-off. A release binary reduces the need to maintain a compiler toolchain, while the AUR `-git` package follows the latest commit and therefore has a different update boundary. Nixpkgs provides a packaged executable, while a flake can pin or override source information. The README describes Nix as the primary installation and development route, but it does not publish upgrade or rollback instructions for remembered usernames and sessions.

The workspace declares `GPL-3.0-only`, and the repository includes a `LICENSE` file. That matters when a distributor copies, modifies, links, or redistributes tuigreet. The GPL label and source availability should be reviewed against the distribution method, but this article does not provide legal advice.

There is also a packaging detail worth checking before building. The workspace `Cargo.toml` identifies version `0.11.0`, while the release list includes `0.11.1`. The README does not explain that difference. Operators should confirm which tag or commit they intend to package and avoid assuming that the workspace version field alone identifies the newest published binary.

Editorial conclusion

Linux administrators using greetd should consider tuigreet when they want a configurable terminal greeter for Wayland or Xorg and can maintain its Rust and greetd integration. Operators who require a graphical mouse-oriented login screen should first verify that a terminal interface fits their deployment. Before adoption, inspect the exact release artifact or source revision used, confirm the greetd command for the target distribution, and review PAM and power-command assumptions in the local configuration.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. tuigreet/tuigreet on GitHub