# driftwm: Infinite Canvas Wayland Compositor

> driftwm is an experimental Rust Wayland compositor that places native-size windows on an infinite 2D canvas. It targets trackpad and touchscreen users, while its recent releases and compositor-level scope require direct compatibility and license checks.

**malbiruk/driftwm** — A trackpad-first infinite canvas Wayland compositor.

- Repository: https://github.com/malbiruk/driftwm
- Website: https://malbiruk.github.io/driftwm/
- Stars: 1,828 · Forks: 78
- Language: Rust
- License: NOASSERTION
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/malbiruk-driftwm

## Why driftwm Uses a Canvas Instead of Workspaces

driftwm addresses a specific gap between conventional stacking and tiling window managers. Stacking compositors place windows over one another. Tiling compositors divide available screen space into cells or computed layouts. driftwm takes another approach: windows retain their native sizes on an infinite 2D canvas, and the display acts as a camera that can pan and zoom across that canvas.

The project is designed primarily for laptops, especially users who navigate with a trackpad or touchscreen. On a compact screen, the canvas allows applications to occupy separate spatial regions rather than forcing every window into one viewport. Users pan to an application when needed, zoom out to inspect several windows, or move the camera back to a saved position.

Window proximity supplies the compositor's grouping behavior. As window edges approach one another, driftwm snaps them together. Neighboring snapped windows form an implicit cluster that can be moved, resized, or fitted as a group. There is no documented explicit grouping command that users must maintain. This can produce rows and pane-like arrangements without imposing a global tiling rule.

That model will not satisfy everyone. A person who needs a deterministic grid, fixed workspaces or strict screen containment may find the spatial arrangement harder to predict. A person who wants every window to remain immediately visible can use zoom-to-fit, but the compositor still depends on camera movement and the user's ability to remember locations. driftwm is therefore aimed at users who prefer spatial navigation over conventional workspace boundaries.

## How Smithay Backs driftwm's Compositor Architecture

driftwm is implemented in Rust and built on Smithay. `Cargo.toml` pins Smithay and `smithay-drm-extras` to the Git revision `4cf0b62028039661477d482ec4758b687d8f4392`. It enables backend and rendering features including `backend_drm`, `backend_gbm`, `backend_egl`, `backend_winit`, `backend_libinput`, `renderer_gl` and `wayland_frontend`, along with desktop support.

This is a compositor rather than a utility that arranges windows inside an existing desktop session. The Makefile installs a `driftwm` executable, a `driftwm-session` script, a Wayland session desktop file, an XDG desktop portal configuration, systemd user units, a reference configuration and wallpaper resources. Those artifacts show that adopting driftwm involves display-session and service integration, not just launching an application from a desktop menu.

The canvas itself behaves as a viewport with position and scale. A three-finger swipe pans it, while trackpad scrolling pans it when the pointer is over the canvas. `Mod` plus left-button dragging also pans it from anywhere. Scroll momentum allows a quick flick to continue until friction stops the movement.

Zoom can be controlled through a two-finger pinch on the canvas, a three-finger pinch anywhere, the mouse wheel over the canvas, or `Mod` plus scroll at the cursor. `Mod+=` and `Mod+-` change zoom, while `Mod+0` and `Mod+Z` reset it to `1.0`. This separates window coordinates from screen coordinates, which is the central mechanism behind the compositor's spatial model.

## Snapping, Navigation, and Cluster Operations

Navigation follows the geometry of the canvas. A four-finger swipe or `Mod+Ctrl` plus left-button drag jumps to the nearest window in the gesture's direction. `Mod` plus an arrow moves toward a directional target, including configurable anchors that remain valid when no window occupies that direction. `Alt-Tab` and `Alt-Shift-Tab` cycle through windows by most-recently-used order.

Bookmarks store named or numbered canvas positions. `Mod+1-4` jumps to the first four bookmarked positions, and `Mod+Shift+1-4` saves the current camera location. A home toggle, available through a four-finger pinch out or `Mod+A`, moves between the origin and the prior position. These mechanisms are important because an infinite canvas has no visible boundary indicating where a previous session placed an application.

