scroll: a Wayland compositor that drops tiling for scrolling

One fork, one layout

scroll is a Wayland compositor forked from sway, and the difference is stated in the first paragraph of the README: the main difference is that scroll only supports one layout, a scrolling layout similar to PaperWM, niri or hyprscroller.

That is the whole thesis. sway gives you tiling, stacking and tabbed layouts, and the choice between them is per workspace and per key press. scroll takes that away and gives you one model in which windows are arranged along a scrolling axis, so a window opens beside the focused one and the view scrolls to reach it.

What survives the fork is compatibility. The README says scroll works very similarly to hyprscroller, and that it is also mostly compatible with sway configurations aside from the window layout. The executables are renamed to scroll, scrollmsg, scrollnag and scrollbar, the build tree is basically the same as sway's, and the IPC and configuration surface a sway user already knows still applies. The README advises people unfamiliar with i3 or sway to read their documentation, because compatibility is very high.

There is one structural difference that affects building rather than using. scroll uses a modified version of wlroots that is included in the source tree and linked statically, so you need the scroll dependencies plus the wlroots dependencies, and you do not need a system wlroots installed.

The feature list is where the fork earns its name

Beyond the layout, scroll adds a set of features that sway does not have. The visual ones come first: very customizable animations, rounded borders and title bars, dimming of inactive windows, and dynamic shadows with blur. Content scaling lets the content of individual windows be scaled independently of the general output scale.

Then there are the navigation features, and they are the most substantial additions. Overview mode shows an overview of the desktop and lets you work with the windows at that scale, with two overview modes, one showing all the windows on the workspace and another showing all the workspaces on each monitor, both fully interactive. Jump lets you move to any window with a few key presses, similar to easymotion in some editors, and it accepts window rules as criteria. There is a jump mode to preview and switch to any available workspace. Workspace scaling lets you scale the workspace to any scale and keep working.

Scripting is the other axis. scroll provides a Lua API to script the window manager and a Lua REPL to use the API in real time, invoked with `scrollmsg --lua_repl`. A REPL means you can inspect and change the running compositor while it is running, which is the kind of thing that turns a window manager into a platform.

The rest of the list is smaller but specific: several full screen modes named workspace, global, application and layout; trails and trailmarks, which are anonymous marks you define and jump to; spaces, which are named configurations of existing windows that can be recalled later on the same or any workspace; alignment and fitting rules; a focus ring for the last few focused windows; pinned windows; trackpad or mouse dragging to scroll the workspace; per output orientation so the layout works on monitors placed in either orientation; a `workspace split` command to show both halves of an ultra wide display at once; and optionally minimizing windows to a scratchpad.

The man pages are the documentation

The README says the man pages are the best source of documentation for details on all the commands, and that they are up to date. It points you at the manual sections directly.

``` bash man 5 scroll man 1 scroll man 1 scrollmsg man 7 scroll-ipc man scroll-output man scroll-bar man scrollnag ```

Five is the configuration manual, one is the program, seven covers the IPC. If you have not installed scroll yet, the source of the manual is in the repository at sway/scroll.5.scd.

Two other sources sit alongside it. There is a TUTORIAL.md in the repository with videos explaining the different features, and there is an example configuration at config.in that includes key bindings for most commands. The README suggests reading the example configuration carefully with the manual side by side, and experimenting while customizing it.

This is a deliberate design choice rather than an omission. A compositor is configured through a key binding language, and the man pages are the reference for that language, the same way a manual page is the reference for a command line tool.

Packaging for Arch, Fedora and NixOS

On Arch Linux there are two AUR packages. The stable one is `sway-scroll`, currently at 1.12, and it corresponds to the development version of sway, so you can have any version of sway and scroll installed on the same system and start either without problems, because scroll does not need a system wlroots and its executable and file names differ.

``` sh paru -S sway-scroll

The unstable development version carries all the newest changes and features.

sh paru -S sway-scroll-git ```

The README notes that the package `sway-scroll-stable` has been discontinued and renamed `sway-scroll`, so an existing installation should be migrated rather than left pointing at the old name.

On Fedora and derivatives, scroll is packaged in the Terra repository, and the install is `dnf install scroll`. On Nobara and Ultramarine Terra is pre-installed. On Bazzite it is pre-installed but disabled, and the README tells you to enable and install it at your own risk. NixOS users are pointed to a maintained flake in another user's repository, with the maintenance credited to Diax170.

Artix needs an elogind patch before the AUR package works

Artix uses elogind instead of the systemd login daemon, and because of that the AUR packages for scroll will not work out of the box. Artix also has no package of its own for scroll, so the options are to install it manually or to modify the AUR package, and the README points at an issue describing the change.

The manual route starts by cloning the package repository.

``` bash git clone https://aur.archlinux.org/sway-scroll.git cd sway-scroll

Then a patch to the PKGBUILD replaces systemd-libs with elogind in the dependency list.

diff --- a/PKGBUILD +++ b/PKGBUILD @@ -19,7 +19,7 @@ "libliftoff" "libglvnd" "lcms2" - "systemd-libs" + "elogind" "opengl-driver" "xcb-util-errors" "xcb-util-renderutil"

The second hunk changes the meson options so the build uses the elogind provider for sd-bus.

diff

build() { mkdir -p build - arch-meson build scroll -D sd-bus-provider=libsystemd -D werror=false -D b_ndebug=true + arch-meson build scroll -D sd-bus-provider=libelogind -D werror=false -D b_ndebug=true ninja -C build }

With the patch applied, the package is built and installed with makepkg.

bash makepkg -si ```

This is a good illustration of the cost of a fork in a specific corner of the ecosystem. Nothing is wrong with scroll, but every distribution variation in the init system has to be handled by someone, and here that someone is the user.

Building from source, and what the tree contains

The repository is the sway source tree with the changes applied, and the layout makes that obvious. There are directories for sway/, swaybar/, swaymsg/ and swaynag/ alongside the scroll specific client/, common/, include/, protocols/ and subprojects/, plus completions/ and tests/ with a pytest.ini.

The build system is meson, with meson.build at the root and meson_options.txt alongside it. The subprojects/ directory is where the bundled wlroots lives, which is the modified version that is linked statically. That is why the README says you need the scroll dependencies plus the wlroots dependencies to build it, and why a system wlroots is not required.

The other root files describe the project process: release.sh for cutting a release, a .clang-format for the C code style, .editorconfig, a .mailmap and CONTRIBUTING.md. The presence of sway/ and swaybar/ directories next to the scroll ones is a reminder that a fork carries its ancestry in the tree, and a change that fixes something in scroll often has an upstream equivalent that someone will want to send back.

Release cadence, maintenance and the licence

The release list shows 1.12.19 on 2026-08-12, 1.12.20 on 2026-08-18 and 1.12.21 on 2026-08-21, with the last push on 2026-10-19. So the project publishes patch releases into the 1.12 line at a fairly regular pace, and the working tree is ahead of the last tag.

That matters for the packaging story. The AUR stable package is described as currently at 1.12 and corresponding to the development version of sway, while `sway-scroll-git` tracks the newest changes. The gap between a tagged release and the working tree is where the newest features live, which is why the README describes the git package as unstable and the tagged one as stable.

The licence is MIT, with the terms in the LICENSE file at the repository root, so building scroll yourself and distributing it carries no unusual obligation beyond keeping the licence text. The practical cost of adopting a compositor fork is not licensing but tracking. You are running software that diverges from sway on purpose, and the config compatibility is described as high but explicitly excepting the window layout, so the day you need sway's tiling layouts back, scroll is the wrong tool rather than a configurable one.

Editorial conclusion

scroll suits a Wayland user who wants the i3 keybindings and configuration habits with a scrolling, PaperWM style layout instead of tiled stacking, and who is willing to read man pages rather than a GUI settings app. It does not suit someone who wants sway's multiple tiling layouts, or someone whose distribution has no package and no AUR access. Verify first which version you are installing, since the stable AUR package is at 1.12 while the repository was pushed to on 2026-10-19 with tags up to 1.12.21, and read man 5 scroll before rewriting your configuration.

Frequently asked questions

Official sources

1. dawsers/scroll on GitHub
2. Issues
3. License: MIT
4. README
5. Releases