SDDM: a display manager that ships theming as its main feature

Why QML changes what a display manager is

A display manager is a small program with an outsized role: it runs before your session, it is the only thing on screen when you log in, and it has to be correct about PAM, logind, and device permissions. SDDM's contribution is not a new approach to any of that. Its contribution is that the login screen is a QtQuick application, so it can be animated and laid out with the same tools a desktop application uses.

The README states the goal plainly: fast, simple and beautiful, using modern technologies like QtQuick so the designer has the ability to create smooth, animated user interfaces. The architectural consequence is stated just as plainly. SDDM puts no restrictions on the user interface design, it is completely up to the designer, and the project supplies a few callbacks for authentication and suspend.

That is an unusual position for a system component. Most display managers ship a fixed interface with configuration for colors and fonts. SDDM ships a host process and a theme protocol, and the protocol is deliberately small. If you are choosing a display manager because you want the login screen to look a certain way, this is the one where that is a supported activity rather than a patched fork.

A callback API and a set of premade components

The theming model rests on a handful of callbacks and a small component library. Authentication and suspend are the callbacks named in the README. The premade components include a textbox and a combo box, described as provided to ease theme creation.

The practical difference from a fixed-UI display manager is that a theme author is not styling widgets, they are writing an application. There is no constraint on layout, no fixed set of fields, and no requirement that the password box be where the project decided. The cost is that a theme can be wrong in ways the project cannot prevent, including themes that never call the authentication callback and leave you at a screen that looks like a login prompt but does nothing.

Several sample themes ship with the project and the README recommends them as starting points for new ones. The screenshots and videos linked from the README are all of the same theme family, which is a reasonable indication of what the project considers a complete result. The screenshots are fetched from a `master` path in the repository image URLs even though the default branch is now `develop`, which is a small sign of how long some of these links have been in place.

Three licenses in one repository

SDDM's licensing is split by file type, which is unusual and worth understanding before you build a theme or ship a derivative. Source code is GNU GPL version 2 or later, at your choosing. QML files are MIT licensed. Images are CC BY 3.0, and the tree contains a matching `LICENSE.CC-BY-3.0` file alongside the main `LICENSE`.

The practical effect is that the theme layer, which is where almost all of a login screen's design work happens, is permissively licensed. A theme can be written, shared, and put in a distribution without the copyleft obligations that apply to the C++ source. For a project that wants to attract theme authors, that split is the single most important structural decision in the repository.

GitHub reports the project license as GPL-2.0, which is accurate for the code and incomplete for the repository as a whole. Anyone packaging SDDM has to treat the QML and image assets separately from the binary, and anyone who has only read the metadata field will get that wrong.

Running the greeter as a system user

The installation section is short and the details in it are the ones that cause trouble. Qt 5.15.0 or later is required. The greeter runs as a system user named `sddm` whose home directory must be set to `/var/lib/sddm`. If PAM and systemd are available, the greeter goes through logind, which is what gives it access to DRM devices.

That conditional is doing a lot of work. On a distribution with PAM and systemd, SDDM gets device access through logind and you do not need to think about groups. On a distribution without them, you have to add the `sddm` user to the `video` group yourself, or you will hit errors relating to GL and DRM devices. The README does not give you the command for that case, which is the first thing to look up if you are on a non-systemd system.

A related permission problem shows up with user icons. SDDM reads the icon from `~/.face.icon` or from `FacesDir/username.face.icon`, and the `sddm` user needs read access to those files. The README's suggested fix uses ACLs, which is the right tool when other users must not be able to traverse your home directory:

setfacl -m u:sddm:x /home/username
setfacl -m u:sddm:r /home/username/.face.icon

The first line grants execute permission on the directory so the path can be traversed, and the second grants read on the icon alone. That is a narrower grant than making the home directory world readable, which is what you would get from a blanket chmod.

Choosing the virtual terminal, and the NVIDIA Prime fix

SDDM is assumed to start at the virtual terminal given by the CMake variable `SDDM_INITIAL_VT`, an integer defaulting to 1. If that terminal is not available, SDDM takes the next one. You override the variable when you want something other than tty1, for example if you have already given tty1 to something else.

The troubleshooting section's first entry is an NVIDIA Prime recipe, added to the bottom of the Xsetup script:

if [ -e /sbin/prime-offload ]; then
    echo running NVIDIA Prime setup /sbin/prime-offload, you will need to manually run /sbin/prime-switch to shut down
    /sbin/prime-offload
fi

The echo text is the useful part. It tells you that shutting the offload down afterwards is a manual step, which is the kind of thing that would otherwise be discovered by wondering why the GPU is busy after logging out.

The custom DPI entry is a configuration detail worth copying. For high resolution screens the README says to configure Xorg yourself rather than expecting the greeter to guess, and the way to do it is a `ServerArguments` line in the `X11` section of `/etc/sddm.conf`:

ServerArguments=-nolisten tcp -dpi 192

Note what that line does. It carries an Xorg argument through the display manager's configuration, not through an Xorg configuration file, and it pairs the DPI setting with `-nolisten tcp`. That pairing is the sort of thing that gets dropped when you edit the file by hand later and the greeter starts listening on TCP.

Release cadence and the default branch

Three releases are visible and the gaps between them are large. v0.19.0 shipped on 2020-11-03, v0.20.0 on 2023-06-23, and v0.21.0 on 2024-02-26. Each release announcement says the team is working toward SDDM 1.0.0 and asks for bug reports and pull requests on the GitHub tracker. The 0.19.0 announcement credits the Liri, KDE and LXQt projects, and notes that development is by volunteers.

So the honest read is that this is a project with a long release tail and continuous work between tags, not one that ships on a schedule. The last push was on 2026-08-19, and the default branch is `develop`, which is the branch most of that work lands on. Distributions shipping SDDM are therefore often carrying a version whose tag is years old with patches on top, and the `ChangeLog` in the tree is the file the release announcements point to.

The issue count is the other number a reader should weigh. The tracker shows 753 open issues, which for a component that every desktop user passes through twice a day is as much a statement about volunteer capacity as about the software. Wayland work is where it concentrates: v0.21.0's most visible change was not populating the keyboard layout list in the Wayland greeter, which is exactly the class of small difference that separates a X11 session from a Wayland one.

Editorial conclusion

SDDM makes sense when the login screen is something you want to design rather than configure, which is why KDE and LXQt ship it as a default. The QML theme interface means a designer can build almost anything, and the MIT licensing on QML files makes that easier to distribute than the GPL on the C++ source would. It makes less sense as a drop-in for a system where you only need the login screen to work, because every visual decision then belongs to whichever theme happens to be installed. Before switching, check whether the themes you actually want exist for your display server, since the repository has accumulated a large issue tracker, 753 open at last count, and Wayland sessions are where that backlog concentrates.

Frequently asked questions

Official sources

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