After the rename, source URLs and extracted-dir refs that used
$pkgname-$pkgver were producing kwin-fourier-6.6.4.tar.xz etc. which
KDE doesn't ship. Use a separate _upname/hardcoded value for the
upstream artifact.
kwin-fourier: introduce _upname=kwin, use everywhere the upstream
dir/tarball name is referenced (source URL, prepare
patch -d, cmake -S)
qt6-base-fourier: $_pkgfn=${pkgbase/6-/} produced 'qtbase-fourier'
with the rename. Hardcode _pkgfn=qtbase.
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.
Three small runtime checks in qtbase 6.11.0:
1. src/opengl/qopengltextureglyphcache.cpp createTextureData() and
load_glyph_image_to_texture() — the `#else` branch (active when
qtbase is built with QT_CONFIG(opengles2), every aarch64 distro)
hard-codes GL_ALPHA without checking the runtime context's ES
version. Replace with `useR8 = ctx->format().majorVersion() >= 3`
so ES 3+ contexts get GL_R8 + GL_RED.
2. src/gui/rhi/qrhigles2.cpp toGlTextureFormat() RED_OR_ALPHA8 case
— gated only on caps.coreProfile. Extend with
`caps.gles && caps.ctxMajor >= 3`.
3. src/opengl/qopengltextureuploader.cpp Format_Alpha8 and
Format_Grayscale8 cases — short-circuit on `context->isOpenGLES()`
before reaching the swizzle fallback. Restrict to ES 2 only so
ES 3+ falls through to the existing TextureSwizzle path.
Discovered while validating chromium-fourier patch 3/3 (NV12
EXTERNAL_OES) on ohm. The chrome stall, VLC vout init failure and
mpv "could not initialize video chain" all share this Qt 6 root
cause: every Qt application running on Mali / panfrost / panthor
under a KWin Wayland session emits glTexImage2D(GL_ALPHA) on every
text-glyph cache upload, mesa returns GL_INVALID_VALUE, the
compositor's frame-callback path stalls, and every wayland video
client deadlocks behind it.
PKGBUILD inherits from extra/qt6-base 6.11.0-2 with arch+=aarch64,
epoch=1 to dominate Arch's pkgrel until upstream lands the fix.
qt6-base-cflags.patch and qt6-base-nostrip.patch carried verbatim
from upstream packaging.
KWIN_PIVOT.md (in chromium-fourier/) carries the full diagnosis
thread.
test0r
marfrit