fourier — journey

Chronological account of how a single-patch chromium V4L2 dispatch unlock turned into a 4-series + RFC + 3 upstream draft campaign. Each step uncovered the next layer's contributing bug. Index: fourier.

1. Started as a single chromium V4L2 dispatch unlock — flip kAcceleratedVideoDecodeLinux default + re-allow direct EGL/GLES2 in WaylandSurfaceFactory. Two patches, “does it decode?”.
2. Discovered every NV12 modifier on panfrost is external_only → wrote chromium patch 3 (NV12 EXTERNAL_OES). Without this, sampling NV12 from a panfrost dmabuf goes through a path that doesn't advertise the modifier correctly.
3. Validated patch 3 → discovered chrome stalled at 3 s under KWin. Different bug, deeper layer.
4. Attributed stall to Qt 6 glTexImage2D(GL_ALPHA) errors — GL_ALPHA is deprecated as an internalFormat in OpenGL ES 3.0; Qt 6 was hard-coding it via QT_CONFIG(opengles2) with no runtime ES check. Wrote qt6-base-fourier (3 patches).
5. Stall persisted at 6 s → identified KWin's Transaction::watchDmaBuf parking transactions on stub fences. The compositor was waiting for a fence the producer never signalled.
6. Wrote kwin-fourier 0001 (diagnostic bypass) → stall persisted at 22 s → identified the V4L2 capture pool depth equal to chrome's pipeline depth. Decoder running, compositor working, but the pipeline deadlocked itself on buffer count.
7. Wrote chromium patch 4 (capture pool floor at 16) → end-to-end smooth playback on ohm. ~81 % chrome CPU vs ~131 % pre-patch baseline.
8. Drafted upstream-shape kwin patch 0002 (poll dmabuf fd directly instead of going through EXPORT_SYNC_FILE + QSocketNotifier), vb2-dma-resv RFC (3-patch kernel series — the architectural correction that makes the kwin wait premise actually true), and the Qt 6 bug report body.
9. Restructured public github repo from chromium-fourier → fourier with sibling subdirs (chromium-fourier/, qt6-base-fourier/, kwin-fourier/, docs/, tools/). The campaign needed a name that reflected what it actually was.
10. Mesa Syyuu regression on fresnel diagnosed and worked around — mesa 26.0.5 introduced a panfrost GLX regression on Mali-T860 that crashes sddm-greeter-qt6. Pinned to 26.0.3 via IgnorePkg. Separate from fourier work, captured here because it surfaced during a fresnel install of fourier packages.
11. firefox-fourier patch 3 runtime defect identified and corrected (today, 2026-04-28; rebuild pending on boltzmann). MOZ_LOG showed patch 3 only walked the generic codec's hw_configs; libavcodec on ALARM registers v4l2_request as separate AVCodec entries (h264_v4l2request etc.). Corrected to probe by name first, fall back to hw_configs.

The investigation thread is documented in gitea/marfrit-packages under:

• arch/chromium-fourier/NEXT.md — campaign chronology, including the 2026-04-28 closing section
• arch/chromium-fourier/KWIN_PIVOT.md — the discovery story for the qt6 + kwin layers
• docs/dmabuf-zero-copy.md (in github.com/marfrit/fourier) — the panfrost external_only finding and how it cascaded into chromium patches 2 + 3

Every time a layer was patched, the next layer's contributing bug surfaced. The campaign was over when all four layers (chromium, Qt 6, KWin, the V4L2 capture pool depth) were patched on the same machine, on the same kernel, on the same compositor.

The vb2-dma-resv RFC is the only piece that adjusts a fifth layer (the kernel video producer), and it's a correctness patch rather than a gating one — kwin-fourier 0002 already works without it; the RFC just removes the need for the workaround.