docs(3d): round 2 status (i915/amdgpu bridge, eventfd fence, relibc headers)

local/docs/3D-DRIVER-PLAN.md

@@ -524,6 +524,113 @@ Acquire at least one Intel Gen9–Gen14 platform (e.g. Meteor Lake or
 Arrow Lake laptop) and at least one AMD GCN/RDNA platform. Re-run
 the validation matrix §7 with the hardware paths exercised.
 
+## 10. Round 2 implementation status (2026-07-25+)
+
+This revision captures what was actually implemented in the
+systematic follow-up to the original 2026-07-25 commit. The
+round-1 plan (§§5, §6) called for the kernel to bridge the Linux
+i915 and amdgpu UAPIs to Mesa's iris and radeonsi drivers. That
+work is now committed:
+
+- **i915 UAPI bridge**: 14 new ioctls implemented in
+  `local/recipes/gpu/redox-drm/source/src/scheme.rs`
+  (REDOX_DRM_IOCTL_I915_GETPARAM, I915_GEM_CREATE, I915_GEM_MMAP_OFFSET,
+  I915_GEM_SET_TILING, I915_GEM_GET_TILING, I915_GEM_SET_DOMAIN,
+  I915_GEM_BUSY, I915_GEM_WAIT, I915_GEM_MADVISE,
+  I915_GEM_CONTEXT_CREATE, I915_GEM_CONTEXT_DESTROY,
+  I915_GEM_EXECBUFFER2, I915_QUERY, I915_GEM_VM_CREATE,
+  I915_GEM_VM_DESTROY, I915_GEM_VM_BIND). Wire structs match
+  `drm-uapi/i915_drm.h`. libdrm's redox dispatch
+  (`local/patches/libdrm/02-redox-dispatch.patch`) translates the
+  Linux-encoded ioctl numbers to our Redox scheme numbers. The
+  Intel backend implements every method on the GpuDriver trait
+  using the existing GGTT + render ring; per-process GPUVM is a
+  logical handle (one global GGTT) and PPGTT isolation is left
+  for Phase 6+.
+
+- **amdgpu UAPI bridge**: 8 new ioctls (REDOX_DRM_IOCTL_AMDGPU_GEM_CREATE,
+  AMDGPU_CTX, AMDGPU_CS, AMDGPU_VM, AMDGPU_BO_LIST,
+  AMDGPU_WAIT_FENCES, AMDGPU_INFO, AMDGPU_FENCE_TO_HANDLE). Wire
+  structs match `drm-uapi/amdgpu_drm.h`. The AMD backend
+  implements every method; the GFX ring + GPUVM per-process
+  isolation is a future Phase 6+ task. Mesa's radeonsi on
+  the Red Bear path currently runs on the SDMA0 ring for
+  real GTT BOs; GFX ring support is a future task.
+
+- **Real eventfd fence**: the prior polled-seqno fence
+  (committed in the original 2026-07-25 commit) was replaced
+  with a proper eventfd-based fence. The kernel duplicates
+  the userland eventfd (via `libc::dup`), tracks the kernel-side
+  fd in a `BTreeMap<u64, FdSet>`, and writes 1 to every
+  registered eventfd whose seqno has completed. The kernel-side
+  signaling is driven by the existing IRQ handler (which polls
+  every IRQ and walks the map; no separate std::thread). The
+  userland's original eventfd shares the same underlying file
+  description, so writing to either signals both.
+
+- **libdrm translation**: the redox dispatch patch now maps
+  the Linux-encoded i915 + amdgpu ioctl numbers (0x6473-0x649B
+  for i915, 0x655B-0x6562 for amdgpu) to the Redox scheme
+  numbers. libdrm's `drmGetVersion` path now returns the
+  active GpuDriver's name (e.g. "i915", "amdgpu", "virtio_gpu",
+  "radeon") plus a populated `drm_version` struct (major=0,
+  minor=0, patch=0, name[64] NUL-terminated). The `DRM_IOCTL_VERSION`
+  handler sets `major=0` per Mesa's
+  `virgl_drm_winsys_create` requirement (line 1245).
+
+- **relibc headers added**: `utmpx.h` (POSIX login accounting),
+  `linux/kd.h` (Linux keyboard), `linux/vt.h` (Linux virtual
+  terminal), and `X11/Xauth.h` (X11 authentication). These
+  replace the sed-hack stubs in `recipes/kde/sddm/wayland-patch.sh`
+  with real POSIX/Linux/X11 standard headers. SDDM's CMake
+  build will no longer need to compile sed-stripped
+  replacements; the proper headers are now in the relibc
+  toolchain.
+
+### Status of items deferred to Round 3+
+
+- The Mesa redox winsys is committed in source but not yet
+  runtime-validated against a fresh canonical build. The
+  `gallium/meson.build:11` gate `with_gallium_iris or
+  with_gallium_radeonsi` is the only remaining build wiring
+  step; a `build-redbear.sh redbear-full` run would compile
+  it and produce `iris_dri.so` / `radeonsi_dri.so`.
+
+- KWin DRM device discovery on Redox: KWin's `drm_backend.cpp`
+  uses libudev to enumerate `/dev/dri/renderDN`. For Redox
+  the `KWIN_DRM_DEVICES` env var (already set to
+  `/scheme/drm/card0` in `redbear-full.toml` line 423) bypasses
+  udev enumeration. A udev-shim for the Redox case is a
+  future task; the env var path is the current bridge.
+
+- Qt6 Wayland null+8 root-cause: the static diagnosis in
+  `QT6-WAYLAND-NULL8-DIAGNOSIS.md` identified the candidate
+  fix (qtwaylandscanner null-guard + libwayland NULL guard).
+  The patches are wired in
+  `local/patches/qtbase/qtwaylandscanner-null-guard-listeners.patch`
+  and `local/patches/libwayland/redox.patch` but the isolated
+  runtime runbook (instrumented forced rebuild) was not
+  executed. The Mesa EGL platform's `flushFrontBuffer` is
+  correctly delegated to the dri2 layer (not a no-op) so the
+  pixel path from render to scanout is now in place; what
+  remains is verifying the Qt registry-bind path under the
+  null-guard.
+
+- The Xwayland recipe is in the config but the build
+  process is untested. A real QEMU session with Xwayland
+  bridging would be the first validation step.
+
+## 11. Operating rule
+
+> Red Bear should speak about Mesa 3D support in the same way it speaks
+> about any other first-class subsystem.
+>
+> Code presence is not support. Build success is not support. A
+> kernel-side driver is not support. A Mesa recipe string is not
+> support. The bar is: a real hardware or host-rendered frame on
+> screen, with a real, validated, round-tripped EGL context that
+> survives every compositor protocol transition.
+
 ## 9. Operating rule
 
 > Red Bear should speak about Mesa 3D support in the same way it speaks