KWIN_PIVOT: campaign closed end-to-end (part 3 update)
build and publish packages / distcc-avahi-aarch64 (push) Failing after 19s
build and publish packages / lmcp-debian (push) Has been skipped
build and publish packages / lmcp-any (push) Has been skipped
build and publish packages / claude-his-any (push) Has been skipped
build and publish packages / ffmpeg-v4l2-request-aarch64 (push) Has been skipped
build and publish packages / claude-his-debian (push) Has been skipped

Three patches landed on ohm in sequence today: qt6-base-fourier
(GL_ALPHA → GL_R8 on ES 3.x, 3 sites in qtbase), kwin-fourier
(watchDmaBuf no-op test fixture), chromium-fourier patch 4/4
(V4L2 capture pool floor at 16). Each unsticks one layer.

Together they produce smooth 1080p30 H.264 playback under KDE
Plasma 6.6.4 Wayland on RK3566 PineTab2 mainline, where stock
chromium previously stalled in 3 seconds. Combined chrome CPU
~81% steady, KWin ~9%, zero GL_INVALID_VALUE during playback.

Brave's YouTube on the same compositor session also feels snappier
independently — the kwin-fourier watchDmaBuf bypass is a
general-purpose latency reduction for every wp_linux_dmabuf client
on Mali-class hardware, not chrome-specific.

The kernel-side architectural hole is the right upstream-correct
fix: vb2 / hantro / rga don't populate dma_resv exclusive fences
for V4L2 producers, so dma_buf_export_sync_file substitutes a stub
fence representing nothing real. Per-driver fence wiring (3 small
commits: vb2 helper API, hantro opt-in, rga opt-in) plus a parallel
KWin commit using poll(POLLIN) directly on the dmabuf fd is the
planned MR pair. kwin-fourier as it stands is a working diagnostic,
not the upstream-bound shape.
This commit is contained in:
2026-04-28 18:51:37 +00:00
parent 84088141fd
commit 13a7566c34
8 changed files with 144 additions and 13 deletions
+20
View File
@@ -1,5 +1,25 @@
# KWin pivot — fix the chrome-on-KWin video stall
> **2026-04-28 update part 3 — campaign closed end-to-end.** Three
> patches landed on ohm in sequence: qt6-base-fourier (GL_ALPHA →
> GL_R8), kwin-fourier (watchDmaBuf no-op), chromium-fourier patch
> 4/4 (V4L2 capture pool floor at 16). Each unsticks one layer.
> Together they produce smooth 1080p30 H.264 playback under KDE
> Plasma 6.6.4 Wayland on the box where stock chromium previously
> stalled in 3 seconds. Combined chrome CPU ~81 % steady, KWin ~9 %,
> zero GL_INVALID_VALUE in the journal during playback. Brave's
> YouTube on the same session feels markedly snappier independently
> — kwin-fourier is a general-purpose latency reduction for every
> wp_linux_dmabuf client on this hardware, not a chrome-specific
> fix. **The kernel-side architectural hole — vb2 / hantro / rga not
> populating `dma_resv` exclusive fences for V4L2 producers — is the
> right upstream-correct fix and the planned next move.** kwin-fourier
> in its current shape (blanket bypass) is a working *diagnostic
> instrument*; the upstream MR will be the kernel-side per-driver
> patch (3 commits: vb2 helper API, hantro opt-in, rga opt-in) plus
> a parallel KWin commit using `poll(POLLIN)` directly on the dmabuf
> fd instead of the `EXPORT_SYNC_FILE`+`QSocketNotifier` roundtrip.
> **2026-04-28 update part 2 — qt6-base-fourier landed, validated, did
> not fix the chrome stall.** The Qt 6 GL_ALPHA bug (qopengltextureglyphcache.cpp,
> qrhigles2.cpp, qopengltextureuploader.cpp) is real, the patch is