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.
0002's upstream-shape patch turned out to be semantically equivalent to
stock (sync_file snapshots fences at export, polling the dmabuf fd tracks
later-added fences — the patch swaps one ioctl for one F_DUPFD with a
behaviour change Mutter explicitly moved away from on amdgpu). Hosts
running 0002 are effectively stock and stall during V4L2 stateless
playback because the producer doesn't populate dma_resv exclusive fences,
so the sync_file is a stub and KWin waits forever.
0001 (bypass the watchDmaBuf wait entirely) is the working downstream
carry. Trade-off is that frames can present before the producer signals,
but on V4L2 stateless hardware where no fence is populated at all,
there's nothing to wait for in practice.
Upstream fix lives in the linux-media RFC (vb2 dma_resv producer fences,
sent 2026-04-29). Once that lands and producer drivers opt in, the
0001 carry can be retired and the upstream-shape 0002 reconsidered.
Both patches stay on disk; 0002 is not being upstreamed (MR 9157 closed
on reviewer feedback).
0002-transaction-poll-dmabuf-fd-directly-upstream-shape.patch is the
form we'll be sending to invent.kde.org/plasma/kwin (see
upstream-submissions/kwin-fourier/kde-mr-body.md). Same observable
behavior as 0001 (skip the EXPORT_SYNC_FILE round-trip), cleaner
shape: dup() the dmabuf fd and hand it to TransactionFence directly
instead of bypassing the wait entirely.
0001 is kept on disk for reference; carry could revert to it if the
upstream-shape MR runs into review issues.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Mirror github.com/marfrit/fourier kwin-fourier/0002 +
README update to the local Arch package source. PKGBUILD
unchanged — still applies 0001 (the diagnostic bypass).
The 0002 patch (poll dmabuf fd directly, drop the
EXPORT_SYNC_FILE + sync_file roundtrip) is staged for
validation; when validated, swap the source array entry in
PKGBUILD from 0001 to 0002 and rebuild.
Hypothesis under test: KWin's Transaction::watchDmaBuf calls
DMA_BUF_IOCTL_EXPORT_SYNC_FILE on every plane of every imported
dmabuf and parks the transaction on a QSocketNotifier(POLLIN)
waiting for that sync_file. On V4L2 hantro CAPTURE buffers (RK3566
mainline 6.19, panfrost mesa 26.0.5) the resulting fence either
never signals or signals so late that chrome's 6-buffer V4L2
capture pool exhausts at ~6s, hard-stalling the decoder. mpv with
gpu-next slideshows at 76% drop. weston A/B with same chrome v4
binary plays through clean — KWin's watchDmaBuf is the suspect.
This experiment patches watchDmaBuf to no-op. Wayland clients are
required by spec to ensure buffer contents are complete before
wl_surface.attach+commit, so the fence-wait is a defensive
optimization for misbehaving clients, not a correctness primitive.
If chrome plays through end-to-end at the recorded 34.7% combined
CPU number with this patched KWin, the bug is confirmed and the
upstream fix can be refined (timeout, V4L2-source skip, or use the
dmabuf fd directly in the QSocketNotifier instead of an extra
exported sync_file).
KWIN_PIVOT.md (in chromium-fourier/) carries the discovery thread.
test0r
marfrit