mesa-patched

Arch's mesa PKGBUILD plus one backported upstream commit, rebuilt for lab (the Moonlight client). Nothing else on the network uses this — mainpc stays on its own pinned mesa.

The bug

labwc was killing Moonlight mid-stream, roughly hourly:

wp_linux_drm_syncobj_surface_v1#47: error 3: Acquire point set but no buffer attached
 - SDL Error (5): Wayland display connection closed by server (fatal)

In mesa 26.1.5, wp_linux_drm_syncobj_surface_v1 is owned by the surface (wsi_wl_surface->wl_syncobj_surface, created once in wsi_wl_surface_init), so it outlives swapchain recreation. A retiring swapchain can leave an acquire point pending on that shared object; the next commit then carries an acquire point with no buffer attached, and wlroots-based compositors treat that as a fatal protocol error and disconnect the client.

Diagnosed 2026-07-25. Three of four crashes that day landed within one second of a fresh 8BitDo uhid instance — the gamepad hotplug forces a swapchain rebuild mid-present. A fourth had no gamepad event at all, which fits: the pad is only one way to force a rebuild. An output reconfigure (kanshi re-asserting 4K120), a resize, or any VK_ERROR_OUT_OF_DATE_KHR does the same. The fix targets the object's lifetime, so it covers every trigger rather than just the pad.

The patch

0001-wsi-wayland-move-drm-syncobj-to-swapchain.patch is a clean cherry-pick of upstream mesa commit 674cbe7b, "vulkan/wsi/wayland: Move drm syncobj to swapchain." (2026-06-20). It moves the object to chain->wl_syncobj_surface, destroys it with the swapchain, and explicitly clears a retiring chain's:

if (old_chain->wl_syncobj_surface) {
   wp_linux_drm_syncobj_surface_v1_destroy(old_chain->wl_syncobj_surface);
   old_chain->wl_syncobj_surface = NULL;
}

It is not in the 26.1.x stable branch, which is why 26.1.5 still has the bug — and why downgrading to 26.1.4 would not have helped either.

Packaging notes

• epoch=3 matches CachyOS's mesa epoch, and pkgrel=2 so the result supersedes the repo's 3:26.1.5-1 instead of looking like a downgrade.
• The patch is appended last in source=(), after the loop that appends the NVK Rust crates — its checksum is the trailing SKIP in both b2sums and sha256sums. Adding it anywhere else silently misaligns every crate checksum.
• prepare() (upstream Arch's) already auto-applies any *.patch in source; do not add a second patch call.

Rebuilding by hand

podman run --rm -v "$PWD":/build:z docker.io/library/archlinux:base-devel bash -c '
  pacman -Syu --noconfirm --needed base-devel git
  useradd -m builder && echo "builder ALL=(ALL) NOPASSWD: ALL" >/etc/sudoers.d/builder
  chown -R builder /build
  su - builder -c "cd /build && makepkg -s --noconfirm --nocheck --skippgpcheck"'

Only vulkan-radeon is installed on lab — the WSI code lives in libvulkan_radeon.so. The other split packages are build output, not deployed.

Deployed state

Installed on lab and held with IgnorePkg in /etc/pacman.conf, so a routine -Syu cannot silently drop the fix and reintroduce the crash.

Revert: pacman -U the cached 3:26.1.5-1 from /var/cache/pacman/pkg and drop the IgnorePkg entry.

When to retire this

When lab's repos ship a mesa that already contains 674cbe7b — i.e. 26.2 or later, or a 26.1.x point release that backports it. Check with:

curl -s "https://gitlab.freedesktop.org/api/v4/projects/176/repository/commits?path=src/vulkan/wsi/wsi_common_wayland.c"

At that point: drop the IgnorePkg entry, -Syu normally, and archive this repo. Until then CI here is the early-warning system — a red build means Arch bumped mesa and the patch no longer applies.