Session app matrix

Which applications this project has actually run, on one machine, at what bar, with the observable that was checked named in every cell.

This page is generated, and the generator can only emit a cell somebody executed. An application nobody ran does not appear as a row here no matter how confident anyone is that it would work; it appears in Requested, and not emitted instead. That is the whole design: the app set cannot widen by assertion, only by running something and landing its evidence.

The machine, the build, and the date

One machine was measured. Everything below is one laptop, one Intel iGPU, one internal panel, one kernel. None of it generalises, and reading this page as “Vitrin runs these applications” would be false.

• Inventory read: 2026-08-10
• Last recorded run in this corpus: 2026-08-11 — the operator-driven bare-metal session that ran alacritty and nautilus and produced #268. The last checklist run is still 2026-08-09, the second bare-metal DRM run (docs/drm-bringup.md)
• Kernel: 7.1.6-arch1-1 — this is not the kernel the bare-metal evidence was taken on. Both DRM runs ran on 7.1.5-arch1-2 (docs/drm-bringup.md); the machine has since moved up one release
• Mesa: 1:26.1.6-1
• wlroots: wlroots0.19 0.19.3-1 — the built shim links libwlroots-0.19.so (readelf -dW shim/build/vitrin-shim). 0.17 and 0.20 are also installed on this machine and are not what is used
• vitrind revision: 38978f6 — v0.1.0-56-g38978f6, the revision of the tree at the last regeneration. Not a self-reported vitrind --version: nothing was launched to produce this page. Individual runs predate it and name their own where one is recorded — the nested lock-screen run recorded core f9f2b8a, and the second DRM run followed the three fixes in cf0e7ff
• Machine: one laptop. Intel iGPU on /dev/dri/card1 (i915) drives the only connected output, eDP-1, at 2560x1600 @ 240 Hz, scale 1. A second card (/dev/dri/card2, nvidia) has every connector disconnected and is not in the display path
• Host compositor for nested runs: Hyprland 0.56.2-1, XDG_SESSION_TYPE=wayland

CI cannot produce this page’s contents. A GitHub runner has no DRM device, no seat and no GPU, so it cannot run vitrind against a panel and cannot run a GUI application at all. What CI can do, and does, is assert that the checked-in page is byte-identical to what the generator emits — which catches a hand edit, and catches nothing else. The measurements themselves come from a human executing the runbook at the bottom of this page, on the target machine.

How to read a cell

The bar is weak, and here is exactly how weak

Most rows below were scored at one bar: the application mapped a window and repainted. Nothing was typed into it, nothing was clicked, and nothing was checked for correct rendering.

An application can map a window and repaint and still be unusable, because a realm is missing things a desktop application assumes it has:

• No cross-realm clipboard through the app’s own clipboard interface. The shim advertises wl_data_device_manager, but see shim/src/globals.c:217-224: “THIS GLOBAL STILL GRANTS NOTHING ACROSS THE REALM BOUNDARY” — a shim serves exactly one client on exactly one private socket, so both ends of any transfer through it are the same application. What exists across realms instead is a core-mediated channel driven by two physical human chords (WS-E.2.1, D-024), reachable by no client at any verb set.
• No portals. No file chooser, no screen share, no opening a link.
• No session bus. A realm has no session D-Bus of its own, so anything that expects one degrades or fails.
• No IME. Nothing here serves text-input/input-method, so composing text in any non-Latin script does not work.
• No XWayland child processes. There is no X server anywhere in this stack, so an application that forks an X11 helper loses that helper.

Where a row was proved by a named task instead — an integration gate, a runbook checklist, an issue’s acceptance criterion — the row names that task, and the task is what the row means. Those rows assert something specific and are much stronger than the weak bar.

The four evidence classes on this page

Linkage is the weakest class here and it has demonstrated false positives in both directions on this very machine — see What this page does not measure. It is published because the question “what on this machine actually needs X11” has no better answer that does not require launching everything, and it is never mixed into the two execution tables.

Desktop applications executed against vitrind

