@@ -229,3 +229,21 @@
  would need deferred replies across threads. The DMABUF p95 ≤ 10 ms target (REQ-NFR-001) is
  unmeasured.
### Status of #3 at the end of this session
Done and verified on this host: pixman formats (incl. r5g6b5), damage-driven capture with the
latency numbers above, Disable/mode change/reboot (unit tests and the reboot E2E on QEMU 11.1 and
8.2), CPU cursor compositing (unit tests only), console selection by id and label through
`output_name`, the DMABUF session/frame store/vram display plumbing (unit tests with memfds).
Builds: `cmake-build-debug` (66 QEMU tests pass, 2 skip; full `test_sunshine` 637 tests, 0 failed
tests, only the three known PlatformTestSuite setup failures), `cmake-build-noqemu` (569 tests, same
as the Phase 0 baseline), `cmake-build-release-cuda`, doxygen 1.18.0 without warnings.
Open, needs a native Linux host with `/dev/dri` (and ideally `/dev/udmabuf`):
- `QemuDmabufGpuTest.ImportsCropsAndFlipsBottomUpScanout` and
  `QemuCaptureTest.VaapiRequiresQemuToRenderOnTheEncoderGpu` have never run.
- `E2E_GL=1` (VAAPI and NVENC) has never run; the GL cursor path and the `y_invert` blit are
  untested on a GPU.
- DMABUF latency (REQ-NFR-001 target p95 ≤ 10 ms); REQ-NFR-001 stays `draft` until then.
- Possible tearing because `UpdateDMABUF` is answered before the encoder reads the buffer.