Two prior root-cause hypotheses were posted then overturned during
iter1 of dmabuf-modifier-triage:
1. kwin-fourier 0001 watchDmaBuf bypass — exonerated by stock-kwin
A/B (both compositor variants produce green).
2. mpv vo_dmabuf_wayland.c plane-semantics — exonerated by Phase 2
source-read of mpv 0.41.0 + Kwiboo b57fbbe (both pieces of code
read straight; the WAYLAND_DEBUG fd-mismatch trace is most likely
libwayland's wl_closure_marshal dup_cloexec'ing the fd at marshal
time and printing the post-dup value).
Real layer back open. Four candidates filed in
dmabuf-modifier-triage#1 comment 252.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Campaign reopen — iter8's "campaign-closing" status was contingent on
"mpv --hwdec=vaapi smooth", which doesn't hold against fresh-install
interactive testing. iter9 single-track scope:
- Bug #1 (libva-v4l2-request-fourier#1) only
- mpv H.264 fresh-login through ≥30s of decode without any of: cap_pool
double-init, REQBUFS EBUSY, REINIT bad-fd, OUTPUT ENOMEM
- Phase 0 will source-read cap_pool + request_pool + iter6 REINIT,
build a vo=null reproduction harness, prepare bisect against iter5
baseline, and a libva-direct C probe for minimal repro
Bug #2 (presentation green) is dmabuf-modifier-triage's job — peer
campaign opened 2026-05-08 at ~/src/dmabuf-modifier-triage/. README
cross-link now points at it.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
marfrit/libva-multiplanar#1 — dmabuf-wayland↔KWin presentation handoff
produces solid green on ohm independent of decoder backend. Updated
the Known issues at iter8 production tip section to point at the
issue instead of saying "Not yet filed".
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Two bugs uncovered in fresh-install interactive mpv testing on ohm
2026-05-08, immediately after the libva-v4l2-request-fourier-1.0.0.r280.65969da-1
package landed on [marfrit]:
1. libva cap_pool / REQBUFS / iter6-REINIT lifecycle cascade — filed
marfrit/libva-v4l2-request-fourier#1. Probe-context + decode-context
cap_pool double-init, EBUSY on REQBUFS (no STREAMOFF between),
iter6 REINIT bad-fd, OUTPUT queue ENOMEM. Phase-5-sonnet-C4 from
iter5 was prescient about this race.
2. dmabuf-wayland↔KWin presentation handoff produces solid green —
independent of libva (also reproduces with ffmpeg's V4L2 request
hwaccel). vo=gpu shows correct picture, so decoder is fine.
Likely modifier/pitch handshake regression between iter5 close
2026-05-05 and now. Not yet filed; needs separate triage.
Iter5/8 close claims of "mpv --hwdec=vaapi smooth" do not hold against
fresh-install + fresh-Plasma-session interactive testing. The working
HW-decode workflow on ohm right now is:
mpv --hwdec=v4l2request --vo=gpu fourier-test/...
Both issues must be triaged before any future iteration claims a
clean ohm path.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
fresnel-fourier opened 2026-05-07 at ~/src/fresnel-fourier/ as an
independent 8(+1) loop. RK3588 stays "no campaign yet".
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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>
TL;DR section at the top covers:
- What libva is (standard userspace shim, backends per hardware,
what v4l2_request is in this lineage)
- Why firefox-fourier exists (Firefox 150 RDD sandbox blocks
/dev/media* + linux/media.h ioctls; the ~50-line patch opens
just what V4L2-stateless decoders need)
- Sister fourier-series campaigns: kwin-fourier (compositor /
scanout-plane fixes) + chromium-fourier (Chromium VAAPI on aarch64
+ GL-stack workarounds for Mali-G52/Panfrost)
Skim-friendly intro for new readers; the rest of the README stays
the campaign-discipline detail.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Phase 1 locked F (Firefox RDD sandbox verify-by-patch) and A (frame-11
EINVAL diagnose) running in parallel on a single firefox-fourier build.
Track F: GREEN. Patched Firefox 150.0.1 (firefox-fourier, pkgrel=1.1)
launches on ohm WITHOUT MOZ_DISABLE_RDD_SANDBOX=1 and engages our
libva-v4l2-request backend end-to-end. Three patches needed (Phase 2
identified one and deferred two):
- Broker policy (SandboxBrokerPolicyFactory.cpp): allow /dev/media*,
extend cap-filter to admit stateless decoders that lack M2M caps.
- Seccomp policy (SandboxFilter.cpp): allow ioctl magic byte '|'
for <linux/media.h> request-API ioctls.
- Driver (media.c): replace select() with poll() — Mozilla's RDD
seccomp common policy admits poll/ppoll/epoll_* but not
select/pselect6. Driver-side fix preferred; smaller surface,
portable across sandbox policies, and poll() is the modern API.
Track A: REPRODUCES + DIAGNOSED. Frame-11 EINVAL fires deterministically
on a single-slice P-frame (slice_type=0, frame_num=5, post-IDR) — the
exact iter1/iter2 carryover signature, confirming it isn't environmental.
Y2 instrumentation (in v4l2_ioctl_controls) now logs num_controls /
error_idx / per-control id+size on EINVAL. Sizes match kernel UAPI;
error_idx == num_controls is the kernel's "all bad / no specific control"
sentinel — it's a request-level rejection, not a single-field violation.
Fix is iter4's lock; rig + Y2 in place for fast iter4 turnaround.
Build infrastructure introduced: firefox-fourier LXD container on
boltzmann (RK3588 aarch64, persistent, ssh -J boltzmann
builder@firefox-fourier). Upstream Arch x86_64 wasi packages installed
to work around 4-year-stale ALARM versions. PGO generation crashes at
exit (LXC has no display); obj/dist/ tarball used as the deployable
artifact instead of the pacman package.
Phase 6 surprises captured in phase6_iter3_findings.md: malformed
first-cut patch (descriptive vs numeric hunk headers), --enable-v4l2
isn't a Mozilla 150 flag (auto-set on aarch64+GTK), Mozilla 2025 PGP
key rotation, ALARM-stale wasi, onnxruntime missing in ALARM, and the
"no tricks" lesson (revert workarounds first when redirected).
Carries to iter4 substrate: Track A fix is the natural lock; mpv
libplacebo --vo=gpu segfault stays as separate iter4 candidate.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Single-question campaign — make multi-planar libva accepted by VA-API
consumers on Rockchip hantro RK3568 (PineTab2/ohm first iteration).
Backend only, success criterion is boolean correctness, performance
deferred. Substrate carried over from libva-v4l2-request-fourier
STUDY.md (commit e0acc33 in the fork) plus locked decisions from the
2026-05-04 setup exchange.
Fork lives as a subdirectory: libva-v4l2-request-fourier/ (separate
git repo, origin marfrit/libva-v4l2-request-fourier, upstream
bootlin/libva-v4l2-request).
Empty Gitea repo created at git.reauktion.de/marfrit/libva-multiplanar;
local origin remote set, no push yet (per operator instruction —
wait for publish-worthy state).