libva-multiplanar/phase0_evidence/2026-05-04-firefox/findings.md

# Phase 0 deliverable #3 — Firefox VAAPI engagement test (2026-05-04)

In-session test of stock Firefox 150.0.1 with `media.ffmpeg.vaapi.enabled=true` + `LIBVA_DRIVER_NAME=v4l2_request` env. Headless rig (Xvfb under SSH).

## Verdict

**Inconclusive at the boolean-correctness level under this rig.** Firefox loads our libva backend for a capability probe but does not engage it for the actual H.264 decode — falls back to software via FFmpeg in the RDD process. The decision to skip VAAPI happens **at Firefox's gfx-environment gating layer**, before VAAPI device init is attempted. **Likely cause: Xvfb provides software framebuffer with no DRI/DRM render-node integration, which Firefox requires for VAAPI surface allocation.** Not a libva-side or driver-side fault.

A definitive Firefox verdict requires retesting inside a real Plasma/X session with live DRM access. That's a Phase 7 verification task once a session is live.

## What was actually run

Firefox 150.0.1, profile at `/tmp/firefox-vaapi-test/profile/` (preserved as `profile_user.js` here), with these prefs on top of stock:

- `media.ffmpeg.vaapi.enabled = true`
- `media.ffvpx.enabled = false`
- `media.hardware-video-decoding.force-enabled = true`
- `media.hardware-video-decoding.enabled = true`
- `media.av1.enabled = false`
- `gfx.x11-egl.force-enabled = true`
- `widget.dmabuf.force-enabled = true`
- `media.rdd-process.enabled = true`
- `media.rdd-ffvpx.enabled = false`
- `media.rdd-ffmpeg.enabled = true`
- `media.gpu-process-decoder = true`
- `logging.PlatformDecoderModule = 5`, `logging.MediaPDM = 5`

Env on top of stock:

- `MOZ_DISABLE_RDD_SANDBOX=1`, `MOZ_DISABLE_CONTENT_SANDBOX=1`, `MOZ_DISABLE_GMP_SANDBOX=1`, `MOZ_DISABLE_SOCKET_PROCESS_SANDBOX=1` (rule out sandbox interference)
- `LIBVA_DRIVER_NAME=v4l2_request` + `LIBVA_V4L2_REQUEST_VIDEO_PATH=/dev/video1` + `LIBVA_V4L2_REQUEST_MEDIA_PATH=/dev/media0`
- `LIBVA_MESSAGING_LEVEL=2`

Run command:

```
xvfb-run -a -s "-screen 0 1280x720x24" -- \
  strace -ff -ttt -s 256 -o /tmp/firefox-vaapi-test/strace/ff \
    -e trace=ioctl,openat,close,clone,clone3,execve \
    firefox -profile /tmp/firefox-vaapi-test/profile -no-remote -new-instance \
      file:///tmp/firefox-vaapi-test/test.html
```

Test page autoplays `bbb_1080p30_h264.mp4` via `<video src="file://..." autoplay muted>`. Run ran to 30 s timeout (exit 124).

## Evidence — what the strace shows

| Process | PID | Behavior |
|---|---|---|
| Parent | 143578 | dconf warnings only, no media path |
| RDD | **143696** | **Opens `/usr/lib/libva.so.2` + `libva-drm.so.2` + `libva-x11.so.2`, immediately closes them all** (~9 ms apart, no fd retained). Capability probe pattern: `dlopen` → `dlsym` → `dlclose`. |
| Content | 143725 | No libva opens; talks to RDD via IPC for decode |
| Utility | 143764 | Second probe of libva.so.2 + libva-drm.so.2 + libva-x11.so.2; gets `ENETDOWN` first try (sandbox path mangling), retries with `O_NOCTTY|O_CLOEXEC` and succeeds |
| (forkserver) 143775 | 143775 | Re-probes the same libva chain; same close-immediately pattern |
| Anywhere | — | **Zero** opens of `/dev/dri/renderD128` (the DRM render node libva-v4l2-request would use); only `/dev/dri` directory enumeration to enumerate render nodes |
| Anywhere | — | **3 V4L2 ioctls total** — and the three `/dev/video[012]` opens at 1777888991.21x are **Firefox's webrtc/camera enumeration probe**, not libva-driven (timestamps precede the libva opens by ~115 ms) |
| Anywhere | — | **`v4l2_request_drv_video.so` never opened** — libva-v4l2-request was never reached |

So the libva backend is reachable from Firefox's process tree and not blocked by sandbox; Firefox just doesn't drive it.

## Evidence — what the MOZ_LOG shows

From `firefox.log.child-2.moz_log` (RDD process, 276 KB):

