# fresnel-fourier

## TL;DR

Peer campaign to [`libva-multiplanar`](../libva-multiplanar/README.md), targeting **fresnel** (Pinebook Pro / Rockchip **RK3399**) instead of ohm (PineTab2 / RK3566). Same deliverable shape — make `libva-v4l2-request-fourier` work end-to-end, for production VA-API consumers — but on a different SoC with a different (and broader) V4L2 decoder surface.

The libva backend fork itself (`libva-v4l2-request-fourier`) is shared: it lives at [`../libva-multiplanar/libva-v4l2-request-fourier/`](../libva-multiplanar/libva-v4l2-request-fourier/). This campaign does not nest a second copy. Code-side work that turns out to be RK3399-specific lands either as `#ifdef`/runtime-detected paths inside that fork's `master` or, if scope diverges sharply, on a feature branch — Phase 2 source-read of each iteration decides.

## Origin

`libva-multiplanar` reached iter5-close on 2026-05-05 with the ohm path solid: hantro (`rk3568-vpu` DT compatible) decodes H.264 to NV12 dmabufs end-to-end, three iterations of bugs fixed, mpv `--hwdec=vaapi` smooth, firefox-fourier RDD-sandboxed Firefox engages the backend without `MOZ_DISABLE_RDD_SANDBOX=1`, chromium-fourier 149 confirmed as the regression-check consumer.

That campaign's README explicitly names fresnel (RK3399) and ampere/boltzmann (RK3588) as **"future iterations after ohm path is solid"** (libva-multiplanar/README.md:87). fresnel-fourier is the formal peer campaign for the RK3399 leg of that promise.

**Topology choice (LOCKED 2026-05-07):** peer campaign, not child of libva-multiplanar. Each runs its own 8(+1) phase loop. Cross-link only — fresnel-fourier results do *not* gate libva-multiplanar's Phase 8 close (which already happened iteration-by-iteration on ohm).

## Hardware target

