hypr-dynamic-cursors: a Hyprland plugin that tilts and stretches your pointer

A cursor treated as an object being dragged

The core idea is physical. The plugin simulates how your cursor would behave if it were an actual object being dragged across the screen, which means the cursor can change based on how it is used, tilting in the direction you are moving or rotating straight out towards the movement.

That framing explains the three simulation modes, which are the whole feature set. In rotate mode the cursor is simulated as a stick which is dragged across the screen on one end, so it rotates towards the movement direction. In tilt mode the cursor is tilted based on the x direction and the speed it is moving at. In stretch mode the cursor stretches and squishes in the direction of movement based on the speed, recreating the stretching done to moving objects in comic animations.

The author's own assessment of the modes is worth keeping in view. The tilt mode was intended to simulate how an object would be affected by air drag, but implemented is only a rough approximation. The stretch mode is described with a bluntness that is funnier than the feature itself.

This is a joke project, and the documentation says so. The plugin was created more or less as a joke, mainly to see how using a rotating or tilted cursor feels. That framing is useful for an adopter, because it sets the expectation for how much support you will get.

The inspiration is KDE, and the shake to find feature is described as akin to how KDE Plasma and macOS do it.

Shake to find is the feature worth taking seriously

If you take one part of this plugin seriously, take this one.

Shake to find enlarges the cursor when it is shaken, which makes it easier to find. The feature is also supported in KDE Plasma and macOS, so it is an established convention rather than an invention here. It can be enabled separately or together with one of the simulation modes, and it is enabled by default.

That separation is the important design point. If you only want shake to find and no unusual cursor behaviour, you disable the modes above with the mode `none`. So the plugin is not an all or nothing package, and the one feature with a clear practical use can be taken on its own.

The magnification can also be triggered as a dispatcher instead of on shake, which turns the cursor enlargement into something you can bind to a key or a gesture rather than something tied to physical mouse movement.

The project also supports hyprcursor for high resolution cursor images, so a magnified cursor does not turn into a blurry blob when the shake fires. That combination of magnified shape and high resolution images is listed as a completed state item in the project.

Shake to find is described in the documentation as the only useful feature, and it was implemented more or less as an afterthought.

Both software and hardware cursor paths are handled

A cursor plugin has an awkward fork in the road: some compositors draw the pointer themselves, and some let the hardware do it. Getting this wrong means the effect never appears.

The project checklist records both paths as done. Software cursor rendering and hardware cursor rendering are both marked complete, and so is the stick simulation, the air drag simulation, per-shape length and starting angle where possible, the cursor shake to find, an overdue refactoring, and the hyprcursor magnified shape.

One item is explicitly not done: pendulum simulation, which sits unchecked in the list, alongside a note that there are multiple things which may or may not be implemented in the future.

The per-shape length and starting angle entry is the detail that matters most for anyone who cares about the effect. It means the length of the virtual stick and the angle it rests at can be defined per cursor shape, so a large arrow and a small crosshair do not behave identically. Whether that is configurable through the settings interface or only in source is not described in the documentation available here.

The project is C++, built as a shared object plugin, and the build output is named after the plugin.

Installing with hyprpm, and the x86_64 restriction

Official installation goes through hyprpm, and the command is short:

hyprpm add https://github.com/virtcode/hypr-dynamic-cursors
hyprpm enable dynamic-cursors

Two constraints come with it and both are hard. The plugin is only supported on x86_64 architectures, and the project helpfully notes that if you do not know what that means you are probably fine. And supported Hyprland versions are v0.41.2 and upwards, while the latest commit on the main branch generally tries to target Hyprland's main branch, the -git build.

That last point is where people get stuck. A release Hyprland and a git Hyprland are different plugin ABIs in practice, and the documentation is explicit elsewhere that a mismatched or unsupported Hyprland release will fail to build or load the plugin if you update.

hyprpm handles the plugin and its loading on startup, and the project documentation points at the hyprpm section of the Hyprland wiki for the details of keeping it loaded.

The architecture restriction is the one to check first, before anything else, because it is the only one you cannot work around by changing configuration.

NixOS and Gentoo get first class packaging