```
[RDD 143696: Main Thread]: D/PlatformDecoderModule PDMInitializer, Init PDMs in RDD process
[RDD 143696: Main Thread]: D/PlatformDecoderModule FFMPEG: version: 0x200, macro: 62, micro: 100/101, isFFMpeg: yes
[RDD 143696: Main Thread]: D/PlatformDecoderModule FFVPX: Link result: Success
[RDD 143696: Main Thread]: D/PlatformDecoderModule PDMInitializer, RDD PDM order:
[RDD 143696: Main Thread]: D/PlatformDecoderModule PDMInitializer, 0: FFmpeg(FFVPX)
[RDD 143696: Main Thread]: D/PlatformDecoderModule PDMInitializer, 1: FFmpeg(OS library)
[RDD 143696: Main Thread]: D/PlatformDecoderModule PDMInitializer, 2: Agnostic
```

PDM order in RDD is FFVPX → FFmpeg(OS library) → Agnostic. **No VAAPI PDM in the order list** — Firefox's PDM enumerator concluded VAAPI isn't usable on this rig before adding it to the list.

From `firefox.log.moz_log` (parent, 210 B):

```
[Parent 143578: Main Thread]: D/PlatformDecoderModule Broadcast support from 'RDD', support=H264 SWDEC
```

The `SWDEC` suffix is decisive: parent confirms RDD reports H.264 capability at the **software-decode** tier, not VAAPI / hardware tier.

Steady-state during playback: many `[RDD 143696: MediaPDecoder #4]: V/PlatformDecoderModule ProcessDecode: mDuration=41666µs ; mTime=...` lines — RDD is decoding 24 fps content via FFmpeg (`mDuration=41666µs` = 1/24 sec), software path.

## Why this happens

Firefox's VAAPI gating in modern code (since ~115) requires a working EGL+DMABUF environment that can allocate VAAPI surfaces and import them as DMA-BUFs for compositing. The check happens during PDM enumeration in the RDD process, before any VAAPI device init. Under **Xvfb**:

- Xvfb is a software X server with no `/dev/dri` integration (its rendering goes to a software framebuffer, not the GPU).
- `gfx.x11-egl.force-enabled = true` lets Firefox try EGL on Xvfb, but the EGL context can't get a GBM device.
- DMABUF allocation requires a render node with GBM support, which Xvfb doesn't expose.

So Firefox's PDM enumerator skips VAAPI and the OS-library FFmpeg PDM falls through to software H.264. The probe of libva.so.2 we see is Firefox **checking that libva is installed** (so it knows to add VAAPI as a candidate **for environments that support it**), but the platform-fitness check then disqualifies the candidate.

The probe is not the engagement. The engagement is what we'd see if we got a `/dev/dri/renderD128` open + `vaCreateContext` ioctls + `__vaDriverInit_1_23` symbol call into our `v4l2_request_drv_video.so` + the V4L2-stateless contract trace on `/dev/video1` + `/dev/media0`. None of that happened.

## Predecessor-claim retest

| Claim | Result |
|---|---|
| Firefox 150 + `media.ffmpeg.vaapi.enabled=true` + LIBVA env vars engages our backend (Mozilla bug 1965646 documents this is "supposed to work" on RK3566/RK3588) | **Not engaged under Xvfb headless rig.** Capability probe only; SW fallback. |
| `LIBVA_DRIVER_NAME=v4l2_request` is sufficient for Firefox to choose our backend | Sufficient at the libva-driver-selection layer (libva.so loaded the right driver), but Firefox doesn't reach that layer because gfx-env check fails first. |
| `MOZ_DISABLE_RDD_SANDBOX=1` clears sandbox-related blockers | RDD sandbox not the blocker — even with sandbox disabled, VAAPI isn't engaged. The `ENETDOWN`-then-retry pattern in some processes is unrelated noise. |

## Implication for Phase 1 lock

Firefox-as-test-consumer: ✓ libva backend reachable, ✗ engagement not demonstrable in this rig, ⚠ definitive answer requires real Plasma session.

Two options for closing this Phase 0 deliverable:

1. **Accept rig limitation, defer Firefox engagement test to Phase 7 verification.** Phase 1 binding cells include Firefox as a target consumer; Phase 6 implementation (if any beyond Step 1) goes ahead; Phase 7 retests Firefox in real Plasma session at the end. Risk: if there's a Firefox-specific engagement bug, we discover it late.
2. **Run the test inside a live Plasma session** (drive sddm-greeter through to a user session, or wake the user session via SSH `loginctl unlock-session`/etc.). Removes the Xvfb confound. Ohm currently has SDDM greeter on tty1 + no live user session, so this requires either physical interaction or a session-start orchestration script.

mpv `--hwdec=vaapi-copy` in the same headless rig DID engage the libva backend end-to-end (per `phase0_evidence/2026-05-04/findings.md`), so the issue isn't "headless can't VAAPI" — it's specifically Firefox's gfx-env requirements being stricter than mpv's.

## Artifacts

- `profile_user.js` — Firefox profile prefs
- `test.html` — autoplay test page
- `firefox.log.{moz_log,child-1.moz_log,child-2.moz_log}` — MOZ_LOG output
- `firefox_stderr` — stderr (mostly dconf-CRITICAL noise from missing XDG_RUNTIME_DIR perms)
- `strace_parent_143578`, `strace_rdd_143696`, `strace_content_143725`, `strace_utility_143764` — per-process strace