4 Commits

Author SHA1 Message Date
claude-noether ec769a9687 docs: clarify Rockchip silicon across operative docs (RK3566)
PineTab2 is Rockchip RK3566 silicon, not RK3568. The hantro driver
attaches via the rockchip,rk3568-vpu DT compatible because RK3566/
RK3568 silicon is close enough to share that variant. The proper
RK3566 mainline driver target (rkvdec2 / vdpu346) has no kernel
support yet — Christian Hewitt's patch series LKML 2025/12/26/206
is unmerged.

Updated operative docs to use the consistent form:
"PineTab2 (Rockchip RK3566 silicon; hantro driver via the
rockchip,rk3568-vpu DT compatible)" or shorter variants.

Files updated:
- README.md (campaign top-level): TL;DR, deliverable, KWin link,
  hardware target, hardware listing
- firefox-fourier/README.md: tested-on line
- phase8_iteration7_close.md: hardware carry
- phase8_iteration6_close.md: hardware carry, MPEG-2 drop
  rationale
- phase0_findings_iter7.md: predecessor summary, fourier-fresnel
  description, hardware carry
- phase2_iter7_situation.md: msync hypothesis hardware reference

Historical iter1-iter5 phase docs left as-is — they're snapshots
of what the campaign believed at the time. The canonical source
for the silicon-ID correction is track_F_research_2026-05-06.md
(commit 358801b).

Not a correctness change. The campaign's empirical evidence is
unaffected — the hantro/rk3568-vpu driver path that we exercised
was always the actual decode path on PineTab2 silicon.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-06 11:39:28 +00:00
claude-noether 104abd1624 iter6 close: A∪I GREEN — per-slot request_fd binding via REINIT
Single architectural fix lands at libva-v4l2-request-fourier
commit a09c03c (`iter6 fix: per-OUTPUT-slot request_fd binding via
REINIT`). Closes both:

- candidate I (Firefox VIDIOC_QBUF EINVAL after multi-surface decode)
- candidate A (cap_pool resolution-change race) — organically
  exercised and verified on YouTube avc1 4 cap_pool_init events
  handled cleanly

Phase 1 success criterion met across all three consumer paths:
- Firefox bbb_1080p30_h264.mp4: 35s+ clean, RDD holds /dev/video1
  + /dev/media0 throughout, zero per-frame errors
- Firefox YouTube avc1 (Enhancer for YouTube forcing h264): ~95s
  sustained, zero errors, 4 cap_pool_init resolution
  renegotiations clean
- mpv vaapi-copy regression: clean 50-frame run, EOF reached

Phase 5 sonnet design review (front-loaded) refuted the pool-
exhaustion competing hypothesis via experiment, endorsed
direction 3 (REINIT). Phase 5 sonnet code review:
APPROVE-WITH-CHANGES (one comment attribution corrected).

Memory updates:
- feedback_request_fd_lifecycle.md: rewritten. iter4's
  case-against-REINIT was a DPB-payload confounder. iter6
  reinstates REINIT with per-slot binding as the correct
  discipline. Meta-lesson recorded: when a prior "rule out X"
  was about an unrelated bug, X is back on the table.

firefox-fourier/README.md: YouTube codec-negotiation note added
(Enhancer for YouTube / enhanced-h264ify needed to force avc1
since FF150 auto-negotiates AV1).

WiFi-IRQ-induced frame drops observed during YouTube playback
documented as out-of-scope system concern (decode pipeline
unaffected; presentation-schedule slips under brcm/iwlwifi IRQ
spikes).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-05 21:44:45 +00:00
claude-noether d2d9107e62 iter5 amendment: extend Firefox sandbox patch to UtilitySandboxPolicy
Real-world YouTube avc1 playback on the iter5-G binary surfaced a
seccomp violation (`syscall 29`, `0x80047C05` = `MEDIA_IOC_REQUEST_ALLOC`)
that the autonomous Phase 7G test missed because seccomp returns
ENOSYS silently and Firefox falls back to SW decode.

Two distinct gaps:
- patch-sync drift: campaign 113-line patch (broker+RDD-seccomp) had
  drifted from container 84-line patch (broker only); iter5-G shipped
  with the broker fix but no RDD seccomp fix.
- coverage gap: FF150 routes VAAPI to the Utility process; iter3's
  RDD-only seccomp allowlist never covered Utility.

Combined patch now hits three gates across two files (six hunks):
- broker: cap-filter widen + AddV4l2RequestApiDependencies + RDD wire-in
- RDD seccomp: kMediaType allow alongside existing kVideoType
- Utility seccomp: new __NR_ioctl override mirroring RDD's allowlist

Build: incremental `makepkg -e` on existing iter5-G object tree took
2:22 wall vs the 2h27m from-scratch alternative.

phase8_iteration5_close.md: appended amendment section with verdict-
gap analysis, patch breakdown, deploy-pending status.

firefox-fourier/README.md: rewrote "The problem" from 2 gates to 3
(broker + RDD seccomp + Utility seccomp); patch summary now explains
the six hunks.

Pending: pkg deploy to ohm + lsof /dev/video1 verification once
network route to ohm is restored.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-05 19:20:30 +00:00
claude-noether 080490d4a7 firefox-fourier: add user-facing README explaining quick vs proper path
Two paths for HW decode through Firefox:
1. Easy: stock Firefox + MOZ_DISABLE_RDD_SANDBOX=1 (sandbox off,
   defense-in-depth lost — OK for personal-machine use)
2. Proper: apply 0001-rdd-allow-stateless-v4l2-request-api.patch to
   firefox-150.0.1 source, build (Arch overlay or generic mach build),
   install. Sandbox stays on; HW decode works.

Patch covers all three sandbox gates discovered iter3-5:
- Broker: cap-filter widening + /dev/media* enumeration
- Seccomp: ioctl magic byte '|' (linux/media.h)

README also points at the companion libva-v4l2-request-fourier repo
which carries the libva-side fixes (request_fd lifecycle, DPB
FFmpeg-semantics, B-slice L1, multi-context safety) needed alongside
the Firefox patch.

Top-level README cross-link added.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-05 17:48:34 +00:00