From: Tobias Heider Subject: Re: NEW: wayland/niri: A scrollable-tiling Wayland compositor To: Christoph Liebender Cc: ports@openbsd.org Date: Sun, 18 Jan 2026 19:55:21 +0100 On Sun, Jan 18, 2026 at 04:14:50PM +0100, Christoph Liebender wrote: > On 1/17/26 23:04, Tobias Heider wrote: > > On Tue, Dec 30, 2025 at 07:33:05PM +0100, Landry Breuil wrote: > > > Le Tue, Dec 30, 2025 at 03:21:56PM +0100, Tobias Heider a écrit : > > > > On Tue, Mar 04, 2025 at 05:13:07PM +0100, Tobias Heider wrote: > > > > > Hi, > > > > > > > > > > here is a new port for niri [1], a scrollable-tiling Wayland compositor > > > > > heavily inspired by the PaperWM extension for Gnome. > > > > > > > > > > This one is a little different than our existing wayland compositor ports > > > > > since it doesn't use wlroots but smithay [2] as its underlying compositor > > > > > library. > > > > > > > > > > Smithay is written in rust and pulls in quite a few dependencies, I had to > > > > > resort to some hacks to make it pick up the patched OpenBSD compatible > > > > > versions since most patches haven't found their way into an upstream release > > > > > yet. In the current version I fetch niri itself and all the patched > > > > > dependencies from my forked trees on github. I already got some of them > > > > > merged upstream so I'm optimistic that we can swtich over to an official > > > > > release in the near future. > > > > > > > > > > Looking forward to get some feedback. > > > > > > > > > > Some open questions: > > > > > Is there a better way to handle the rust dependencies? > > > > > Would it make sense for a large rust package such as smithay to be a separate > > > > > port? > > > > > I used upstream_version.date for our port version, is there a better solution? > > > > > > > > > > [1] https://github.com/YaLTeR/niri > > > > > [2] https://github.com/Smithay/smithay > > > > > > > > Updated it to 25.11 and thought I'd share it here for anyone interested. > > > > > > > > The garbled output after exiting niri seems to be fixed and I managed to > > > > upstream a bunch of patches in dependencies. The port is still fetching from > > > > my github though and is using drm-rs and smithay from my patched forks. > > > > > > > > One open issue is that xwayland-satellite will crash niri after a while, > > > > I am still trying to figure out why. > > > > > > heh, and i thought it was already imported... > > > > > > LIB_DEPENDS = devel/llvm/21 > > > > > > and you have the MODCARGO lines pointing at libLLVM.so commented out.. > > > are you sure that LIB_DEPENDS is needed ? if so im not sure that cant > > > lead to other issues in ports. > > > > > > note that startniri.sh should be updated now that we have proper support > > > for XDG_RUNTIME_DIR. > > > > > > with those fixed i'd be inclined to ok it so that you can maintain it in > > > tree, and itd be good to have non-wlroots implems to play with :) > > > > > > Landry > > > > I removed the llvm references, fixed startniri.sh and added a bit about the > > render-drm-device configuration in pkg/README. I was hoping I could fix it > > but that turned out to be harder than expected so documenting the quirk > > for now is probably the easier way to unblock this. > > > > ok? > > small nit in README: > > > Running > > ======= > > > > On OpenBSD, use the provided ${PREFIX}/bin/startniri.sh script to > > launch niri from an text VT (xenodm must be stopped. > ^ ^ > Also, FWIW, /usr/ports/infrastructure/bin/portcheck complains: > > 3 line(s) longer than 80 chars in Makefile > executable file: files/startniri.sh > hardcoded paths detected in pkg/README, consider using SUBST_VARS and > TRUEPREFIX/LOCALBASE/LOCALSTATEDIR > > Apart from that, it appears that niri has stopped working for me - when I > startniri.sh, there is some log output: Interesting. In previous versions I had SMITHAY_USE_LEGACY=1 set in startniri.sh. Does adding that back fix it for you? It doesn't seem to be necessary on my (amdgpu) desktop. > > niri:/usr/local/lib/libinput.so.0.1: undefined symbol > 'libevdev_event_type_from_name' > niri:/usr/local/lib/libinput.so.0.1: undefined symbol > 'libevdev_event_type_get_max' > niri:/usr/local/lib/libinput.so.0.1: undefined symbol > 'libevdev_event_code_from_name' > niri:/usr/local/lib/libinput.so.0.1: undefined symbol > 'libevdev_property_from_name' > 2026-01-18T15:03:08.886605Z INFO niri: starting version 25.11 (71174535441) > 2026-01-18T15:03:09.029946Z DEBUG niri_config: loaded config from > "/home/chris/.config/niri/config.kdl" > 2026-01-18T15:03:09.996876Z DEBUG niri::backend::tty: attempting to use > render node from config: "/dev/dri/renderD128" > 2026-01-18T15:03:09.997186Z INFO niri::backend::tty: using as the render > node: "/dev/dri/renderD128" > 2026-01-18T15:03:10.101200Z WARN niri::backend::tty: primary node is > missing, display-only devices may not work > 2026-01-18T15:03:10.101248Z INFO niri: listening on Wayland socket: > wayland-1 > 2026-01-18T15:03:10.101253Z INFO niri: IPC listening on: > /tmp/run/user/1000/niri.wayland-1.43573.sock > 2026-01-18T15:03:10.103725Z WARN niri::utils::xwayland::satellite: error > spawning xwayland-satellite at "xwayland-satellite", disabling integration: > No such file or directory (os error 2) > > ... and nothing happens. I can send an interrupt with ctrl+c to end the > process, which wasn't the case before, where starting niri would catch any > input to the terminal. > > Apart from following -current, I haven't really done anything to "actively > break" my niri install though. Possibly relevant parts in my config.kdl are: > > debug { > render-drm-device "/dev/dri/renderD128" > } > > environment { > LC_CTYPE "de_DE.UTF-8" > } > > spawn-sh-at-startup "swaybg -i ~/bg.jpg -m fill" > > I have attached the full config for the curious. > // This config is in the KDL format: https://kdl.dev > // "/-" comments out the following node. > // Check the wiki for a full description of the configuration: > // https://github.com/YaLTeR/niri/wiki/Configuration:-Overview > > // Input device configuration. > // Find the full list of options on the wiki: > // https://github.com/YaLTeR/niri/wiki/Configuration:-Input > debug { > render-drm-device "/dev/dri/renderD128" > } > > environment { > LC_CTYPE "de_DE.UTF-8" > } > > //spawn-at-startup "waybar" > spawn-sh-at-startup "swaybg -i ~/bg.jpg -m fill" > > input { > keyboard { > xkb { > // You can set rules, model, layout, variant and options. > // For more information, see xkeyboard-config(7). > > // For example: > layout "de" > // options "grp:win_space_toggle,compose:ralt,ctrl:nocaps" > } > } > > // Next sections include libinput settings. > // Omitting settings disables them, or leaves them at their default values. > touchpad { > // off > // tap > // dwt > // dwtp > // drag false > // drag-lock > natural-scroll > // accel-speed 0.2 > // accel-profile "flat" > // scroll-method "two-finger" > // disabled-on-external-mouse > } > > mouse { > // off > // natural-scroll > // accel-speed 0.2 > // accel-profile "flat" > // scroll-method "no-scroll" > } > > trackpoint { > // off > // natural-scroll > // accel-speed 0.2 > // accel-profile "flat" > // scroll-method "on-button-down" > // scroll-button 273 > // middle-emulation > } > > // Uncomment this to make the mouse warp to the center of newly focused windows. > // warp-mouse-to-focus > > // Focus windows and outputs automatically when moving the mouse into them. > // Setting max-scroll-amount="0%" makes it work only on windows already fully on screen. > // focus-follows-mouse max-scroll-amount="0%" > focus-follows-mouse > } > > // You can configure outputs by their name, which you can find > // by running `niri msg outputs` while inside a niri instance. > // The built-in laptop monitor is usually called "eDP-1". > // Find more information on the wiki: > // https://github.com/YaLTeR/niri/wiki/Configuration:-Outputs > // Remember to uncomment the node by removing "/-"! > /-output "eDP-1" { > // Uncomment this line to disable this output. > // off > > // Resolution and, optionally, refresh rate of the output. > // The format is "x" or "x@". > // If the refresh rate is omitted, niri will pick the highest refresh rate > // for the resolution. > // If the mode is omitted altogether or is invalid, niri will pick one automatically. > // Run `niri msg outputs` while inside a niri instance to list all outputs and their modes. > mode "1920x1080@120.030" > > // You can use integer or fractional scale, for example use 1.5 for 150% scale. > scale 2 > > // Transform allows to rotate the output counter-clockwise, valid values are: > // normal, 90, 180, 270, flipped, flipped-90, flipped-180 and flipped-270. > transform "normal" > > // Position of the output in the global coordinate space. > // This affects directional monitor actions like "focus-monitor-left", and cursor movement. > // The cursor can only move between directly adjacent outputs. > // Output scale and rotation has to be taken into account for positioning: > // outputs are sized in logical, or scaled, pixels. > // For example, a 3840×2160 output with scale 2.0 will have a logical size of 1920×1080, > // so to put another output directly adjacent to it on the right, set its x to 1920. > // If the position is unset or results in an overlap, the output is instead placed > // automatically. > position x=1280 y=0 > } > > // Settings that influence how windows are positioned and sized. > // Find more information on the wiki: > // https://github.com/YaLTeR/niri/wiki/Configuration:-Layout > layout { > // Set gaps around windows in logical pixels. > gaps 12 > > // When to center a column when changing focus, options are: > // - "never", default behavior, focusing an off-screen column will keep at the left > // or right edge of the screen. > // - "always", the focused column will always be centered. > // - "on-overflow", focusing a column will center it if it doesn't fit > // together with the previously focused column. > center-focused-column "never" > > // You can customize the widths that "switch-preset-column-width" (Mod+R) toggles between. > preset-column-widths { > // Proportion sets the width as a fraction of the output width, taking gaps into account. > // For example, you can perfectly fit four windows sized "proportion 0.25" on an output. > // The default preset widths are 1/3, 1/2 and 2/3 of the output. > proportion 0.33333 > proportion 0.5 > proportion 0.66667 > > // Fixed sets the width in logical pixels exactly. > // fixed 1920 > } > > // You can also customize the heights that "switch-preset-window-height" (Mod+Shift+R) toggles between. > // preset-window-heights { } > > // You can change the default width of the new windows. > default-column-width { proportion 0.5; } > // If you leave the brackets empty, the windows themselves will decide their initial width. > // default-column-width {} > > // By default focus ring and border are rendered as a solid background rectangle > // behind windows. That is, they will show up through semitransparent windows. > // This is because windows using client-side decorations can have an arbitrary shape. > // > // If you don't like that, you should uncomment `prefer-no-csd` below. > // Niri will draw focus ring and border *around* windows that agree to omit their > // client-side decorations. > // > // Alternatively, you can override it with a window rule called > // `draw-border-with-background`. > > // You can change how the focus ring looks. > focus-ring { > // Uncomment this line to disable the focus ring. > // off > > // How many logical pixels the ring extends out from the windows. > width 2 > > // Colors can be set in a variety of ways: > // - CSS named colors: "red" > // - RGB hex: "#rgb", "#rgba", "#rrggbb", "#rrggbbaa" > // - CSS-like notation: "rgb(255, 127, 0)", rgba(), hsl() and a few others. > > // Color of the ring on the active monitor. > active-color "#7fc8ff" > > // Color of the ring on inactive monitors. > inactive-color "#505050" > > // You can also use gradients. They take precedence over solid colors. > // Gradients are rendered the same as CSS linear-gradient(angle, from, to). > // The angle is the same as in linear-gradient, and is optional, > // defaulting to 180 (top-to-bottom gradient). > // You can use any CSS linear-gradient tool on the web to set these up. > // Changing the color space is also supported, check the wiki for more info. > // > // active-gradient from="#80c8ff" to="#bbddff" angle=45 > > // You can also color the gradient relative to the entire view > // of the workspace, rather than relative to just the window itself. > // To do that, set relative-to="workspace-view". > // > // inactive-gradient from="#505050" to="#808080" angle=45 relative-to="workspace-view" > } > > // You can also add a border. It's similar to the focus ring, but always visible. > border { > // The settings are the same as for the focus ring. > // If you enable the border, you probably want to disable the focus ring. > off > > width 4 > active-color "#ffc87f" > inactive-color "#505050" > > // active-gradient from="#ffbb66" to="#ffc880" angle=45 relative-to="workspace-view" > // inactive-gradient from="#505050" to="#808080" angle=45 relative-to="workspace-view" > } > > // You can enable drop shadows for windows. > shadow { > // Uncomment the next line to enable shadows. > on > > // By default, the shadow draws only around its window, and not behind it. > // Uncomment this setting to make the shadow draw behind its window. > // > // Note that niri has no way of knowing about the CSD window corner > // radius. It has to assume that windows have square corners, leading to > // shadow artifacts inside the CSD rounded corners. This setting fixes > // those artifacts. > // > // However, instead you may want to set prefer-no-csd and/or > // geometry-corner-radius. Then, niri will know the corner radius and > // draw the shadow correctly, without having to draw it behind the > // window. These will also remove client-side shadows if the window > // draws any. > // > // draw-behind-window true > > // You can change how shadows look. The values below are in logical > // pixels and match the CSS box-shadow properties. > > // Softness controls the shadow blur radius. > softness 30 > > // Spread expands the shadow. > spread 5 > > // Offset moves the shadow relative to the window. > offset x=0 y=5 > > // You can also change the shadow color and opacity. > color "#0007" > } > > // Struts shrink the area occupied by windows, similarly to layer-shell panels. > // You can think of them as a kind of outer gaps. They are set in logical pixels. > // Left and right struts will cause the next window to the side to always be visible. > // Top and bottom struts will simply add outer gaps in addition to the area occupied by > // layer-shell panels and regular gaps. > struts { > // left 64 > // right 64 > // top 64 > // bottom 64 > } > } > > // Uncomment this line to ask the clients to omit their client-side decorations if possible. > // If the client will specifically ask for CSD, the request will be honored. > // Additionally, clients will be informed that they are tiled, removing some client-side rounded corners. > // This option will also fix border/focus ring drawing behind some semitransparent windows. > // After enabling or disabling this, you need to restart the apps for this to take effect. > prefer-no-csd > > // You can change the path where screenshots are saved. > // A ~ at the front will be expanded to the home directory. > // The path is formatted with strftime(3) to give you the screenshot date and time. > screenshot-path "~/Pictures/Screenshots/Screenshot from %Y-%m-%d %H-%M-%S.png" > > // You can also set this to null to disable saving screenshots to disk. > // screenshot-path null > > // Animation settings. > // The wiki explains how to configure individual animations: > // https://github.com/YaLTeR/niri/wiki/Configuration:-Animations > animations { > // Uncomment to turn off all animations. > // off > > // Slow down all animations by this factor. Values below 1 speed them up instead. > // slowdown 3.0 > } > > // Window rules let you adjust behavior for individual windows. > // Find more information on the wiki: > // https://github.com/YaLTeR/niri/wiki/Configuration:-Window-Rules > > // Work around WezTerm's initial configure bug > // by setting an empty default-column-width. > window-rule { > // This regular expression is intentionally made as specific as possible, > // since this is the default config, and we want no false positives. > // You can get away with just app-id="wezterm" if you want. > match app-id=r#"^org\.wezfurlong\.wezterm$"# > default-column-width {} > } > > // Open the Firefox picture-in-picture player as floating by default. > window-rule { > // This app-id regular expression will work for both: > // - host Firefox (app-id is "firefox") > // - Flatpak Firefox (app-id is "org.mozilla.firefox") > match app-id=r#"firefox$"# title="^Picture-in-Picture$" > open-floating true > } > > // Example: block out two password managers from screen capture. > // (This example rule is commented out with a "/-" in front.) > /-window-rule { > match app-id=r#"^org\.keepassxc\.KeePassXC$"# > match app-id=r#"^org\.gnome\.World\.Secrets$"# > > block-out-from "screen-capture" > > // Use this instead if you want them visible on third-party screenshot tools. > // block-out-from "screencast" > } > > // Example: enable rounded corners for all windows. > // (This example rule is commented out with a "/-" in front.) > /-window-rule { > geometry-corner-radius 12 > clip-to-geometry true > } > > binds { > // Keys consist of modifiers separated by + signs, followed by an XKB key name > // in the end. To find an XKB name for a particular key, you may use a program > // like wev. > // > // "Mod" is a special modifier equal to Super when running on a TTY, and to Alt > // when running as a winit window. > // > // Most actions that you can bind here can also be invoked programmatically with > // `niri msg action do-something`. > > // Mod-Shift-/, which is usually the same as Mod-?, > // shows a list of important hotkeys. > Mod+Shift+Slash { show-hotkey-overlay; } > > // Suggested binds for running programs: terminal, app launcher, screen locker. > Mod+Return { spawn "foot"; } > Mod+Space { spawn "wofi" "--show" "drun"; } > Super+Alt+L { spawn "swaylock"; } > > // You can also use a shell. Do this if you need pipes, multiple commands, etc. > // Note: the entire command goes as a single argument in the end. > // Mod+T { spawn "bash" "-c" "notify-send hello && exec alacritty"; } > > // Example volume keys mappings for PipeWire & WirePlumber. > // The allow-when-locked=true property makes them work even when the session is locked. > XF86AudioRaiseVolume allow-when-locked=true { spawn "wpctl" "set-volume" "@DEFAULT_AUDIO_SINK@" "0.1+"; } > XF86AudioLowerVolume allow-when-locked=true { spawn "wpctl" "set-volume" "@DEFAULT_AUDIO_SINK@" "0.1-"; } > XF86AudioMute allow-when-locked=true { spawn "wpctl" "set-mute" "@DEFAULT_AUDIO_SINK@" "toggle"; } > XF86AudioMicMute allow-when-locked=true { spawn "wpctl" "set-mute" "@DEFAULT_AUDIO_SOURCE@" "toggle"; } > > Mod+Q { close-window; } > > Mod+Left { focus-column-left; } > Mod+Down { focus-window-down; } > Mod+Up { focus-window-up; } > Mod+Right { focus-column-right; } > Mod+H { focus-column-left; } > Mod+J { focus-window-down; } > Mod+K { focus-window-up; } > Mod+L { focus-column-right; } > > Mod+Ctrl+Left { move-column-left; } > Mod+Ctrl+Down { move-window-down; } > Mod+Ctrl+Up { move-window-up; } > Mod+Ctrl+Right { move-column-right; } > Mod+Ctrl+H { move-column-left; } > Mod+Ctrl+J { move-window-down; } > Mod+Ctrl+K { move-window-up; } > Mod+Ctrl+L { move-column-right; } > > // Alternative commands that move across workspaces when reaching > // the first or last window in a column. > // Mod+J { focus-window-or-workspace-down; } > // Mod+K { focus-window-or-workspace-up; } > // Mod+Ctrl+J { move-window-down-or-to-workspace-down; } > // Mod+Ctrl+K { move-window-up-or-to-workspace-up; } > > Mod+Home { focus-column-first; } > Mod+End { focus-column-last; } > Mod+Ctrl+Home { move-column-to-first; } > Mod+Ctrl+End { move-column-to-last; } > > Mod+Shift+Left { focus-monitor-left; } > Mod+Shift+Down { focus-monitor-down; } > Mod+Shift+Up { focus-monitor-up; } > Mod+Shift+Right { focus-monitor-right; } > Mod+Shift+H { focus-monitor-left; } > Mod+Shift+J { focus-monitor-down; } > Mod+Shift+K { focus-monitor-up; } > Mod+Shift+L { focus-monitor-right; } > > Mod+Shift+Ctrl+Left { move-column-to-monitor-left; } > Mod+Shift+Ctrl+Down { move-column-to-monitor-down; } > Mod+Shift+Ctrl+Up { move-column-to-monitor-up; } > Mod+Shift+Ctrl+Right { move-column-to-monitor-right; } > Mod+Shift+Ctrl+H { move-column-to-monitor-left; } > Mod+Shift+Ctrl+J { move-column-to-monitor-down; } > Mod+Shift+Ctrl+K { move-column-to-monitor-up; } > Mod+Shift+Ctrl+L { move-column-to-monitor-right; } > > // Alternatively, there are commands to move just a single window: > // Mod+Shift+Ctrl+Left { move-window-to-monitor-left; } > // ... > > // And you can also move a whole workspace to another monitor: > // Mod+Shift+Ctrl+Left { move-workspace-to-monitor-left; } > // ... > > Mod+Page_Down { focus-workspace-down; } > Mod+Page_Up { focus-workspace-up; } > Mod+U { focus-workspace-down; } > Mod+I { focus-workspace-up; } > Mod+Ctrl+Page_Down { move-column-to-workspace-down; } > Mod+Ctrl+Page_Up { move-column-to-workspace-up; } > Mod+Ctrl+U { move-column-to-workspace-down; } > Mod+Ctrl+I { move-column-to-workspace-up; } > > // Alternatively, there are commands to move just a single window: > // Mod+Ctrl+Page_Down { move-window-to-workspace-down; } > // ... > > Mod+Shift+Page_Down { move-workspace-down; } > Mod+Shift+Page_Up { move-workspace-up; } > Mod+Shift+U { move-workspace-down; } > Mod+Shift+I { move-workspace-up; } > > // You can bind mouse wheel scroll ticks using the following syntax. > // These binds will change direction based on the natural-scroll setting. > // > // To avoid scrolling through workspaces really fast, you can use > // the cooldown-ms property. The bind will be rate-limited to this value. > // You can set a cooldown on any bind, but it's most useful for the wheel. > Mod+WheelScrollDown cooldown-ms=150 { focus-workspace-down; } > Mod+WheelScrollUp cooldown-ms=150 { focus-workspace-up; } > Mod+Ctrl+WheelScrollDown cooldown-ms=150 { move-column-to-workspace-down; } > Mod+Ctrl+WheelScrollUp cooldown-ms=150 { move-column-to-workspace-up; } > > Mod+WheelScrollRight { focus-column-right; } > Mod+WheelScrollLeft { focus-column-left; } > Mod+Ctrl+WheelScrollRight { move-column-right; } > Mod+Ctrl+WheelScrollLeft { move-column-left; } > > // Usually scrolling up and down with Shift in applications results in > // horizontal scrolling; these binds replicate that. > Mod+Shift+WheelScrollDown { focus-column-right; } > Mod+Shift+WheelScrollUp { focus-column-left; } > Mod+Ctrl+Shift+WheelScrollDown { move-column-right; } > Mod+Ctrl+Shift+WheelScrollUp { move-column-left; } > > // Similarly, you can bind touchpad scroll "ticks". > // Touchpad scrolling is continuous, so for these binds it is split into > // discrete intervals. > // These binds are also affected by touchpad's natural-scroll, so these > // example binds are "inverted", since we have natural-scroll enabled for > // touchpads by default. > // Mod+TouchpadScrollDown { spawn "wpctl" "set-volume" "@DEFAULT_AUDIO_SINK@" "0.02+"; } > // Mod+TouchpadScrollUp { spawn "wpctl" "set-volume" "@DEFAULT_AUDIO_SINK@" "0.02-"; } > > // You can refer to workspaces by index. However, keep in mind that > // niri is a dynamic workspace system, so these commands are kind of > // "best effort". Trying to refer to a workspace index bigger than > // the current workspace count will instead refer to the bottommost > // (empty) workspace. > // > // For example, with 2 workspaces + 1 empty, indices 3, 4, 5 and so on > // will all refer to the 3rd workspace. > Mod+1 { focus-workspace 1; } > Mod+2 { focus-workspace 2; } > Mod+3 { focus-workspace 3; } > Mod+4 { focus-workspace 4; } > Mod+5 { focus-workspace 5; } > Mod+6 { focus-workspace 6; } > Mod+7 { focus-workspace 7; } > Mod+8 { focus-workspace 8; } > Mod+9 { focus-workspace 9; } > Mod+Ctrl+1 { move-column-to-workspace 1; } > Mod+Ctrl+2 { move-column-to-workspace 2; } > Mod+Ctrl+3 { move-column-to-workspace 3; } > Mod+Ctrl+4 { move-column-to-workspace 4; } > Mod+Ctrl+5 { move-column-to-workspace 5; } > Mod+Ctrl+6 { move-column-to-workspace 6; } > Mod+Ctrl+7 { move-column-to-workspace 7; } > Mod+Ctrl+8 { move-column-to-workspace 8; } > Mod+Ctrl+9 { move-column-to-workspace 9; } > > // Alternatively, there are commands to move just a single window: > // Mod+Ctrl+1 { move-window-to-workspace 1; } > > // Switches focus between the current and the previous workspace. > // Mod+Tab { focus-workspace-previous; } > > // The following binds move the focused window in and out of a column. > // If the window is alone, they will consume it into the nearby column to the side. > // If the window is already in a column, they will expel it out. > Mod+BracketLeft { consume-or-expel-window-left; } > Mod+BracketRight { consume-or-expel-window-right; } > > // Consume one window from the right to the bottom of the focused column. > Mod+Comma { consume-window-into-column; } > // Expel the bottom window from the focused column to the right. > Mod+Period { expel-window-from-column; } > > Mod+R { switch-preset-column-width; } > Mod+Shift+R { switch-preset-window-height; } > Mod+Ctrl+R { reset-window-height; } > Mod+F { maximize-column; } > Mod+Shift+F { fullscreen-window; } > > // Expand the focused column to space not taken up by other fully visible columns. > // Makes the column "fill the rest of the space". > Mod+Ctrl+F { expand-column-to-available-width; } > > Mod+C { center-column; } > > // Finer width adjustments. > // This command can also: > // * set width in pixels: "1000" > // * adjust width in pixels: "-5" or "+5" > // * set width as a percentage of screen width: "25%" > // * adjust width as a percentage of screen width: "-10%" or "+10%" > // Pixel sizes use logical, or scaled, pixels. I.e. on an output with scale 2.0, > // set-column-width "100" will make the column occupy 200 physical screen pixels. > Mod+Minus { set-column-width "-10%"; } > Mod+Equal { set-column-width "+10%"; } > > // Finer height adjustments when in column with other windows. > Mod+Shift+Minus { set-window-height "-10%"; } > Mod+Shift+Equal { set-window-height "+10%"; } > > // Move the focused window between the floating and the tiling layout. > Mod+V { toggle-window-floating; } > Mod+Shift+V { switch-focus-between-floating-and-tiling; } > > // Toggle tabbed column display mode. > // Windows in this column will appear as vertical tabs, > // rather than stacked on top of each other. > Mod+W { toggle-column-tabbed-display; } > > // Actions to switch layouts. > // Note: if you uncomment these, make sure you do NOT have > // a matching layout switch hotkey configured in xkb options above. > // Having both at once on the same hotkey will break the switching, > // since it will switch twice upon pressing the hotkey (once by xkb, once by niri). > // Mod+Space { switch-layout "next"; } > // Mod+Shift+Space { switch-layout "prev"; } > > Print { screenshot; } > Ctrl+Print { screenshot-screen; } > Alt+Print { screenshot-window; } > > // Applications such as remote-desktop clients and software KVM switches may > // request that niri stops processing the keyboard shortcuts defined here > // so they may, for example, forward the key presses as-is to a remote machine. > // It's a good idea to bind an escape hatch to toggle the inhibitor, > // so a buggy application can't hold your session hostage. > // > // The allow-inhibiting=false property can be applied to other binds as well, > // which ensures niri always processes them, even when an inhibitor is active. > Mod+Escape allow-inhibiting=false { toggle-keyboard-shortcuts-inhibit; } > > // The quit action will show a confirmation dialog to avoid accidental exits. > Mod+Shift+E { quit; } > Ctrl+Alt+Delete { quit; } > > // Powers off the monitors. To turn them back on, do any input like > // moving the mouse or pressing any other key. > Mod+Shift+P { power-off-monitors; } > }