Feature status and limitations

This page is the long-form explanation of what evil can do today and where it is still narrow or unfinished.

---

Big picture

Today, evil is already useful for:

• experimenting with a canvas-oriented desktop model
• writing custom Lua window-management policy
• validating policy through headless and nested live tests
• running a real nested compositor session with several important desktop slices
• building on a codebase with real examples, tests, and an evolving Lua policy surface

It is still evolving, but it is past the rough-sketch stage.

---

Feature overview

Area	Current picture
Core canvas / window / output logic	strong foundation
Headless runtime	practical and heavily testable
Nested winit compositor	the main live path and a good place to actually use and iterate on configs
Lua config + hook surface	real, useful, and expanding
Example configs	several serious starting points, including tiling and tty-focused profiles
TTY / standalone backend	still experimental, but now has a canonical launcher/config path, a stronger virtual tty proof harness, and a narrow documented support target
Desktop / protocol coverage	several important slices are real already, with broader coverage still growing

Strong areas today

Core logic

These parts are relatively strong:

• canvas and viewport logic
• focus stack behavior
• placement and rules
• move/resize helpers
• output layout logic
• key binding parsing

Headless runtime

Headless is one of the strongest parts of the project today. It is heavily tested and very useful for policy work.

Lua policy surface

The Lua surface is real and useful already:

• config loading
• bindings
• autostart
• hooks
• queries
• commands
• draw hooks

Nested backend

The nested winit backend is the main live proving ground and already supports meaningful testing with real clients. For many kinds of work, it is already a practical place to actually run and iterate on configs instead of just a smoke-only environment.

---

Areas that are usable but still narrow

These are not imaginary or placeholder areas; they already have real pieces in place. The main point is that the supported scope is still narrower than what a fully broadened desktop environment would eventually want.

TTY / standalone backend

The udev path exists, can be tried, and is useful for controlled testing, but it still needs more confidence and recovery hardening before it feels routine.

The first non-experimental tty target is intentionally narrow:

• launch through scripts/start-tty.sh
• use the baseline config adapted for the udev backend as the canonical repo-owned tty config
• assume a single-seat seatd / libseat flow on a spare login VT
• treat single-output behavior as the baseline support target
• require dependable startup, repo-owned terminal-probe spawn, focus, modifier move/resize, close, VT switch away/back, clean quit, and usable logs/artifacts

The canonical automated proof path is scripts/tty-virt-smoke.sh, which now captures lifecycle markers, IPC snapshots, and a narrow mixed-app baseline using repo-owned probes.

That means multi-output tty behavior may already be interesting and partially real, but it is not part of the first non-experimental support claim yet.

The project should keep calling tty experimental until these gates are satisfied:

Contract / docs gates

• one documented canonical tty launcher/config flow exists and matches the shipped repo path
• the supported target is documented as single-seat, spare-VT, and single-output baseline first

Automated gates

• the automated virtual tty harness reliably proves the supported startup / interaction / VT-cycle / quit baseline
• tty failures are diagnosable from captured logs and artifacts

Manual gate

• at least one captured real-hardware spare-VT validation pass exists

For the first non-experimental tty target, the project is still intentionally not claiming broad support for:

• advanced monitor management and broad tty hotplug coverage
• fully general multi-output tty support
• tty-native screencopy / screenshot IPC parity
• advanced IME / input-method configuration
• a broad real-hardware compatibility matrix

Multi-output behavior

There is a real multi-output model, but not every desktop-like workflow around it is broadened yet.

Layer-shell

The first panel-style slice is proven on the winit backend, but broader shell behavior is still follow-up work. On the tty (udev) backend the layer-shell client maps and participates in session artifacts but is not yet visually rendered.

Clipboard / DnD / lock / session features

There are real first slices here, but not every broader desktop workflow is claimed yet.

XWayland

The first mixed-session path is real, but broader X11/XWayland surface area is still narrow.

---

Unsupported or deliberately narrow areas

Some support claims are intentionally kept narrow so the docs match reality. Examples of intentionally narrow or unsupported areas today include:

• broad output reconfiguration beyond the current apply slice
• broad clipboard-manager/data-control tooling
• protocol-backed screencopy and advanced capture paths
• compositor-originated DnD
• some deeper XWayland behaviors

The project tries to be explicit about these limits instead of pretending broad support exists.

---

The most important limitation to remember

The project is still choosing honesty over feature-count bragging.

That means a lot of support claims are written as:

• “first slice proven”
• “nested only”
• “tty unproven”
• “wired but not fully proven”

That is intentional.

---

How to read example configs honestly

Some examples, especially the tiling example, build creative UX behavior in Lua that feels very real from the user side.

That does not always mean the runtime has an equivalent first-class built-in feature yet.

Example:

• a page-based tiling config can emulate workspace-like behavior without a native workspace runtime
• a Lua-managed fullscreen or float mode can behave well without protocol-backed native toggles

Those are strengths of the Lua policy model, but they should still be described honestly.

---

Short version

If you want the shortest honest summary:

• core logic: strong
• headless: strong
• nested live: practical and credible
• tty: real and usable, but still the least settled path
• Lua API: useful now, still evolving toward a cleaner long-term surface
• desktop/session feature breadth: several important slices are real already, with broader coverage still being added carefully