hyprpm is distribution agnostic, and the documentation says plainly that distribution specific mechanisms usually offer a better and more stable user experience, which is why two are documented in detail.

NixOS has two routes. There is a package in nixpkgs, and the recommendation is to use that one if you are on a release version of Hyprland, with the caveat that the package is maintained by other people and might not be up to date. It goes into the plugins list of a home-manager configuration:

wayland.windowManager.hyprland = {
    enable = true;
    plugins = [ pkgs.hyprlandPlugins.hypr-dynamic-cursors ];
};

If you daily drive the development version of Hyprland, the flake included with the plugin is the recommended route instead, since it is built against the same development branch. The flake input sets hypr-dynamic-cursors to follow the hyprland input, with a comment saying that is to make sure the plugin is built for the correct version of Hyprland:

hypr-dynamic-cursors = {
    url = "github:VirtCode/hypr-dynamic-cursors";
    inputs.hyprland.follows = "hyprland"; # to make sure that the plugin is built for the correct version of hyprland
};

Gentoo is packaged in the Hyproverlay portage overlay, which contains the entire Hy-* ecosystem. Hyprland plugins in that ecosystem are usually packaged as -9999 live ebuilds, so unmasking with ** is required, which means adding an entry to a package.accept_keywords list:

hyprland-plugin/dynamic-cursors **

after which the plugin is installed with emerge --ask hyprland-plugin/dynamic-cursors.

Building from source needs Hyprland headers and a C++26 compiler

The Makefile shows the build contract, and it is stricter than it looks.

The compiler flags are the interesting part. The build uses -Wall, -fPIC and -std=c++26, and it asks pkg-config for the cflags of hyprland, pixman-1 and libdrm. That is three development packages you need installed, and the hyprland one means you need the Hyprland source tree available locally, because the pkg-config output is rewritten by a sed expression to add both the hyprland root and its src directory to the include path.

The output is a shared object named after the plugin, dynamic-cursors.so, linked with -shared. When the compiler is g++, the flags add --no-gnu-unique, which is the usual workaround for a class of symbol visibility problems with the Hyprland plugin ABI.

There are convenience targets for the local workflow. make load builds the plugin and loads it into the running Hyprland with hyprctl plugin load, and make unload removes it with hyprctl plugin unload. A format target runs clang-format over the headers and sources, and there is a .clang-format file in the repository, so the formatting is enforced by configuration rather than by convention.

The plugin name and the repository metadata file are the other two pieces: the plugin is called dynamic-cursors, and hyprpm.toml in the tree is what hyprpm reads to know what it is enabling.

Where this plugin is the wrong choice

There are several, and they are stated in the project itself.

The x86_64 restriction rules out ARM machines outright, which covers a growing share of Linux hardware. There is no workaround in the documentation beyond checking your architecture.

The support commitment is the other one, and it is not ambiguous. The author says the plugin was created more or less as a joke, that the main goal was to see how using a rotating or tilted cursor was like, that no future updates and bugfixes are guaranteed, and that the only useful feature, shake to find, was implemented more or less as an afterthought. There are no GitHub releases either, so there is no version to pin and no changelog to read.

The repository is not archived and the last push was on 2026-10-05, so the code is not frozen. It is simply a project whose author has stated that they will not maintain it.

If you need a cursor effect that you can rely on, or one that is configured through a supported settings panel rather than through source and environment variables, this is the wrong tool. The plugin is a C++ shared object that needs the Hyprland headers at build time and a matching Hyprland version at load time.

The one case where this is clearly the right choice is a user who wants shake to find, on x86_64, and accepts that the feature may break when they update Hyprland.

Editorial conclusion

Adopt hypr-dynamic-cursors if you run Hyprland on x86_64 and want a pointer that behaves like a dragged object, or if you mainly want shake to find, which the author calls the only genuinely useful feature. Skip it if you are on a non x86_64 machine, since the plugin is only supported there, or if you need a maintained effect, because the author states no future updates and bugfixes are guaranteed. Verify first that your Hyprland is v0.41.2 or newer, that you build against a matching Hyprland version, and that you set the mode to none if you only want the magnification.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. VirtCode/hypr-dynamic-cursors on GitHub