Updating

New releases happen when the patchset is rebased onto a new upstream niri release; each rebase gets a tag v<niri-version>.<patch-count> and release notes listing the patch series changelog. The releases page shows them all.

Arch Linux

One command, from anywhere inside the clone:

./update-niri-tablet.sh

It fetches the latest release tag, shows the changelog since your installed version, builds and installs the package, and re-checks the IgnorePkg = niri pin in /etc/pacman.conf. It also rebuilds EasySetup whenever the app's sources changed, so the GUI stays current alongside the package (a plain cargo build, no sudo), and keeps its launcher entry and icon installed. The script refreshes itself from origin/main at startup too, so fixes to the updater itself don't wait for the next release tag.

It also checks your config for nodes the new build rejects. After v26.04.20 it looks for the old tap-4/swipe-4-* gesture names in ~/.config/niri (config.kdl and its cfg/ fragments) and offers to rename them for you: one dated .bak backup per touched file, and the change is undone unless niri validate passes on the result. Declining is fine, but rename before your next login (by hand, or save once from EasySetup), or the session starts on niri's default config with an error notification. With --yes the updater only reports and never edits config files.

Useful flags:

• --check - report what would happen, without touching anything
• --force - rebuild even an up-to-date install
• --tag vX.Y.Z - pick a specific release
• --main - track the development branch instead of releases
• --yes / -y - skip prompts for non-interactive runs

The manual equivalent:

git pull
cd pkg
makepkg -si        # incremental: the shared target dir is reused

After any update, log out and back in: the running session keeps the old binary until then. Verify with niri --version and the niri validate check on Installation.

Two notes:

• update-niri-tablet.sh is the user-facing updater. update.sh and install.sh at the repo root are maintainer scripts; they rebase and regenerate the patch series against a dev clone of niri (Development).
• After a big Rust toolchain jump, deleting ~/.cache/niri-tablet-target is harmless: the next build is just a slow cold one again.

NixOS

Bump rev in the fetchFromGitHub block to the newest release tag. The hash changes with it; leave it empty once and Nix prints the right one. See Installation for the full snippet.

Why IgnorePkg matters

With the pin in place, pacman -Syu skips niri and your patched build stays installed. When a new upstream niri release comes out, don't let pacman replace the package: a new niri-tablet release follows each upstream release, and ./update-niri-tablet.sh moves you to it in one step.