Render on the GPU with no display, through Xwayland

This VM sees the host's 7900 XT through virtio-gpu and renderD128 is
readable without the video group, so the software rasteriser was never
necessary. What was in the way is that the emulator's `-gpu host` renderer
speaks GLX: with no DISPLAY it cannot open a context at all
("GlxEnginegetDefaultDisplay: Failed to open display 0") and silently falls
back.

So `emu up` now starts a headless sway whose only job is to provide an
Xwayland, and Xwayland's GLX runs on the render node. The guest's GLES
reports `virgl (AMD Radeon RX 7900 XT)` afterwards. One compositor per
machine, on a named socket so a second `emu up` reuses it; no seat, no DRM
master, no card node.

Scrolling a list in the stock Settings app: 25.5% janky frames and 8 slow
UI-thread frames on software, 3.3% and 0 on the GPU. An emulator also costs
1.1 GB less resident (2.9 GB against 3.9 GB), which is real headroom on a
machine that only takes two.

The reason this is worth the machinery is measurement rather than speed.
Before it, frame timings from in here said nothing about an app at all --
ai-app scrolled *better* than Settings, because both were bounded by the
rasteriser rather than by anything either was doing.

Host Vulkan is off in `GPU_HOST_FEATURES`, and that one is a bug rather than
a preference: gfxstream asks Venus for a memory type for its ColorBuffers
that Venus does not offer, and the emulator dies before adb sees it. GLES is
unaffected. Retry it whenever mesa moves; the failure is loud.

A missing sway, or one that will not start, says so and falls back to
software exactly as before -- verified by moving the config aside.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

README.md

@@ -40,6 +40,48 @@ about one device (`adb devices`) all turn the defaulting off, and nothing is
 guessed when this checkout's emulator is not running: adb's own error is
 better than a wrapper picking a stranger's device.
 
+## Rendering on the GPU with no display
+
+This machine has no screen, and for a long time that meant the emulator
+rasterised in software. It does not have to: the VM sees the host's GPU
+through virtio-gpu, and `/dev/dri/renderD128` is readable without being in
+the `video` group.
+
+What was in the way is that the emulator's `-gpu host` renderer speaks GLX,
+so with no `DISPLAY` it cannot open a context at all -- it says
+`GlxEnginegetDefaultDisplay: Failed to open display 0` and falls back. So
+`emu up` starts a **headless sway** whose only job is to provide an
+Xwayland, and Xwayland's GLX runs on the render node. The guest's GLES then
+reports `virgl (AMD Radeon RX 7900 XT)` instead of a software rasteriser.
+One compositor is started for the machine and reused, on a named socket
+under `XDG_RUNTIME_DIR`; it needs no seat, no DRM master and no card node.
+
+Measured 2026-08-30, scrolling a list in the stock **Settings** app:
+
+| | janky frames | 90th percentile | slow UI-thread frames |
+|---|---|---|---|
+| software | 25.5% | 93ms | 8 |
+| on the GPU | 3.3% | 28ms | 0 |
+
+An emulator also costs about **1.1 GB less** resident this way (2.9 GB
+against 3.9 GB), which is a whole emulator's worth of headroom on a machine
+that only takes two.
+
+This matters for more than speed. Before it, frame timings measured in here
+said nothing at all about an app: our own app scrolled *better* than
+Settings did, because both were bounded by the rasteriser rather than by
+anything either of them was doing. Now the platform floor is low enough that
+an app's own jank is visible above it.
+
+`GPU_HOST_FEATURES` carries the one workaround: host Vulkan is switched off,
+because gfxstream asks Venus for a memory type for its ColorBuffers that
+Venus does not offer, and the emulator dies before adb sees it. GLES is
+unaffected. It is worth retrying whenever mesa moves -- the failure is loud
+and costs one boot to find.
+
+If sway is missing, or the compositor will not start, `emu up` says so and
+starts on software rendering as it always did. None of this is essential.
+
 ## Refusing to start one
 
 `emu up` checks `MemAvailable` first and refuses if starting an emulator