hyprlock: GPU-accelerated screen locking for Hyprland

hyprlock's role in a Hyprland session

hyprlock addresses a narrow but important piece of the Hyprland desktop: locking the display while preserving the visual and interactive conventions of that compositor. The README identifies it as Hyprland's screen-locking utility and emphasizes the `ext-session-lock` protocol. That protocol requirement is the clearest boundary around its intended audience. A user choosing a lock screen for Hyprland can reasonably expect hyprlock to fit that environment, while someone seeking an interchangeable locker for unrelated Wayland compositors would need compatibility information that the repository does not provide.

The project is primarily written in C++ and presents a screen locker rather than a complete desktop shell. Its documented feature set includes fractional-scale support, GPU-accelerated rendering, a blurred screenshot background, and native fingerprint support through libfprint's D-Bus interface. It also supports Hyprland-oriented presentation features such as gradient borders, blur, animations, and shadows. These details indicate that visual integration is part of the product, not merely an incidental background color.

The practical problem is therefore not generic desktop authentication. hyprlock is aimed at users who lock a Hyprland session and want the lock screen to fit that compositor's rendering model. The repository does not document standalone operation on other desktop environments, a browser-based unlock path, account administration, or audit logging, so those capabilities should not be assumed from its name.

Rendering, protocol, and authentication in hyprlock

The repository describes hyprlock as fully GPU accelerated. Its listed Mesa requirements, including `libgbm`, `libdrm`, and the OpenGL runtime, connect that claim to a graphics-oriented build path. The README also names Cairo, Pango, Wayland libraries, and related Hypr libraries as dependencies. This is enough to establish that hyprlock is assembled around Wayland rendering and graphical composition rather than a minimal terminal locking path.

hyprlock uses the `ext-session-lock` protocol. That matters because the documented locking mechanism is tied to a specific session-lock extension instead of being described as a generic screen dimmer. The README does not explain the lock state machine, compositor handshakes, or fallback behavior when a session lacks the protocol. Consequently, protocol support is a firm requirement to check rather than a compatibility feature that can be assumed across every Wayland compositor.

Resource loading is described as multithreaded. The mechanism is useful for acquiring resources needed by the lock screen while those resources include graphics and authentication integrations. The repository does not identify worker counts, scheduling rules, timeout behavior, or failure handling, so it would be misleading to promise a particular startup latency.

Fingerprint authentication is optional rather than universal. The README specifically connects it to libfprint through its D-Bus interface. PAM is also a required build dependency, which indicates an authentication stack beyond screenshots and visual effects. Neither the README nor the repository entries explain supported sensors, enrollment workflow, fallback passwords, or failure states. Users should verify those details in their own PAM environment before relying on fingerprint unlock.

Arch Linux installation for hyprlock

The README gives two Arch Linux package choices. The `hyprlock` package is described as a binary x86 tagged release, while `hyprlock-git` compiles from the latest source. This distinction matters to readers who need a packaged tagged build and readers who deliberately want source tracking. The repository does not give commands for removing either package or changing repositories.

Install the tagged Arch package with the documented command:

pacman -S hyprlock

The next line installs the development-oriented package variant, which the README describes as building from the latest source:

yay -S hyprlock-git

These are alternatives rather than two required commands. The README does not include a Hyprwm-specific command for assigning a lock shortcut, enabling fingerprint hardware, or starting a system service. Configuration is delegated to the linked Hyprland wiki, so users should look there for session integration and visual settings rather than inventing command-line flags.

For a source build, install the dependencies before configuring CMake. Development headers may be packaged separately under names ending in `-devel` or `-dev`. The exact package commands for those headers are distro-specific and are not supplied by the README.

Building hyprlock from the C++ repository

The source build requires `cairo`, `hyprgraphics`, `hyprlang`, `hyprutils`, `hyprwayland-scanner`, Mesa components, `pam`, `pango`, `sdbus-cpp` version 2.0.0 or newer, `wayland-client`, `wayland-protocols`, and `xkbcommon`. The dependency list mixes graphics, Wayland, configuration, authentication, and D-Bus libraries. A failed build may therefore reflect a missing development package rather than an error isolated to hyprlock's own source.

Configure a Release build in the repository's `build` directory:

cmake --no-warn-unused-cli -DCMAKE_BUILD_TYPE:STRING=Release -S . -B ./build

This command tells CMake to use the repository root as its source directory and create `build` for generated files. The repository does not document custom install prefixes or optional feature switches, so the supplied command should be used as written unless its configuration requirements are already understood.

Build the `hyprlock` target with the processor count detected by the documented shell expression:

cmake --build ./build --config Release --target hyprlock -j`nproc 2>/dev/null || getconf _NPROCESSORS_CONF`

After a successful build, install the configured artifacts with:

sudo cmake --install build

The README does not define what success output should look like or provide a smoke-test command. After installation, the first concrete checks are therefore whether the executable can locate its runtime libraries and whether the target Hyprland compositor supports `ext-session-lock`.

Configuration scope and visual trade-offs in hyprlock

The README sends users to `https://wiki.hyprland.org/Hypr-Ecosystem/hyprlock/` for documentation and configuration. No configuration file, syntax example, default configuration, or key binding appears in the repository README. This is a meaningful limitation for review: the feature list establishes what the project can represent, but not how each option is enabled or what values it accepts.

Several documented choices involve visible cost or operational assumptions. A blurred screenshot requires the lock screen to display session imagery, which raises questions about what appears on screen and when the background is generated. The repository README does not document screenshot timing, image storage, multi-monitor behavior, or whether image data leaves memory. Those are not grounds to claim a privacy defect, but they are specific details a user may need from the linked wiki before deployment.

Fractional-scale support and GPU rendering are relevant to mixed-DPI Hyprland setups, yet the README gives no scaling configuration example. Animations, shadows, gradients, and blur add presentation options, but the repository does not expose resource budgets or a way to disable GPU effects. The practical trade-off is clear: hyprlock offers a compositor-specific visual design surface, while the README does not provide enough configuration detail to predict its behavior across every display arrangement.

Fingerprint support introduces another boundary. libfprint must be available through D-Bus, and suitable hardware and PAM configuration are implied by the named integrations. The README does not state whether a password fallback is configured or how it behaves when the D-Bus service is absent.

hyprlock maintenance and licensing boundaries

The repository is not archived. Its last push was on 2026-08-11, which means it has seen a recent change relative to the documented release history, though recency alone does not establish API stability or operational reliability. Recent releases include v0.9.6 on 2026-07-18, v0.9.5 on 2026-04-18, and v0.9.4 on 2026-04-14.

The release sequence suggests that users may need to distinguish an installed package version from current source. The README offers a tagged `hyprlock` package and a source-building `hyprlock-git` package, but it gives no upgrade, downgrade, configuration migration, or rollback procedure. It also does not provide a compatibility matrix between hyprlock releases, Hyprland releases, protocol revisions, or libfprint versions. An upgrade review should therefore include the wiki and the installed environment rather than assuming configuration remains unchanged.

The project uses the BSD-3-Clause license. The exact obligations and notices are defined by the repository's `LICENSE` file. This review does not provide legal advice. Organizations should inspect that file and any separately installed PAM or fingerprint components before redistribution or modification. The presence of a permissive project license does not automatically settle the licensing of dependencies such as Mesa, PAM, Wayland libraries, or libfprint.

Choosing hyprlock against a simpler lock screen

hyprlock is built around Hyprland, Wayland, `ext-session-lock`, GPU graphics, and optional fingerprint integration. A simpler alternative would be a basic screen-lock mechanism whose documented deployment model does not depend on Hyprland-specific libraries, compositor visuals, or this project's multithreaded resource acquisition. The exact alternative application is not named in the repository, so no competitor-specific compatibility claim is justified.

The difference in approach is that hyprlock treats the lock screen as a GPU-rendered Hyprland component with effects and native fingerprint support. It is therefore a closer fit when visual integration, fractional scaling, and Hyprland conventions matter. A minimal locker can be the better choice when the user wants fewer rendering dependencies, does not need a blurred screenshot or compositor-specific effects, or operates outside an environment with the required Wayland protocol and build libraries.

hyprlock is the wrong tool when cross-desktop portability is the primary requirement or when PAM and libfprint integration cannot be established. It is also a poor fit for a user who expects the README alone to define configuration and upgrade behavior. The linked wiki is part of the practical adoption path because it is the repository's stated source for documentation and configuration.

Editorial conclusion

hyprlock fits Hyprland users who want a native-looking Wayland lock screen with GPU rendering and optional fingerprint support. It is a poor fit for users who need documented cross-desktop deployment or who cannot supply its protocol, rendering, PAM, and Wayland dependencies. Before adopting it, verify that the target system supports `ext-session-lock`, inspect `pam/` and `LICENSE`, and confirm that the wiki configuration matches the local Hyprland session.

Frequently asked questions

Official sources

1. hyprwm/hyprlock on GitHub
2. Issues
3. License: BSD-3-Clause
4. README
5. Releases