Moving a window uses `Alt` plus left-button drag or a three-finger doubletap-swipe. When a window is dragged past the viewport edge, driftwm auto-pans the canvas. Resizing is available through `Alt` plus a three-finger swipe, `Alt` plus right-button drag, or several pinch bindings. `Mod+M` provides a maximize-like fit: it centers the viewport, resets zoom to `1.0`, and resizes the focused window to fill the screen. Applying it again restores the previous state.

Snapped neighbors can move or resize with their cluster when `Shift` is held. `Mod+Shift+W` fits a cluster into the viewport. This implicit behavior reduces explicit layout bookkeeping, but it also means proximity can become an editing boundary that users did not intend. The README describes the snapping rule but does not document a complete user interface for previewing or rejecting a prospective cluster.

## Building driftwm 0.19.0 and Installing Session Resources

The package declares version `0.19.0`, Rust edition 2024 and a minimum Rust version of `1.88`. The repository Makefile documents a release build. This command compiles the compositor in release mode and writes the binary to Cargo's release output directory unless `CARGO_TARGET_DIR` changes that location:

```bash
cargo build --release
```

After the build succeeds, the documented installation target installs the binary, session script, desktop metadata, portal configuration, systemd user files, reference configuration and wallpapers:

```bash
make install
```

The Makefile sets `PREFIX ?= /usr/local`, then places the main executable and `driftwm-session` under the binary directory. It also installs `driftwm.desktop` under `share/wayland-sessions`, `driftwm-portals.conf` under `share/xdg-desktop-portal`, and `driftwm.service` plus `driftwm-shutdown.target` under `lib/systemd/user`. With the default prefix, the compositor binary is `/usr/local/bin/driftwm`.

A practical first session begins with the installed Wayland session entry rather than nesting driftwm inside an unrelated graphical session without understanding its compositor role. Launch one application, pan to another canvas region, then launch a second application there. Move the second window toward the first until their edges snap. Finally, test directional navigation, zoom-to-fit and cluster movement with `Shift`.

Configuration details should be read from `config.reference.toml`. The Makefile removes any old `/etc/driftwm/config.toml` during installation and installs `/etc/driftwm/config.reference.toml`, so users should not expect the reference file to overwrite an existing configuration.

## Trackpad and Touch Input Requirements

Gesture coverage is extensive, which is one of driftwm's main differences from a keyboard-dominated tiling model. Four-finger navigation gestures also work as `Mod` plus three-finger gestures on smaller trackpads. Four-finger pinch in or `Mod+W` performs zoom-to-fit. Four-finger pinch out or `Mod+A` toggles home, while a four-finger hold or `Mod+C` centers the focused window.

The README also states that touchscreens can pan and zoom the canvas, jump between windows, and move or resize windows or whole groups. It shows that touch is a first-class input path in the product design rather than an incidental adaptation.

Users should verify gesture recognition on their own laptop before committing a primary session. Modifier combinations include `Alt`, `Shift`, `Mod`, `Ctrl`, and four modifier keys used for bookmarks. Some operations have both gesture and keyboard equivalents, which helps when recognition is imperfect, but the number of bindings raises the learning and conflict burden.

Mouse input is also available. `Mod` plus left-button drag pans the viewport, `Alt` plus left-button drag moves a window, and `Alt` plus right-button drag resizes it. Mouse wheel scrolling zooms when the pointer is over the canvas. This reduces dependence on touch hardware, but it does not change the compositor's central spatial assumptions.

## Experimental Status, Licensing, and Maintenance Cost

The README warns that driftwm is experimental software and says it was primarily built with AI. That warning matters because a Wayland compositor occupies the display, input, rendering and session stack. A defect or unsupported configuration can affect more than one application. The presence of Rust tests, `proptest-regressions`, `insta` and repository development files is useful project structure, but it is not a published compatibility or production-readiness guarantee.

