docs(3d): round 3 status (winsys BO fix, null+8 fix, KWin device, xwayland)

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

@@ -620,7 +620,94 @@ work is now committed:
   process is untested. A real QEMU session with Xwayland
   bridging would be the first validation step.
 
-## 11. Operating rule
+## 11. Round 3 implementation status (2026-07-25+)
+
+This revision captures what was implemented in the systematic
+follow-up to the Round 2 commit. Round 3 focused on completing
+the Mesa redox gallium winsys, the Qt6 Wayland null+8 fix, the
+KWin DRM device discovery path, and the Xwayland wiring.
+
+- **Mesa redox winsys BO byte-count fix**: the winsys'
+  `redox_drm_bo_create` was using `templat->width0` as the
+  allocation size, which is wrong for 2D textures (would
+  allocate only the width of a 1×1×1 buffer for a 100×100×1
+  texture) and breaks for compressed formats. The new
+  `redox_resource_byte_count` helper computes the correct
+  byte count based on the format (using
+  `util_format_get_blocksizebits` / `util_format_is_compressed`
+  for compressed and uncompressed), the dimensions
+  (`width0 × height0 × depth0 × array_size`), and the face
+  count (× 6 for cube maps). The result is passed to both
+  `redox_gem_create` and stored in `bo->size` for later
+  `redox_gem_map` use.
+
+- **Qt6 Wayland null+8 root-cause fix**:
+  - qtwaylandscanner: the generated `init_listener()` now
+    wraps `wl_<interface>_add_listener(...)` in a `if (m_<interface>)`
+    guard. When the upstream proxy is NULL (the bind failed
+    or the global hasn't been emitted), the call becomes a
+    no-op and the Qt frontend falls back to the standard
+    "global not available" code path. We also added a guard
+    around the `init_listener()` call inside `init()`.
+  - libwayland: the userland library now guards every entry
+    point that dereferences a `wl_proxy*` (wl_proxy_add_listener,
+    wl_proxy_get_version, wl_proxy_set_user_data,
+    wl_proxy_get_user_data, wl_proxy_destroy) with an
+    `if (!proxy) { errno = EINVAL; return ...; }` check. The
+    matching server-side functions (wl_resource_set_user_data,
+    wl_resource_get_user_data, wl_resource_get_version)
+    also have NULL guards. This is the second NULL-guard site
+    that the qtwaylandscanner-generated code relies on.
+
+- **KWin DRM device discovery**: KWin's `drm_backend.cpp` uses
+  libudev to enumerate `/dev/dri/renderDN`. On Redox, the
+  DRM device is at `/scheme/drm/card0`. We now set
+  `KWIN_DRM_DEVICES=/scheme/drm/card0` in
+  `redbear-full.toml` (was already there; now also documented
+  in the sddm.conf and 21_sddm.service envs). A
+  `/dev/dri/renderD128` symlink that points at the scheme is
+  the planned fallback for libudev-based discovery. The
+  comment in redbear-full.toml explains that libudev 252+
+  may ignore `KWIN_DRM_DEVICES` if the device is detectable
+  via udev — the symlink fallback covers that case.
+
+- **Xwayland TODO expanded**: the recipe's `#TODO` comment
+  now lists 5 specific runtime validation steps: live X
+  client under Wayland, XInput2 input forwarding, Xrender +
+  Xshm extensions, screenshot capture, and the GLX/DRI3
+  acceleration path. The recipe is `recipes/wip/wayland/
+  xwayland/recipe.toml`; a duplicate of the recipe is in
+  `local/recipes/wayland/xwayland/` (per the WIP policy
+  "if Red Bear depends on a WIP subsystem long-term, prefer
+  moving the maintained shipping version under
+  `local/recipes/`"). Build dependencies are complete
+  (libepoxy, libxkbfile, libxfont2, libxau, libx11, libxcb,
+  pixman, libxcvt, libxshmfence, freetype2, libwayland,
+  wayland-protocols, openssl1, etc.).
+
+### What was NOT done in Round 3 (Round 4+ follow-up)
+
+- The canonical `build-redbear.sh redbear-full` run to
+  validate the Round 2+3 changes. The winsys improvements and
+  the wayland null-guard changes are committed but uncompiled
+  in a fresh image. The Mesa configure step needs to complete
+  (libclc dep is in place) and then produce `iris_dri.so` /
+  `radeonsi_dri.so` for the winsys to be runtime-linked.
+
+- A real Qt6 Wayland client runbook execution. The static
+  diagnosis and the patches are in place; a fresh
+  libwayland→qtbase→qtdeclarative→qtwayland forced rebuild
+  is needed to confirm the fix. 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.
+
+- Hardware validation: still zero bare-metal Intel/AMD
+  runs. The kernel Intel path treats `0x7D51` as MTL Gen14
+  with GGTT + render ring + i915 UAPI bridge; the AMD path
+  has the amdgpu UAPI bridge but no real GFX ring yet.
+
+## 12. Operating rule
 
 > Red Bear should speak about Mesa 3D support in the same way it speaks
 > about any other first-class subsystem.