Phase 0 deliverable #3 (Firefox): headless-rig finding

Firefox 150.0.1 + media.ffmpeg.vaapi.enabled=true + LIBVA_DRIVER_NAME=
v4l2_request, executed under Xvfb on ohm.

Result: inconclusive at the boolean-correctness level. RDD process
dlopens libva.so.2 + libva-drm.so.2 + libva-x11.so.2 for capability
probe then immediately closes them; never reaches vaInitialize, never
opens /dev/dri/renderD128, never reaches v4l2_request_drv_video.so.
Falls back to software H.264 in RDD via FFmpeg-OS-library PDM
(Broadcast support from 'RDD', support=H264 SWDEC).

Root cause: Xvfb provides software framebuffer with no DRI/DRM
render-node integration. Firefox's gfx-environment platform-fitness
check rejects VAAPI before adding it to the RDD PDM order list.
Not a libva-side or driver-side fault — mpv --hwdec=vaapi-copy in
the same headless rig DID engage end-to-end (per
phase0_evidence/2026-05-04/findings.md).

Definitive Firefox verdict requires retesting inside a live Plasma
session — deferred to live-session run (next commit).

Also: Phase 0 deliverable #2 (Step 1 reconciliation into fork
master) was completed and pushed to marfrit/libva-v4l2-request-fourier
between this and the prior Phase 0 commit; status table updated.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

phase0_findings.md

@@ -136,7 +136,17 @@ Items #1 and #4 above executed against the substrate that was actually deployed
 - **Substrate inventory shift**: the installed `/usr/lib/dri/v4l2_request_drv_video.so` on ohm is **not** built from `libva-v4l2-request-fourier/master`. It's `libva-v4l2-request-ohm-gl-fix 1.0.0.r0.ga3c2476-2`, built on **boltzmann** 2026-05-02 from `~/src/marfrit-packages/arch/libva-v4l2-request-ohm-gl-fix/PKGBUILD` (which applies `fourier-local.patch` + Step 1 patches `0001..0018` on top of bootlin tarball `a3c2476`). The git fork at `e8c3937` is a *pre-Step-1* substrate — it has the multi-planar wedge + HEVC strip + UAPI shim + STREAMON-defer WIP, but lacks `0002..0018` (request_pool, conditional PRED_WEIGHTS, ANNEX_B start codes, fill DECODE_PARAMS from VAAPI, no CAPTURE S_FMT, SCALING_MATRIX matrix_set predicate, level_idc, POC sentinel strip, DPB picnum, P/B-frame flags). **Rebuilding from the fork as-is would be a regression** — Phase 0 deliverable #2 (Step 1 reconciliation) is upstream of any "build from fork and install" step. The "Build + install on ohm" section below describes the *target* recipe once reconciliation lands; the *current* binary on ohm matches its build chain via the marfrit-packages PKGBUILD on boltzmann.
 - **Rig caveat**: `mpv --hwdec=vaapi --vo=null` fails with `Could not create device.` because vo=null doesn't provide a DRM context to vaapi proper — this is mpv-side, not libva. Headless test rigs (SSH session) must use `--hwdec=vaapi-copy` or run inside a real Plasma/X session.
 
-Phase 0 deliverables status: #1 ✓, #2 not started (recommended next), #3 not started (independent), #4 ✓.
+Phase 0 deliverables status: #1 ✓, #2 ✓ (Step 1 reconciled into fork master and pushed; see `libva-v4l2-request-fourier/` git log), #3 ⚠ partial (see below), #4 ✓.
+
+## Firefox engagement test (Phase 0 deliverable #3, 2026-05-04)
+
+Stock Firefox 150.0.1 + `media.ffmpeg.vaapi.enabled=true` + `LIBVA_DRIVER_NAME=v4l2_request` env, executed under Xvfb on ohm. Full write-up: [`phase0_evidence/2026-05-04-firefox/findings.md`](phase0_evidence/2026-05-04-firefox/findings.md).
+
+**Verdict**: inconclusive at the boolean-correctness level under the headless rig. Firefox's RDD process **dlopens libva.so.2 + libva-drm.so.2 + libva-x11.so.2 for capability probe** then immediately closes them; never reaches `vaInitialize`, never opens `/dev/dri/renderD128`, never reaches `v4l2_request_drv_video.so`. Falls back to software H.264 in RDD via FFmpeg-OS-library PDM (`Broadcast support from 'RDD', support=H264 SWDEC`). The gating decision happens **at Firefox's gfx-environment platform-fitness check**, before VAAPI device init — Xvfb provides software framebuffer with no DRI/DRM render-node integration, so Firefox's PDM enumerator skips VAAPI entirely. Not a libva-side or driver-side fault.
+
+mpv `--hwdec=vaapi-copy` in the same headless rig DID engage end-to-end, so the issue is specifically Firefox's gfx-env requirements being stricter. Definitive Firefox verdict requires retesting inside a live Plasma session — currently ohm has only SDDM greeter on tty1 with no active user session.
+
+**Implication for Phase 1**: Firefox stays as a target consumer in the corpus, but the binding cell for "does Firefox engage HW decode" is locked to Phase 7 verification in a real session, not to a Phase 0 baseline. mpv `--hwdec=vaapi-copy` carries the boolean-correctness substrate for Phase 0; vainfo + chromium-fourier 149 (TBD) provide additional triangulation.
 
 ## Source-read references (carry-over from STUDY.md)