From 078cd912984a3c07c6daad07bbea3449bff429ea Mon Sep 17 00:00:00 2001 From: vasilito Date: Sun, 26 Jul 2026 08:29:07 +0900 Subject: [PATCH] docs(3d): round 3 status (winsys BO fix, null+8 fix, KWin device, xwayland) --- local/docs/3D-DRIVER-PLAN.md | 89 +++++++++++++++++++++++++++++++++++- 1 file changed, 88 insertions(+), 1 deletion(-) diff --git a/local/docs/3D-DRIVER-PLAN.md b/local/docs/3D-DRIVER-PLAN.md index 6d519c8c0e..aab6bafbed 100644 --- a/local/docs/3D-DRIVER-PLAN.md +++ b/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__add_listener(...)` in a `if (m_)` + 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.