12 Commits

Author SHA1 Message Date
claude-noether 97f6bf2c6e README: refresh dmabuf-wayland green known-issue with current state
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>
2026-05-08 20:43:19 +00:00
claude-noether c331519507 iter9 phase 0: lock cap_pool/REQBUFS/REINIT cascade as the question
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>
2026-05-08 14:01:47 +00:00
claude-noether 16f95235b9 README: link the dmabuf-wayland green issue to its filed tracker
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>
2026-05-08 13:41:40 +00:00
claude-noether 20b3dd4d87 README: known issues at iter8 production tip — cap_pool cascade + dmabuf-wayland green
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>
2026-05-08 13:38:07 +00:00
claude-noether f778faea50 README: point Hardware target's fresnel line at the new fresnel-fourier peer campaign
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>
2026-05-07 20:11:26 +00:00
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 067a221bc6 README: add TL;DR explaining libva, firefox-fourier, sister campaigns
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>
2026-05-05 18:16:59 +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
marfrit 8e6d9e6966 Iteration 5 close — A+G+B+E all GREEN
Heavyweight four-track iteration. All Phase 1 success criteria met:

- Track A (DEBUG sweep): ~339 lines of iter1/iter3/iter4 instrumentation
  removed across 7 fork commits. Driver builds clean; per-frame log
  noise zero (1 v4l2-request line per 2000-frame stress).

- Track G (PGO-disabled Firefox rebuild): firefox 150.0.1-1.1 built
  on boltzmann (single-pass non-PGO, ~2h27m). 68.7 MB pkg, 169 MB
  libxul (21× smaller than iter3 PGO-instrumented). 2.7× faster
  decode through firefox-fourier sandbox.

- Track E (multi-context): LAST_OUTPUT_* moved from process-global
  static to per-driver_data. Two concurrent mpv with 2s stagger
  both decode clean.

- Track B (libplacebo segfault): 35s mpv --vo=gpu, 0 segfaults
  (mpv falls through to GLES via Panfrost gracefully).

Phase 5 sonnet review came back YELLOW with 4 caveats; 3 resolved
in code (additional 107-line sweep, readback_warned removed),
1 documented as iter6+ candidate (cap_pool resolution-change race
latent under untested consumer probe patterns).

iter5-end driver sha256: 4bed52ec5d44b389. firefox-fourier 1.1
sha256: aa94c7290ee7be76. README iteration table updated.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-05 17:39:35 +00:00
marfrit 67494ae7ee Iteration 4 close — Track A locked, three-iteration carryover resolved
The iter1+iter2+iter3 frame-11 EINVAL is empirically eliminated. mpv
direct stress test on ohm via patched libva-v4l2-request-fourier:

  RequestBeginPicture:     2130
  RequestSyncSurface:      4254
  S_EXT_CTRLS EINVAL:      0
  Unable to set control(s): 0
  Generic EINVAL:          0
  ENETDOWN:                0

2130 frames at 24 fps = real-time HW decode (>98% of 2160-frame max
in 90 seconds wall time). Track A's Phase 1 success criterion crushed.

Three correctness fixes (4 fork commits):
- 74d8dd1: DPB fields=V4L2_H264_FRAME_REF + skip stale entries
- 385dee1: fresh request_fd per frame (THE load-bearing fix)
- b81ce69: B-slice L1 reflist .fields copy-paste

Plus diagnostic instrumentation (a12d299, 4892656, f21bdf0) deferred
to iter5 sweep alongside earlier iter1/iter3 instrumentation.

Three new memory entries: kernel obfuscation extends to compound TRY,
request_fd lifecycle (fresh per frame), FFmpeg as empirical authority.
README iteration table updated.

Carries to iter5 substrate: DEBUG sweep, mpv libplacebo segfault,
multi-context libva safety, PGO Firefox rebuild, eventual upstream
prep (Mozilla bug + bootlin libva-v4l2-request).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-05 14:29:43 +00:00
marfrit f91469abe3 Iteration 3 close — F GREEN, A reproduced + diagnosed for iter4
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>
2026-05-05 12:56:34 +00:00
marfrit affc1752e0 Initial campaign substrate: README + phase0_findings
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).
2026-05-04 08:10:03 +00:00