Software a person would daily drive. Every row is a recorded execution against vitrind; there are no inferred rows.

What these rows over-claim if read quickly:

• Firefox ESR — this is the pinned Mozilla ESR tarball, not a distro package — Arch ships no firefox-esr, and what is installed on the measured machine is firefox-developer-edition, which was never run against vitrind. The row is about 140.12.0esr and nothing else. The commit that first brought Firefox up in a realm, cae70f0 (2026-07-20), wired only firefox_bringup.sh into CI — under the mock core and declared SKIPPED with VITRIN_SKIP_FIREFOX_GATE=1 — so it is not this row’s provenance.
• alacritty — #203 records only vitrind --nested; it does not name the host compositor, so the venue here is this machine’s host and not something the record states.
• alacritty — Nothing was measured. No latency, no frame count, no correctness check on what the terminal drew — the operator used it and reports that it worked. The log retained on disk covers a 60-second segment ending at a VT switch away, so it corroborates the launch, the focus and the keystroke delivery, and does not cover the later part of the session in which #268 was found.
• Cursor — Plausible causes exist and none was checked, so none is recorded: an Electron app needs environment this realm’s env_allow may not carry, and the row above shows a second toplevel in a realm is a path with a known defect (#268). Both are guesses. What the corpus has is: it was launched, and nothing appeared. Re-running it with the realm’s stderr captured is what would turn this row into a cause.
• nautilus — Closing it broke the session’s keyboard, which is issue #268. toplevel_unmap clears keyboard focus to nobody, so alacritty — still mapped and still taking pointer events — could not be typed into again. Read this row as “nautilus itself worked” and not as “two windows in a realm work”: the second half of that is a filed bug. Minimize and maximize did nothing, which is not a defect — VITRIN_WM_CAPABILITIES withholds minimize deliberately and every window is single-maximized at the view size.
• kitty — kitty was proved to crash before #203’s fix — the abort was reproduced with alacritty and with kitty. #203’s acceptance criterion names alacritty alone as re-run to completion afterwards, and no record anywhere shows kitty re-run post-fix. So this row is the weak bar and not #203’s named task.
• Visual Studio Code — the recorded row reads “Electron (VS Code — so also Discord, Slack, Obsidian)”. Only VS Code was run; the other three are an inference from a shared runtime and are declined below rather than given rows.
• xterm — the repository holds only the fragment Can't open display, never the as-emitted line. libXt’s format string is Can't open display: %s, so the real line carries a colon and the display name; those bytes were not captured and are not reconstructed here.
• rofi — the six-globals count is recorded for waybar specifically, in D-021; the recorded row groups rofi with it but attaches no separate measurement. rofi also keeps an X11 path, so it appears in the Wayland-mode inventory table too.

Repository test clients executed against vitrind

Clients this repository wrote. Nobody daily drives them, and the strongest evidence in the tree is about them — which is exactly why they are in a separate table. The two checklist runs of the bare-metal backend both used solid-client; the desktop applications that have since run on it (2026-08-11) were driven by hand in one session and are recorded at the operator drove bar, which is not a repeatable task.

What these rows over-claim if read quickly:

• weston-terminal — a real third-party Wayland client with a mock-free gate — stronger evidence than any weak-bar row above — but nobody daily drives it, so it says nothing about a desktop. The cited gate runs on ubuntu-latest against apt’s weston (shim/ci/install-deps.sh), whose version this page does not record.
• gtk-entry-probe — this is a GTK3 fixture, not nautilus, gimp or inkscape, and it must not be cited as evidence for those three. No GTK4 or Qt6 fixture exists.
• clipboard-peer — the repository’s own precedent for how to record a substitution honestly: #213 names alacritty and Firefox, neither of which can be made in CI to put a known string on a clipboard without a human’s mouse, so a toolkit-free client stands in and the README says so. Not asserted: that a real chord on real hardware produces any of it.
• solid-client — solid-client commits wl_shm buffers and is not a desktop application. On the date of this run no desktop application had ever reached bare metal; two did on 2026-08-11, by hand, and their rows are above. The second run’s own open list notes the shim never emits dmabuf, so the zero-copy scanout path is dead code against every real application either way.
• solid-client — still solid-client. Three items stayed open after this run: vitrind’s own log line renders the connector name empty, the shim never emits dmabuf, and refresh_view_cache composes for absent consumers.
• input-echo-client — the run found a shipped defect — TextureKey::current enumerated every input to compose_human_visible except the lock, which is a locked session that looked unlocked. Two further warnings: the page states step 7 is weaker than it reads (input-echo-client is static, so every frame carried the identical digest), and the page contradicts itself by also carrying an empty “not yet executed” record block further down. It was executed.

Failures that are not X11 gaps

Issue #221 asks for this section by name, because a reader counting failures would otherwise fold every one of them into “no X11” and overstate what an X11 shim would buy.

• waybar — there is no zwlr_layer_shell_v1, so it has nothing to map into. This is WS-E Stage 2, which owns layer-shell.
• rofi — there is no zwlr_layer_shell_v1, so it has nothing to map into. This is WS-E Stage 2, which owns layer-shell.

Issue #203 is closed and fixed on main, and is described here in the past tense. It belongs in this section because it removed applications from the measurable set for a reason that had nothing to do with X11: on_new_deco answered an xdg-decoration request eagerly, and wlr_xdg_toplevel_decoration_v1_set_mode schedules a configure whose wlr_xdg_surface_schedule_configure asserts surface->initialized — which is correctly false at new_toplevel_decoration time, because xdg-decoration requires the decoration object to be created before the surface’s first commit. Every decoration-aware client therefore aborted the shim at startup. The fix defers the mode reply to the initial commit; shim/src/globals.c:55-77 carries the reasoning, and shim/tests/xdg_conformance_client.c’s FACT 4 is the regression test. Firefox never binds zxdg_decoration_manager_v1 at all, which is the only reason the entire acceptance suite missed it.

The machine’s X11-only software (linkage, not execution)

Measured on this machine by ELF linkage, not by running anything. These are the applications that would need Phase 3 E3.2 (per-app rootless X server with an embedded window manager) before they could run in a realm at all.

Two entries are here for completeness and are not an argument for E3.2: picom and openbox are an X11 compositor and an X11 window manager, so they are X11-only by definition rather than for want of a port, and running either inside a per-app rootless X server is not a thing anyone wants.

The interim, stated as what it is. Until E3.2 lands, the owner keeps a second session for the software in this table. So “I did not have to reboot into Hyprland” is false for this named set, and the claim must not be made without that carve-out. This is a workaround the owner accepts as a cost, not a mitigation the project offers: nothing in this stack confines that second session, it runs another compositor with full access to the same devices, and switching to it leaves the confined world entirely. See Where this is honest about its limits.

Software with a Wayland mode, so not an X11 dependency (linkage, not execution)

Measured on this machine by ELF linkage and strings, not by running anything. These are not X11 dependencies: each carries a Wayland path, selected by the switch in the third column. Counting any of them toward the X11 gap would overstate it.

Where linkage did not settle the question (linkage, not execution)

Linkage contradicted itself and only a run settles these. They are published as explicit unknowns rather than guessed into one of the tables above.

Games are recorded here as a measured dependency of this machine and as nothing else. E3.2’s exit criteria (docs/plan/03-phase-3-network-x11-fleet.md §E3.2) say nothing about games; games additionally need relative pointer, pointer constraints, gamepads and GPU features far beyond E3.2. This row is a measurement, not a commitment, and no schedule anywhere in this repository covers it.

Requested, and not emitted

These applications are on the list somebody wants covered, and the generator refused to give them a row because no execution against vitrind is recorded for them. They are named here rather than dropped silently, so the absence is legible.

• wofi — named in the recorded failing row, but not installed on the measured machine (pacman -Q wofi reports it absent), so no package version can be recorded and the cell cannot be regenerated here even by a live runbook. See the waybar and rofi rows for the same failure.
• Discord — the recorded Electron row reads “VS Code — so also Discord, Slack, Obsidian”. That parenthetical is an inference from a shared runtime, not a measurement: no record anywhere shows it executed against vitrind. See the Electron runtime row in the Wayland-mode table.
• Slack — same inferred parenthetical as Discord; never executed against vitrind. See the Electron runtime row in the Wayland-mode table.
• Obsidian — same inferred parenthetical as Discord; never executed against vitrind. See the Electron runtime row in the Wayland-mode table.
• Steam (steamwebhelper) — the owner named Steam and games as a real dependency of this machine. Nothing in the Steam stack has ever been executed against vitrind, and no schedule in this repository covers games. See its row in the inconclusive table: the client’s windowing path came out unknown, which is a measurement and not a commitment.
• google-chrome — the packaged Google build, distinct from Arch’s chromium. Never executed against vitrind, and its linkage contradicts itself. See the inconclusive table.

What this page does not measure

• Most of the seed rows are undated. The weak-bar rows carry no log, no recorder dump and no screenshot; the only bound available is the commit that wrote the record down, which bounds when the row was written, not when the application was run. The Recorded, and where column says undated where that is the case rather than reusing a commit date as if it were a run date.
• The verbatim xterm failure line was never captured. What this repository holds is the fragment Can't open display. The real format string in libXt is Can't open display: %s, so the emitted line has the shape <progname>: <error type>: Can't open display: <display> — but the bytes xterm actually wrote in that realm are gone, and they are not reconstructed here. Capturing them is a runbook step.
• Desktop applications have run on bare metal exactly once, by hand. alacritty and nautilus on 2026-08-11, in one operator-driven session — not a checklist run, not repeatable by someone who was not there, and measured for nothing. The two runs the bring-up runbook records both used solid-client. That session also produced a defect (#268: closing a second window in a realm leaves the keyboard focused on nobody) and one application that did not open at all with no cause established. The named reason to expect further difference still stands, recorded by the second checklist run: the shim never emits dmabuf, so the zero-copy scanout path is dead code against every real application.
• Every inventory row is linkage, not behaviour, and linkage has demonstrated false positives in both directions on this machine. Chromium, Blender, scrcpy, OpenRGB and rpi-imager all classify X11-only by DT_NEEDED and all five have Wayland paths (Chromium statically links its own libwayland; Blender and SDL3 dlopen theirs; Qt loads its platform plugin by name). Alacritty and kitty classify as neither, because they dlopen everything. Method, for reproducibility: readelf -d walked recursively with sonames resolved from ldconfig -p, plus strings -a. Never ldd — ldd invokes the dynamic loader and can execute the binary under inspection.
• That walk does not follow DT_RUNPATH, so a private library directory ends it. Measured, not theorised: /usr/bin/inkscape is a 19-soname launcher stub (7 direct NEEDED entries) carrying neither family, because its entire GUI lives in /usr/lib/inkscape/libinkscape_base.so — a path ldconfig -p does not know — whose own closure is 147 sonames and carries all three Wayland libraries. Any row here whose closure looks implausibly small is this case, and the fix is to point the walk at the real library.
• The installed set is not the used set. A bulk scan of /usr/bin on 2026-08-10 classified 494 ELF binaries as X11-only, owned by 114 packages, 37 of them xorg-* and 58 explicitly installed. (Method, so the number is reproducible: every non-symlink ELF file in /usr/bin, transitive DT_NEEDED closure via readelf -d with sonames resolved from ldconfig -p, counted when the closure contains an X11 soname and no libwayland-*. The dlopen false-positive above applies to this count too, so it is an upper bound on the X11-only set, not an exact one.) Which of those the owner actually uses is not measured here: no shell history was read, no access times, no launcher history. The requirement list handed to E3.2 comes from the owner naming what he needs, never from ranking a /usr/bin.
• xlsclients was empty at inventory time, and that means less than it looks. XWayland is running under the host compositor and the connection genuinely worked (xprop -root _NET_SUPPORTING_WM_CHECK returned a window id), yet xlsclients listed zero X11 clients. That is one instant on one day in a session a few hours old. It is not evidence that the owner never runs X11 software — the installed set proves he can — and a truthful version needs sampling over days, which nobody has done.
• Steam games themselves are entirely unmeasured. What was measured is steamwebhelper, the client UI. No game binary was inspected: a Proton title’s windowing path runs through Wine inside a container, which no static scan here reaches.
• Nothing was launched to produce this page. No vitrind, no realm, no nested compositor, no application under test. Every machine row is an inference from bytes on disk, and every execution row is a transcription of a run somebody else recorded earlier. Widening the matrix means executing the runbook below.

Runbook: regenerate this page on the target machine

CI has no DRM device, no seat and no GPU, and structurally cannot run this. It can only assert that the checked-in page matches a regeneration. Everything below is done by a human on the target machine.

0. Safety, non-negotiable

Run every step of section 2 in a nested host window. Never against the DRM/TTY backend from inside a live session: that takes DRM master and the seat, and kills the session you are sitting in. Bare-metal runs happen from a spare TTY, with the escape route rehearsed first — see docs/drm-bringup.md.

1. Re-take the read-only machine inventory

Nothing here launches anything. Record what these print; they are the header fields and the three inventory tables.

uname -srvmo                       # kernel -> header
pacman -Q mesa wlroots0.19         # mesa, wlroots -> header
git -C "$REPO" describe --tags --dirty   # vitrind revision -> header
pacman -Q <app>                    # one per row, for the Version column
xlsclients -l                      # X11 clients live in the current session

# Linkage, per candidate binary. NEVER use ldd: it invokes the dynamic
# loader and can execute the binary under inspection.
readelf -dW /usr/bin/<app> | grep NEEDED
strings -a /usr/bin/<app> | grep -iE 'libwayland-client|wl_compositor|ozone-platform'

A binary that shows neither family in NEEDED is not evidence of anything: alacritty, kitty, Blender, SDL3 and every Qt application load their backend at run time. Check strings before concluding, and if the two disagree, the row belongs in the inconclusive table, not in a guess.

2. Run an application in a realm, and record what you saw

Build first:

cargo build --workspace
meson compile -C shim/build

Write a one-realm file naming the application by absolute path:

cat > /tmp/matrix-realm.toml <<'EOF'
[[realm]]
id = "realm-0"
command = "/usr/bin/xterm"
args = []
env_allow = []
EOF

realm.toml refuses a relative command. Then run the core nested, capturing both streams — the failure you are measuring is usually on the application’s stderr, not in the core’s log:

./target/debug/vitrind --nested \
  --realm /tmp/matrix-realm.toml \
  --shim "$PWD/shim/build/vitrin-shim" \
  2>&1 | tee /tmp/matrix-xterm.log

Record, for the row:

1. The observable you checked. Not “it worked”. Either the specific thing a named task asserts, or — if all you did was look at it — the weak bar, mapped a window and repainted, and nothing more.
2. The verbatim failure line, copied out of the log, if it failed. A fragment is not a quote.
3. The package version from step 1, and the date.
4. The cause, if it failed: was an X server missing, or was it something else? A failure with a non-X11 cause goes in Cause::NotAnX11Gap with its owner named, or the page will overstate the X11 gap.

3. Land the measurement, and regenerate

Edit crates/xtask/src/session_matrix.rs — never this page. Add the application to REQUESTED if it is not there, then add an Execution (or a Linkage) carrying the evidence. The generator refuses a cell whose observable is a bare pass/works/ok, and refuses an Execution for an application that is not in REQUESTED.

cargo xtask session-matrix           # rewrite this page in place
git diff -- docs/book/src/session-app-matrix.md   # review what changed
cargo test -p xtask                  # the generator's own gates
cargo xtask session-matrix --check   # what CI runs; must print "no drift"

4. If you want a row and cannot get evidence for it

Add it to REQUESTED with the reason, and leave it declined. It will appear under Requested, and not emitted with your reason attached, which is the honest outcome and the one this page is built to make cheap.