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>
iter1 lock's "H.264 first; MPEG-2 next" backlog item is dropped.
MPEG-2 SD/HD decodes trivially in CPU on RK3568's A55 cluster
(well under one core), so the campaign's user audience doesn't
need MPEG-2 HW path. If upstream review surfaces the question,
the answer is "H.264-only by design — CPU handles MPEG-2 fine
on this hardware."
phase0_findings_iter6.md left as historical record of what was
in-scope at that substrate time; the close doc is now the
operative carry-list source.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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>
claude-noether