marfrit
13a7566c34
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.