coppwr exposes the live PipeWire graph instead of a settings panel

coppwr treats a running session as an editable object graph

coppwr is a Rust desktop application for people who need to see what a PipeWire session is actually doing. The README describes it as a low level control GUI for the PipeWire multimedia server, and the feature list covers node graph editing, object inspection, object creation and destruction, process monitoring with profiler statistics, metadata editing and module loading. That is a very different surface from a mixer with a row of sliders. The objects the library exposes are treated as things you can select and inspect while the graph is live, which is what makes the tool interesting when a session misbehaves and no ordinary settings panel can explain why.

The node graph runs on a forked egui-snarl, not the published crate

The visual layer rests on a short list of Rust crates named in Cargo.toml. egui and eframe 0.36.1 provide the immediate mode interface, and the manifest picks glow as the renderer instead of the default wgpu backend, with a comment pointing at a wgpu issue. egui_dock 0.21.1 supplies docking, so panels can be rearranged. The node graph itself does not come from the crates.io release of egui-snarl. The manifest points at a fork hosted by the project author, and the README credits it as a fork of egui-snarl living on a branch named coppwr. The PipeWire bindings follow the same pattern, with pipewire taken from a fork of pipewire-rs rather than the published crate. Two of the core dependencies are therefore maintained alongside the application.

Three Cargo features decide which PipeWire and portal APIs are reachable

The feature list is short enough to read in one sitting, and each entry answers a concrete question. pw_v0_3_77 exists because the Link permission on PipeWire globals only appeared in libpipewire 0.3.77, so a build against an older library has no access to that permission at all. xdg_desktop_portals is on by default and pulls in ashpd, pollster and futures-util. It provides dark and light theme detection and opens PipeWire remotes through the Camera and Screencast portals, which means the app asks the desktop portal rather than handling the grant itself. persistence is also on by default and adds serde together with eframe persistence, so window info and graph node positions are stored on disk between sessions.

Building from source demands Rust 1.95 and the PipeWire headers

Three requirements stand in the way of a source build: Rust and Cargo version 1.95 or later, the bindgen requirements, and the PipeWire library headers or development packages. The manifest declares edition 2024 and a rust-version of 1.95, so an older toolchain is rejected rather than left to miscompile. With those in place, the release build in the repository root is a single command.

cargo build --release

Because the pipewire dependency is pinned to one git revision and egui-snarl to another, the build fetches those exact commits instead of tracking the tip of either fork, which makes builds repeatable but also means upstream changes arrive only when the author updates the manifest.

Three packaging routes, none of which update themselves

Flathub hosts io.github.dimtpap.coppwr, which is the least involved route on a desktop distribution. Arch users have two AUR packages, coppwr for a source build and coppwr-bin for a prebuilt binary. Debian and RPM packages are published from the GitHub releases page rather than from distribution repositories. A note in the README states that coppwr does not self-update, so each route leaves the upgrade to you: a new Flathub or AUR release arrives on its own schedule, while a Debian or RPM package means fetching the release asset and installing it by hand.

If you prefer to build the AUR package yourself, the README gives this sequence for the prebuilt variant.

git clone https://aur.archlinux.org/coppwr-bin.git
cd coppwr-bin
makepkg -i

The makepkg step does the compile work and installs the result, so expect a Rust build rather than a quick copy.

Object creation and module loading are the wrong tool for a desktop user

The README is direct about who should not reach for coppwr. End users of PipeWire who want to configure it are pointed to simpler tools recommended by the PipeWire developers, and people curious about the internals are pointed at the PipeWire documentation and wiki instead. That separation matters, because creating and destroying objects and loading modules on a live session is destructive work by nature. The README describes those capabilities without mentioning a confirmation step or an undo path for graph edits, so treat any change made through the object inspector as permanent until you verify the session still works as expected.

GPL-3.0-only licensing and a fork-based dependency footprint

The package metadata declares GPL-3.0-only, and the source tree keeps LICENSE and Cargo.toml at the top level. For anyone auditing what ships inside, the more interesting detail is the dependency shape. egui-snarl and pipewire-rs are both used as forks maintained by the same author, which means an installed coppwr is not simply a set of crates.io versions, it is a build assembled around two upstream branches. The last push was on 2026-09-02, and the most recent tagged release is 1.7.1 from 2025-12-06, so work has continued after that release was cut.

Editorial conclusion

Adopt coppwr if you are diagnosing a live PipeWire graph or writing software that talks to libpipewire, and leave it alone if your goal is day to day device or volume configuration, where the simpler tools recommended by the PipeWire developers fit better. Before you commit to it, confirm your libpipewire version, because the Link permission on globals needs 0.3.77 or later, and accept that you will rebuild or repackage by hand, because coppwr does not self-update.

Frequently asked questions

Official sources

1. dimtpap/coppwr on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases