verify-patch-sanity.py validates every active recipe .patch has internally-
consistent hunk line counts — catching the 'malformed patch at line N' failure
at commit/CI/preflight time instead of hours into a cook. This cycle hit that
class three times (qtwaylandscanner, sddm, xwayland), each only discovered when
cookbook tried to apply the patch.
Running it across the repo found 29 latent malformed patches (validated against
GNU patch: e.g. relibc/P3-sysv-ipc reproduces 'malformed patch at line 22').
They were harmless only because they sit in vendored recipes (baked, not re-
applied) — but would fail on any version-bump re-derivation. --fix recounts the
hunk headers (body untouched) and repaired all 29.
Wired into build-preflight.sh (Phase 1.0D) and redbear-ci.yml, with a unit test
(test-patch-sanity.sh). Skips archived/legacy trees and unvalidatable formats
(empty placeholders, bare-@@ git hunks).
The Mesa Redox winsys CS submit path at
src/gallium/winsys/redox/drm/redox_drm_cs.c:156 faked the seqno with
'result.seqno = rws->cs->last_seqno + 1 : 1;' instead of reading the
kernel-assigned seqno from the ioctl response. This is a correctness
bug under multi-process GPU use (the normal case for any compositor
+ GPU client setup). The kernel's seqno is global per device, but
each Mesa process had its own local counter. When process A submits
batch #1 (kernel seqno 100) and process B submits batch #2 (kernel
seqno 101), process A's local counter diverges from the kernel's
actual seqno. Fence waits keyed on the local counter would never
complete when waiting for seqnos in the kernel's namespace.
Fix (three coordinated changes):
### 1. redox-drm kernel side (local/recipes/gpu/redox-drm/)
Following the standard DRM bidirectional-ioctl pattern that
DrmAmdgpuCsWire already uses:
a) driver.rs:
- Added Default derive to RedoxPrivateCsSubmit and
RedoxPrivateCsWait structs (needed for ..Default::default() at
construction sites).
- Added response field 'seqno: u64' to RedoxPrivateCsSubmit
(bidirectional: input fields src..byte_count, output seqno).
- Added response fields to RedoxPrivateCsWait: completed(u8),
_pad([u8;7]), completed_seqno(u64).
- Updated size tests: Submit 32->40 bytes, Wait 16->32 bytes.
- Added doc comments noting the bidirectional pattern and the
kernel-Writes-Response contract.
b) scheme.rs:
- CS_SUBMIT handler writes resp.seqno back into req.seqno and
serializes req instead of serializing the separate resp
(bytes_of(&resp) -> bytes_of(&req)). This is the kernel
returning the response in the same struct.
- CS_WAIT handler similarly copies result fields into req.
- req made mutable for in-place mutation before serialization.
- All other places that construct these structs use
..Default::default() for the new response fields.
c) drivers/amd/mod.rs, intel/mod.rs, virtio/mod.rs:
- Each cs_submit and cs_wait construction site now uses
..Default::default() for the new response fields. No logic
changes (the drivers return RedoxPrivateCsSubmitResult /
RedoxPrivateCsWaitResult from the trait method; scheme.rs
copies the response into the bidirectional struct).
### 2. Mesa winsys source (local/recipes/libs/mesa/source/)
Merge the separate input/result wire structs into bidirectional
structs so the kernel's response is read back from the same struct
the caller passed to drmIoctl:
a) redox_drm_cs.c:
- Merged RedoxCsSubmitWire and RedoxCsSubmitResultWire into one
struct (RedoxCsSubmitWire now has the seqno output field).
- Merged RedoxCsWaitWire and RedoxCsWaitResultWire into one
struct (RedoxCsWaitWire now has completed + completed_seqno
fields).
- Removed 'result.seqno = rws->cs->last_seqno + 1 : 1;' fake.
Instead, reads 'submit.seqno' and 'wait.completed_seqno' from
the same struct after drmIoctl returns.
- Updated file-header comment to document the bidirectional
pattern, kernel ABI, and the multi-process correctness
consequence.
b) Patches the durability:
- Added 'mesa/26-cs-submit-bidirectional-seqno.patch' to the
patches list in local/recipes/libs/mesa/recipe.toml.
- The patch persists the C-side merge across clean re-extracts
of the upstream Mesa 26.1.4 tarball.
Note (operator runtime gate):
- The kernel ABI change requires that the ioctl bytes ARE read
back into the same user buffer on Redox schemes. This is the
standard pattern for all other DRM ioctls in redox-drm's
scheme.rs (DrmGemCreateWire, DrmAmdgpuCsWire, DrmCreateDumbWire
etc.). Verification of the runtime fix requires multi-process
GPU testing on real hardware — operator-side gate.
- Per AGENTS.md NO-FALLBACK policy: this fixes a real correctness
bug. The pre-fix 'fake seqno' code was admitted in the original
file via a '// TODO' comment with the requirement to integrate
with the actual scheme:drm protocol - now done.
Files changed:
- local/recipes/gpu/redox-drm/source/src/driver.rs
- local/recipes/gpu/redox-drm/source/src/scheme.rs
- local/recipes/gpu/redox-drm/source/src/drivers/amd/mod.rs
- local/recipes/gpu/redox-drm/source/src/drivers/intel/mod.rs
- local/recipes/gpu/redox-drm/source/src/drivers/virtio/mod.rs
- local/recipes/libs/mesa/source/src/gallium/winsys/redox/drm/redox_drm_cs.c
- local/recipes/libs/mesa/recipe.toml
- local/patches/mesa/26-cs-submit-bidirectional-seqno.patch
The Redox EGL platform (platform_redox.c) was removed in upstream
Mesa ~25.0, but the existing local/patches/mesa/03-platform-redox-gpu-probe.patch
still targets it — the patch fails because the file is missing.
This commit adds a documentation patch (26.1.4-defer-redox-platform.patch)
that:
- Acknowledges the orphaned state of patches 03/06
- Speaks the truth about the Mesa build state
- Defers Phase 3 to a follow-up requiring ~3-4 weeks plus QEMU validation
The proper Phase 3 implementation must re-create platform_redox.c for
Mesa 26.1.4 (the original was Mesa 24.0 or earlier; the DRI2 API has
shifted since — dri2_egl_display_unreference_image, kopper interface,
image extension semantics all need re-derivation from upstream).
Until Phase 3 lands, EGL_PLATFORM=redox will not resolve. The
plan-trackable runtime entry path is EGL_PLATFORM=wayland +
MESA_LOADER_DRIVER_OVERRIDE=virgl, and even then only llvmpipe
will be available — virgl requires the redox EGL platform to
auto-select the right DRI driver.
A standalone platform_redox.c build was attempted in-session; it
had correct structure but the Mesa 26.1.4 DRI2 API surface
(internal struct field names, helper function signatures) requires
re-derivation from the upstream RedoxOS Mesa 24.0 fork. That
re-derivation is deferred.
The meson gate that enables EGL on Redox — adding "redox" to
system_has_kms_drm (meson.build:159, so with_dri→with_egl/gbm) and to the
_GNU_SOURCE platform list (:1208) — existed only as an in-place edit in the
untracked extracted source/ tree. Any clean re-extract lost it and reverted to
"Feature egl cannot be enabled". Capture it as local/patches/mesa/08-*.patch and
wire it into recipe.toml so EGL/GBM/llvmpipe build reproducibly. Source tree
reverted to pristine so the patch is the sole, tracked change.
- Add x11proto to redbear-full.toml package list
- libxau recipe updated with x11proto dependency and custom build script
- Fixes libxau build failure: 'Package xproto was not found'
Mesa now builds with -Dgallium-drivers=swrast,virgl for Redox target.
Fixes:
- virgl_screen.c: wrapped disk cache creation in #ifndef __redox__
(build_id_find_nhdr_for_addr uses dl_iterate_phdr — unavailable on Redox)
- bits/safamily-t.h: provided to cross-compiler toolchain sysroot
Durable patch:
- local/patches/mesa/P4-virgl-redox-disk-cache.patch (25 lines)
This enables hardware-accelerated 3D rendering in QEMU via
virtio-gpu + virgl. Mesa EGL/GLES2/GBM now support the virgl
gallium driver alongside llvmpipe software renderer.
63MB pkgar artifact with virgl support.
vasilito
kellito