A scrollable-tiling Wayland compositor.
Getting Started | Configuration | Setup Showcase
Important
This is biri, a custom fork of niri.
It tracks upstream niri and adds a set of extra features on top: GPU post-process shaders (global, per-region, and per-window), a consolidated multi-monitor carousel overview, dynamic overview zoom presets, isolated "signage" outputs, and runtime touchpad/DWT toggles. See Fork Features below for the full list.
Everything documented for upstream niri still applies. Bugs you hit here should be reported to this fork, not to upstream niri.
Warning
Branch rename (2026-09-03). The fork's working branch is now main (formerly barrulus-custom), and the pristine upstream mirror is now upstream (formerly main).
Open pull requests against main. If you track this repo, update flake inputs, package scripts, and clones from barrulus/biri/barrulus-custom to barrulus/biri/main. The old barrulus-custom branch has been removed.
biri-demo-480p.mp4
These exist only in biri, not in upstream niri. Unless noted, each is off by default and inert when unconfigured.
A GLSL fragment shader pipeline layered on top of niri's rendering, in three scopes that can all be active at once:
global-shader— a full-screen post-process pass over the whole composited output: colour grading, CRT scanlines, night-light tints, motion-blur trails, and so on. TTY/DRM backend only.region-shader— the same shader contract scoped to a fixed screen rectangle, optionally pinned to one output. Repeatable.shader {}in awindow-rule— a shader applied to a single window's content, with borders and shadows rendered outside it. Animated, and only redrawn while the window is actually visible.
Supporting machinery:
-
Named
window-shaderspresets driven by thetoggle-window-shaderandcycle-window-shaderbinds: flip the focused window's shader off/on, or rotate it through your presets at runtime — no config editing or reload needed. -
Two API flavours: a native
nirimode and ahyprlandmode that accepts most Hyprlandscreen_shaderfiles with light edits. -
Multi-pass chains via repeatable
pass {}blocks, where each pass reads the previous pass's output. -
A previous-frame feedback buffer (
niri_prev/tex2D_prev) plus a dedicatedglobal_bufferpass for trails and accumulation effects. -
Redraw scheduling (
redraw "auto" | "on-damage" | "continuous") so a static shader doesn't force a continuous redraw loop, andcursor-radiusto reshade only a box around the cursor and keep the rest of the output scanout-eligible. -
shader-animation-max-fpsto cap shader-driven redraws independently of the output refresh rate. -
shaders-in-capture(top-level flag) to opt shader output into portal screencasts and screencopy; by default shaders stay a local display effect and never leak into shared or recorded content. -
Hot-reload on config reload; a shader that fails to compile logs a warning and leaves the screen rendering normally.
Note the cost: an active global shader disables direct scanout and redraws the whole output every frame. The shader documentation covers this in detail.
overview { consolidated-carousel { ... } } replaces the per-monitor overview on multi-monitor setups with a single-screen, cover-flow style browser. Zooming one output's overview out past reveal-zoom continuously reveals the other outputs as perspective panels receding to the sides, fully assembled by assembled-zoom — no snapping or thresholds.
Rotate the ring with the normal focus-column-left/right binds, Shift+scroll, or by clicking a side panel; any of these work at any zoom level, pulling out to show the ring and then returning to where you were. Rotating a sibling output into the centre gives you its live, interactive workspace strip ("the lens"), and clicking a window there — or pressing Enter — jumps focus straight to that window on its real output.
See Configuration: Miscellaneous.
overview { zoom-presets 0.5 0.25 0.1 } plus three new actions — overview-zoom-in, overview-zoom-out, and overview-zoom-cycle — let you move between zoom levels while in the Overview. The zoom actions also open and close the overview at the ends of the range, so two binds (typically Mod+scroll) cover the whole interaction. Transitions are animated via the new overview-zoom animation.
An isolated flag on an output keeps compositor UI — the overview, the Alt-Tab switcher, the hotkey overlay, and the config error notification — off that screen, for projection, digital signage, shop-front visuals, or a clean capture feed. Windows and layer-shell surfaces still render normally. power-off-monitors skip-isolated=true leaves isolated outputs lit while the rest sleep on idle.
toggle-touchpad— enable/disable the touchpad without editing the config.toggle-dwt— same for disable-while-typing.
Both compose with the config settings (config and toggle must agree), reset on restart, and apply to newly hot-plugged touchpads.
Open niri pull requests merged here ahead of upstream, originally combined in niri-qol (now absorbed into this fork):
- Hidden workspaces (niri#2997) — a named workspace can be hidden: it keeps its windows but disappears from the workspace strip, the overview, and workspace switching until toggled back. Declare it hidden at startup with
workspace "name" { hidden true }, or change it at runtime with thetoggle-workspace-visibility,hide-workspaceandunhide-workspaceactions (binds orniri msg action; addfocus=trueto jump to the workspace as it appears). Hidden workspaces also stay out of the consolidated carousel's panels. - Sticky floating windows (niri#3302) — floating windows that follow you across all workspaces of their output. Set
open-sticky truein a window rule (impliesopen-floating), or toggle any floating window with thetoggle-window-stickybind. In the consolidated carousel, sticky windows show on every workspace panel, and clicking one in the lens focuses it. float-above-fullscreen(niri#4062) — a window rule that keeps a floating window visible on top when a fullscreen window occupies the workspace. Off by default.
workspace "scratch" {
hidden true
}
window-rule {
match app-id="firefox$" title="^Picture-in-Picture$"
open-sticky true
float-above-fullscreen true
}
binds {
Mod+H { toggle-workspace-visibility "scratch"; }
Mod+S { toggle-window-sticky; }
}If these land upstream, the upstream versions replace them here.
Windows are arranged in columns on an infinite strip going to the right. Opening a new window never causes existing windows to resize.
Every monitor has its own separate window strip. Windows can never "overflow" onto an adjacent monitor.
Workspaces are dynamic and arranged vertically. Every monitor has an independent set of workspaces, and there's always one empty workspace present all the way down.
The workspace arrangement is preserved across disconnecting and connecting monitors where it makes sense. When a monitor disconnects, its workspaces will move to another monitor, but upon reconnection they will move back to the original monitor.
- Built from the ground up for scrollable tiling
- Dynamic workspaces like in GNOME
- An Overview that zooms out workspaces and windows
- Built-in screenshot UI
- Monitor and window screencasting through xdg-desktop-portal-gnome
- You can block out sensitive windows from screencasts
- Dynamic cast target that can change what it shows on the go
- Touchpad and mouse gestures
- Group windows into tabs
- Configurable layout: gaps, borders, struts, window sizes
- Gradient borders with Oklab and Oklch support
- Background blur for windows and layer-shell surfaces
- Animations with support for custom shaders
- Live-reloading config
- Works with screen readers
demo.mp4
Also check out these videos that showcase a lot of the niri functionality:
- Niri Is My New Favorite Wayland Compositor by Brodie Robertson
- How Is niri This Good? Live Demo + Config by Nick Janetakis
Niri is stable for day-to-day use and does most things expected of a Wayland compositor. Many people are daily-driving niri, and are happy to help in our Matrix channel.
Give it a try! Follow the instructions on the Getting Started page. Grab a desktop shell like DankMaterialShell or Noctalia (or build a more traditional setup): niri by itself is not a complete desktop environment. Also check out awesome-niri, a list of niri-related links and projects.
Here are some points you may have questions about:
- Multi-monitor: yes, a core part of the design from the very start. Mixed DPI works.
- Fractional scaling: yes, plus all niri UI stays pixel-perfect.
- NVIDIA: seems to work fine.
- Floating windows: yes, starting from niri 25.01.
- Input devices: niri supports tablets, touchpads, and touchscreens. You can map the tablet to a specific monitor, or use OpenTabletDriver. We have touchpad gestures, but no touchscreen gestures yet.
- Wlr protocols: yes, we have most of the important ones like layer-shell, gamma-control, screencopy. You can check on wayland.app at the bottom of each protocol's page.
- Performance: while I run niri on beefy machines, I try to stay conscious of performance. I've seen someone use it fine on an Eee PC 900 from 2008, of all things.
- Xwayland: integrated via xwayland-satellite starting from niri 25.08.
niri: Making a Wayland compositor in Rust · December 2024
My talk from the 2024 Moscow RustCon about niri, and how I do randomized property testing and profiling, and measure input latency. The talk is in Russian, but I prepared full English subtitles that you can find in YouTube's subtitle language selector.
An interview with Ivan, the developer behind Niri · June 2025
An interview by a German tech podcast Das Triumvirat (in English). We talk about niri development and history, and my experience building and maintaining niri.
A tour of the niri scrolling-tiling Wayland compositor · July 2025
An LWN article with a nice overview and introduction to niri.
If you'd like to help with niri, there are plenty of both coding- and non-coding-related ways to do so. See CONTRIBUTING.md for an overview.
For the fork-specific features listed above, open issues and pull requests against this repository rather than upstream niri.
Niri is heavily inspired by PaperWM which implements scrollable tiling on top of GNOME Shell.
One of the reasons that prompted me to try writing my own compositor is being able to properly separate the monitors. Being a GNOME Shell extension, PaperWM has to work against Shell's global window coordinate space to prevent windows from overflowing.
Here are some other projects which implement a similar workflow:
- PaperWM: scrollable tiling on top of GNOME Shell.
- karousel: scrollable tiling on top of KDE.
- scroll and papersway: scrollable tiling on top of sway/i3.
- Hyprland has a built-in scrolling layout.
- Paneru and PaperWM.spoon: scrollable tiling on top of macOS.
Our main communication channel is a Matrix chat, feel free to join and ask a question: https://matrix.to/#/#niri:matrix.org
We also have a community Discord server: https://discord.gg/vT8Sfjy7sx