**fresnel** — Pinebook Pro laptop. See [`reference_fresnel_kernel_constraints.md`](../../.claude/projects/-home-mfritsche-src-fourier/memory/reference_fresnel_kernel_constraints.md) for the custom-OC-kernel discipline (don't let `pacman -Syu` clobber the OC DTB) and [`project_fresnel.md`](../../.claude/projects/-home-mfritsche-claude/memory/project_fresnel.md) for fleet placement.

| Property | Value |
|---|---|
| SoC | Rockchip **RK3399** (2× Cortex-A72 + 4× Cortex-A53) |
| GPU | Mali-T860 MP4 (Midgard, panfrost) |
| Decoder block 1 | **rkvdec** (`/dev/video3`) — H.264 + HEVC + VP9 |
| Decoder block 2 | **hantro-vpu-dec** (`rk3399-vpu-dec`, `/dev/video5`) — MPEG-2 + H.264 + VP8 |
| Encoder block | **hantro-vpu-enc** (`/dev/video4`) — JPEG only |
| OS | EndeavourOS-ARM (Arch derivative; same pacman + marfrit-packages mechanism as ohm) |
| Kernel | `linux-eos-arm 6.19.9-99` — **CONFIG_FTRACE=y, CONFIG_FUNCTION_TRACER=y, CONFIG_DYNAMIC_FTRACE=y, CONFIG_TRACING=y** verified 2026-05-07. No rebuild needed for trace work. |

The decode-side surface area is genuinely broader than ohm. ohm has hantro (H.264 + MPEG-2 + VP8) and an rkvdec block whose mainline `rkvdec2`/`vdpu346` driver isn't merged. fresnel has hantro **plus** a fully-driven mainline `rkvdec` covering H.264 + HEVC + VP9. So this campaign exercises codecs (HEVC, VP9) the libva-v4l2-request-fourier fork has **never run on real hardware** to date.

GPU side: panfrost on Mali-T860 (Midgard) is a different generation than ohm's Mali-G52 (Bifrost). KWin / Mesa / panfrost stack regressions or wins on T860 are **not** assumed to track G52 — the kwin-fourier verdict from `fourier_attribution` doesn't transfer for free.

## Scope (LOCKED 2026-05-07 in phase0_findings.md)

**In scope:**

- libva-v4l2-request-fourier backend exercised on fresnel V4L2 decode nodes (`rkvdec` + `hantro-vpu-dec`).
- **Codecs: everything decode-capable** — H.264 + HEVC + VP9 (via rkvdec) + MPEG-2 + VP8 (via hantro-vpu-dec). This is the explicit broadening from libva-multiplanar's H.264-first locked scope.
- Test consumers: `vainfo`, `mpv --hwdec=vaapi`, Firefox via `media.ffmpeg.vaapi.enabled`, chromium-fourier 149 (regression check).
- Phase 1 success criterion (matching libva-multiplanar): **boolean correctness** — "libva accepted + providing access to hardware decoder for each codec." Performance metrics deferred.
- **Phase 0 task 1: recover fresnel from the SDDM greeter crash-loop** (per `~/.claude/plans/dynamic-forging-piglet.md`). Recovery is bookkept as substrate work inside this campaign, not as a separate prereq.

**Out of scope:**

- Front-end libva (API library). Backend only.
- Other hardware (ohm + ampere/boltzmann are libva-multiplanar's iterations).
- AV1 (no decoder block on RK3399 supports it).
- Performance metrics — fresnel CPU/GPU benchmarking is a separate iteration after correctness lands.
- `cros-codecs` Rust replacement (per [`user_stance_rust.md`](../../.claude/projects/-home-mfritsche-src-fourier/memory/user_stance_rust.md)).
- Bootlin / Collabora upstreaming default-deferred (per [`feedback_no_upstream.md`](../../.claude/projects/-home-mfritsche-src/memory/feedback_no_upstream.md)). Same discipline as libva-multiplanar.
- KWin / panfrost / Mali-T860 work — orthogonal until proven otherwise; a parallel `kwin-fourier-fresnel` campaign would be a separate decision.

## Process

8(+1) phase loop per [`feedback_dev_process.md`](../../.claude/projects/-home-mfritsche-src/memory/feedback_dev_process.md). Phase 0 substrate is in `phase0_findings.md`. Phase 5 review uses the sonnet-architect subagent pattern (`Plan` with `model: sonnet`).

In-session-acquired data discipline per [`feedback_replicate_baseline_first.md`](../../.claude/projects/-home-mfritsche-src-kwin-overlay-subsurface/memory/feedback_replicate_baseline_first.md): libva-multiplanar's ohm-side measurements are **reference history**, not threshold sources for fresnel-fourier cells.

## Predecessor work this campaign builds on

- **[`../libva-multiplanar/`](../libva-multiplanar/)** — five closed iterations on ohm. Read in order:
  - `README.md` — current state, codec scope, file map.
  - `phase8_iteration5_close.md` — most recent close. The iter5-end backend is the substrate fresnel-fourier starts from.
  - `phase0_findings.md` (and `phase0_findings_iter[2-5].md`) — locked-scope precedent for codec breadth and consumer matrix on ohm; useful frame-of-reference when locking fresnel-side scope.
  - `phase8_iteration1_close.md` — iter1 surface-export DMA-BUF lifecycle race + multi-resolution cache + 64-pitch alignment bugs. Likely re-surface candidates on RK3399.
- **[`../libva-multiplanar/libva-v4l2-request-fourier/`](../libva-multiplanar/libva-v4l2-request-fourier/)** — the fork itself. 12 commits ahead of bootlin tip plus iter1..iter5 work. `git log` for the actual landing record.
- **[`~/.claude/plans/dynamic-forging-piglet.md`](../../.claude/plans/dynamic-forging-piglet.md)** — fresnel SDDM greeter crash diagnosis + recovery plan. Phase 0 task 1 picks up from here.
- **`~/src/fourier_attribution/`** — ohm-only attribution matrix. The chromium-fourier WHEAT-but-fragile verdict and Cell E (vanilla Chromium 149 control) item are ohm-side context, not fresnel data.

External reference (carry-over from libva-multiplanar):

- Mozilla bug 1833354 / 1965646 (Firefox HW decode on RK35xx via libva-v4l2-request).
- Bootlin upstream `bootlin/libva-v4l2-request` — dormant since 2021.
- Linux kernel `drivers/staging/media/rkvdec/` — RK3399 rkvdec H.264/HEVC/VP9 control protocol reference.
- Linux kernel `drivers/media/platform/verisilicon/hantro_*` — RK3399-vpu-dec MPEG-2/H.264/VP8 control protocol reference.

## Repository layout

```
~/src/fresnel-fourier/                     <- this campaign (its own git repo)
├── README.md                              <- this file
├── phase0_findings.md                     <- locked research question + Phase 0 work list
├── (worklist.md, phase[2-8]*.md as phases land)
└── (the libva fork is NOT here — see ../libva-multiplanar/libva-v4l2-request-fourier/)
```

The campaign repo and the fork repo stay **separate**. fresnel-fourier commits its findings here; code changes to the backend land on the fork's `master` (or a branch named per the iteration if scope diverges from libva-multiplanar's ohm-side `master`).

Operator-facing repo URL: `git.reauktion.de/marfrit/fresnel-fourier` — created empty during scaffolding, no push until first iteration finds something worth publishing.

## Non-upstreaming default

Inherited from libva-multiplanar / `feedback_no_upstream.md`. Patches must be aligned to upstream in syntax and semantics; PR/MR/bug-report only on explicit operator instruction.

## Build infrastructure

distcc/cross-build path is the existing fleet: `aarch64crosscompiler` LXD on data, `tesla` LXD on hertz, `dcc1` on dcw3. See `reference_distcc_kernel_builds.md` for invocation. **Per the locked Phase 0 answer for libva-multiplanar (item 9), no distcc for libva builds** — libva is small and links fast, hand-build on fresnel directly. Same default applies here unless a specific reason emerges.

For chromium-fourier 149 / firefox-fourier rebuilds against fresnel-side findings, the boltzmann LXD container path from libva-multiplanar iter3 is reusable.