Arcan: a Zig-based multimedia engine and application runtime

Arcan's target applications and runtime boundary

Arcan addresses a broad class of applications that sit above ordinary UI toolkits. The README places specialized embedded interfaces at one end of its scope and full standalone desktop environments at the other. Between those endpoints are multimedia applications built through a Lua scripting interface, graphical consoles, and programs that can run either as native components of an Arcan session or inside another desktop. This makes the project relevant to developers designing a runtime with its own display, input, and application model rather than merely rendering widgets inside an existing window system.

The repository also contains Zig build files, C and C++ source directories, Lua scripts, tests, documentation, Nix support, and data resources. Those paths indicate a system-level project with multiple deployment targets. It is not presented as a reusable package installed into a conventional application. Its installation produces several binaries, with `arcan` serving as the main engine and runtime. The source build also produces components such as the privileged `egl-dri` platform helper and the `arcan-net` client-forwarding binary.

This scope is the project's main attraction and its main adoption constraint. A team that only needs audio decoding or a display abstraction may have to absorb much more infrastructure than expected. A team building a purpose-specific interface can use the display server, input handling, multimedia engine, scripting layer, and application loader as parts of one stack rather than assembling those pieces separately. The README explicitly says the build can be tuned to reduce dependencies and configured either for a native desktop or for application runtime behavior inside another desktop.

Lua applications, display targets, and privileged process separation

The documented execution model starts with a Lua script, shared resources, and a built-in script set. The `welcome` example is a simple built-in application that exits after a few seconds, while `console` provides a command line that can also launch Arcan-compatible graphical applications. Application behavior is therefore expected to be represented above the engine rather than compiled into every client.

At startup, Arcan examines environment variables including `DISPLAY`, `WAYLAND_DISPLAY`, and `ARCAN_CONNPATH` to decide whether it should act as a native display server, nest within another display environment, or nest within another Arcan instance. The exact decision rules are not included in the README, so developers should consult the wiki and manpages before depending on a particular combination of variables. The repository's `data/appl` and `data/scripts` directories also distinguish applications from the shared or built-in Lua script collection.

Privilege handling adds another architectural layer. The `egl-dri` platform binary installs setuid by default because some device operations, including laptop backlight access through sysfs, can require elevated access. Arcan separates this helper from the main non-setuid engine. According to the README, the privileged process negotiates device access, handles virtual-terminal switching, and watches for main-process hangs or selected GPU failures. The privilege drop is implemented in `posix/psep_open.c`, which the README identifies as the place to audit.

This design gives Arcan recovery and hardware-access paths that an application library would not normally own. It also gives administrators a privileged component to review. Removing setuid does not grant unrestricted device access: the ordinary user still needs suitable permissions on `/dev/input/event`, `/dev/dri/cardN`, and `/dev/dri/renderN`. A locked-down deployment can therefore disable the setuid helper and still encounter device authorization failures.

Building Arcan with the everything preset

The shortest documented source path clones the repository and populates its in-source external dependencies. The dependency names are distribution-dependent, but the README lists the common libraries used by the broad build. OpenAL is a special case because the in-source copy is patched for an `arcan-lwa` build. Additional codecs, OCR, VNC, USB, video capture, and document rendering are optional rather than universal requirements.

This block clones Arcan and runs the external dependency script. The README says these dependencies can be statically linked for recoverable embedded deployments and that the script also accommodates distribution-specific build variations.

git clone https://github.com/letoram/arcan.git
cd arcan/external/git
./clone.sh
cd ../../

The `everything` preset is selected during CMake configuration. CMake prints which dependencies it found and which features it enabled or disabled, which is important because the resulting feature set can vary with the host system.

mkdir build
cd build
cmake -DBUILD_PRESET="everything" ../src

A debug build uses an additional CMake option. The exact compiler and linker invocation is left to the generated CMake build system.

-DCMAKE_BUILD_TYPE=Debug

After configuration, the README uses the conventional `make` and `sudo make install` sequence. It does not state a required CMake version, compiler version, minimum operating-system version, or complete per-distribution package mapping. HACKING.md and the arcan-wiki are the stated sources for developer and build details.

Running the welcome application and console from source

The documented in-source test does not require installation. It supplies the script directory with `-T`, the shared resource directory with `-p`, and the welcome application as the final argument. Paths are relative to the build directory created in the previous section.