Maintenance activity is visible. The recent releases are `v0.17.3` from 2026-08-18, `v0.18.0` from 2026-09-06, and `v0.19.0` from 2026-09-14. The last push was on 2026-09-21. The repository is not archived. These facts support trying current versions, but they do not remove the cost of checking release notes, gesture changes and compositor integration after upgrades.

Licensing requires care. The README badge and `Cargo.toml` state `GPL-3.0-or-later`, while GitHub classifies the repository license as a custom license it cannot categorize. Users who intend to redistribute, modify or incorporate the code should read the repository's `LICENSE` file directly and confirm the actual terms. This is a license verification step, not legal advice.

Build maintenance also includes the pinned Smithay Git revision. A later dependency resolution or Smithay revision can affect compilation and behavior. The repository includes `flake.nix` and `nix/`.

## Why driftwm Differs from Conventional Compositors

driftwm is not a conventional tiling compositor with an infinite background. Tiling compositors assign applications to predefined regions or calculate a global layout. driftwm allows windows to remain at native size in independent canvas coordinates. The display viewport can move toward a window, move away from it, or zoom out until several applications are visible together.

It also differs from stacking compositors. A stacking system normally makes overlapping windows part of a screen-bound ordering. driftwm says window overlaps happen only on purpose. Its automatic behavior is proximity snapping: nearby edges become connected, and cluster-aware operations can move or resize them together.

This approach trades explicit boundaries for spatial navigation. Conventional layouts can make application positions predictable from the visible screen. An infinite canvas requires users to remember locations or rely on anchors, bookmarks, directional jumps, MRU cycling and zoom-to-fit. Users who enjoy spatial organization may find this direct and coherent. Users who depend on strict placement rules may find implicit clusters harder to predict.

The right comparison is therefore based on interaction model. driftwm suits a user who wants a large virtual desktop controlled through camera movement and proximity. It does not suit a user seeking a fixed grid, workspace isolation or a minimal-risk replacement for a mature display stack. Its distinctive canvas is useful only when the surrounding Wayland integration and gesture behavior meet the user's hardware and workflow requirements.

## Conclusion

Adopt driftwm if you specifically want spatial window management on Linux and can evaluate an experimental compositor outside your primary session. Do not adopt it for strict tiling, predictable stacking or minimal compositor risk. Before switching sessions, verify the `GPL-3.0-or-later` terms against the repository's `LICENSE`, test the documented gestures on your trackpad, and check whether the Wayland applications, portal configuration and systemd session resources required by your setup work with v0.19.0.

## FAQ

### Does driftwm require a trackpad?

No. driftwm is designed around trackpads, but the README also documents mouse bindings, keyboard shortcuts and equivalent touch operations.

### Does driftwm use tiling or workspaces?

No. Windows remain at native size on an infinite canvas, and proximity snapping forms implicit clusters without an explicit group-management workflow.

### How do you build and install driftwm?

The Makefile provides a release build target using `cargo build --release` and a `make install` target for the compositor and its session resources.

### What Rust version does driftwm require?

The `driftwm` package specifies Rust `1.88` and edition 2024 in `Cargo.toml`.

### Is driftwm suitable for a primary Linux session?

The README labels it experimental software and says it was primarily built with AI. It does not make a production-readiness claim.

### How are driftwm window groups managed?

Nearby window edges snap into an implicit cluster. Holding `Shift` during movement, resizing or fitting can operate on the connected windows without explicit group management.

## Sources

- [Issues](https://github.com/malbiruk/driftwm/issues)
- [malbiruk/driftwm on GitHub](https://github.com/malbiruk/driftwm)
- [Project website](https://malbiruk.github.io/driftwm/)
- [README](https://github.com/malbiruk/driftwm/blob/main/README.md)
- [Releases](https://github.com/malbiruk/driftwm/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/malbiruk-driftwm