marfrit
84088141fd
build and publish packages / distcc-avahi-aarch64 (push) Successful in 35s
build and publish packages / lmcp-any (push) Successful in 7s
build and publish packages / lmcp-debian (push) Successful in 6s
build and publish packages / claude-his-any (push) Successful in 7s
build and publish packages / ffmpeg-v4l2-request-aarch64 (push) Successful in 12m2s
build and publish packages / claude-his-debian (push) Successful in 9s
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.