This command launches the built engine against the checked-out scripts and resources. The application is temporary and is documented to shut itself down after a few seconds.

./arcan -T ../data/scripts -p ../data/resources ../data/appl/welcome

After installation, the equivalent built-in application is shorter. The README says Arcan will inspect its environment and choose an appropriate display configuration automatically.

arcan welcome

The more useful initial exercise is `console`. It is intended to resemble a normal command line while allowing compatible graphical applications to run within the Arcan environment.

arcan console

Input troubleshooting has a separate interactive application. The README recommends it when devices are misbehaving and presents it as a quick way to identify whether the problem lies with event delivery or graphics behavior. Its path is installation-dependent, so the README gives it as a repository-relative example rather than a packaged command name.

A first-use evaluation should record the detected display mode, available input devices, GPU access, and selected features. That information matters more than whether the welcome screen appears, because the same source build may disable components according to the dependency probe. The project also supports Lua hook scripts passed through `-H`. The `external_input` hook can expose `extio_1` and `extio_2`, allowing one client to supply input that appears to `myappl` as engine input. The README refers to the manpage for the complete hook contract.

Dependency, licence, and operational boundaries

The `everything` preset is a demonstration configuration, not a good baseline for estimating every production installation. Common dependencies named by the README include `sqlite3`, `openal-soft`, `sdl2`, OpenGL, `luajit`, `gbm`, KMS, FreeType, HarfBuzz, and `libxkbcommon`. Optional additions include FFmpeg, VLC core, Leptonica, Tesseract, LibVNCServer, libusb1, `v4l2-loopback`, and MuPDF. Package names and installation procedures depend on the distribution.

Build customization can reduce dependencies, but the README does not provide a compact matrix showing which preset removes which library or feature. Engineers must inspect CMake's output and the source build definitions for their target. This is a material maintenance consideration because a successful compile may not mean that every codec, hardware path, OCR feature, or display backend is enabled.

GitHub reports the licence as a custom category that it cannot classify. The authoritative file named by the repository is `COPYING`. The README and repository metadata do not reproduce the licence terms, so it would be wrong to assume a standard permissive or copyleft grant. Teams must review that file for redistribution, linking, modification, and distribution conditions. This article does not interpret those legal terms.

There are no GitHub releases. The repository is not archived, and its last push was on 2026-07-29. However, the README states that the GitHub repository is going defunct and that no active development occurs there. It points development to `fossil.arcan-fe.com` while saying GitHub will be synchronized for the time being. A recent synchronization therefore should not be read as a clear signal of where patches and upgrades originate.

Arcan versus a conventional desktop toolkit or compositor

The closest conventional alternative is a combination of a widget toolkit, a Wayland compositor, and separate media or input libraries. That approach leaves application presentation inside the current desktop session. Arcan can instead run as the native display server or as an application runtime inside another desktop, according to the README. It also joins that choice to Lua applications, multimedia processing, virtual-terminal handling, device recovery, hook scripts, and network client forwarding through `arcan-net`.

This difference matters for deployment control. A team using GTK, Qt, or another toolkit can normally reuse the system compositor and window manager. A team adopting Arcan may need to validate display-server behavior, privileged device negotiation, setuid policy, application scripting, and host permissions as one operating surface. The benefit is a stack designed around a custom application model, especially for embedded or recoverable environments. The cost is broader integration work.

Arcan is also the wrong choice when a lightweight library API is all that is required. The documented build centers on a multimedia engine, multiple binaries, system resources, device access, and desktop integration. The README does not document a minimal install mode or stable package API intended for ordinary single-window applications. Projects already committed to Wayland, X11, or a supported desktop compositor should first examine whether Arcan's nested runtime mode offers a requirement they cannot otherwise satisfy.

Editorial conclusion

Arcan fits developers who need an application runtime that can combine graphics, audio, input, networking, and a desktop display server. It is a poor fit for teams seeking a small dependency-free library or expecting new GitHub releases. Before adoption, verify the custom terms in COPYING, reproduce the dependency build on the target operating system, and confirm that the self-hosted Fossil repository will supply fixes and upgrades.

Frequently asked questions

Official sources

1. Issues
2. letoram/arcan on GitHub
3. Project website
4. README