From 0c402cc7388d8d2907dcafc92fd511abbeb06018 Mon Sep 17 00:00:00 2001 From: vasilito Date: Sun, 26 Jul 2026 21:28:52 +0900 Subject: [PATCH] 3D-DRIVER-PLAN: document Round 7 implementation completion Updates the Round 7 action item table to reflect what was implemented in the commit sequence 4c4a73, f2c4b6, 76313e, 7fde22, cbbdad: * mesa meson.build symbol rename (commit 4c4a73) * I915_GEM_VM_BIND dead path + I915_GEM_MADVISE type fix (commit 4c4a73) * AMD gem_create ensure_gem_gpu_mapping (commit 4c4a73) * i915 bridge real implementations: tiling, domain, busy, wait, vm_bind, query, execbuffer2 seqno tracking, register_fence_eventfd (commit f2c4b6) * amdgpu bridge real implementations: ctx, cs, vm, bo_list, wait_fences, info, fence_to_handle, register_fence_eventfd (commit 76313e) * test-virgl-qemu.sh blob=true fix for QEMU \u22658.0 (commit 7fde22) * zwlr_layer_shell_v1 + zwlr_output_manager_v1 in redbear-compositor (commit cbbdad) Validation matrix now shows mesa iris (HW) and mesa radeonsi (HW) as 'real' (source-confirmed) with runtime validation pending the canonical build-redbear.sh redbear-full run. Remaining deferred items called out: Mesa EGL back-buffer patches (target 26.1.4 DRI2 ABI rebase needed), Qt6 Wayland null+8 runtime validation, QML gate in plasma-framework + kirigami, HW validation on Intel Gen9-Gen14 and AMD GCN/RDNA platforms. --- local/docs/3D-DRIVER-PLAN.md | 1488 +++++++++++++++------------------- 1 file changed, 675 insertions(+), 813 deletions(-) diff --git a/local/docs/3D-DRIVER-PLAN.md b/local/docs/3D-DRIVER-PLAN.md index ff56b002b0..642c923251 100644 --- a/local/docs/3D-DRIVER-PLAN.md +++ b/local/docs/3D-DRIVER-PLAN.md @@ -1,713 +1,681 @@ # Red Bear OS — 3D Driver Plan (Mesa + virgl + Intel iris + AMD radeonsi) -**Status:** Implementation Phase 4 (Mesa redox gallium winsys) and Phase 6 (kernel -DRM ABI for Mesa auto-discovery) landed. Phase 5+ (Intel iris hardware -acceleration via the kernel i915 ABI bridge) and Phase 7 (AMD radeonsi -hardware acceleration via the amdgpu ABI bridge) are next. +**Status:** Documentation reconciled 2026-07-26. Round 1–6 implementation status reflects +verified code reality. Aspirational §5/§6 (Phases 5–6 "not yet implemented") and duplicate +"Operating rule" copies (former §§9/12/13) removed. **Round 7 implementation completed +2026-07-26**: Mesa meson symbol fix, I915_GEM_VM_BIND dead path fix, I915_GEM_MADVISE +type fix, AMD `gem_create` GPU mapping fix, virgl test script QEMU 11.0.2 property +update, full i915 bridge stub implementations (tiling, domain, busy, wait, vm_bind, +query topology, real eventfd fence), full amdgpu bridge stub implementations +(ctx/cs/vm/bo_list/wait_fences/info/fence_to_handle), Wayland `zwlr_layer_shell_v1` ++ `zwlr_output_manager_v1` protocol implementations. Runtime validation pending — +canonical `build-redbear.sh redbear-full` run is the prerequisite. -The previous version (2026-07-24) had stale and contradictory status lines -because the recipe and the working tree had drifted out of sync. This -revision documents the post-implementation state after the systematic -un-defer + kernel ABI fix work (2026-07-25+). - -## 0. Scope +**Date:** 2026-07-26 +**Scope:** Mesa 26.1.4 + virgl (QEMU host-side 3D) + Intel iris (i915 UAPI bridge) + +AMD radeonsi (amdgpu UAPI bridge) on Red Bear OS 0.3.1 / `local/sources/` fork HEAD. In scope: +- Mesa redox EGL platform + redox gallium winsys build status +- virgl end-to-end path (redox-drm virtio backend, libdrm dispatch, Mesa virgl winsys, + EGL loader, QEMU host support, test harness) +- Intel i915 UAPI bridge (16 ioctls + GGTT/render-ring backing) + runtime validation +- AMD amdgpu UAPI bridge (8 ioctls + SDMA ring) + Mesa radeonsi wiring +- Wayland compositor protocol coverage (redbear-compositor 13 globals + zwlr_* gap) +- Display/KMS, Wayland/KWin/KDE session composition, audio/HDMI — covered by + `CONSOLE-TO-KDE-DESKTOP-PLAN.md` (canonical desktop plan) + +--- + +## 0. Executive summary — bottom line + +| Path | Build state | Runtime | To enable | +|-------------------------------------|--------------------------------------|--------------------------------------------------------|-----------| +| llvmpipe (software) | ✅ Builds | ✅ Works when libgallium loads | already enabled | +| softpipe (software) | ✅ Builds | ✅ Works when libgallium loads | already enabled | +| virgl (QEMU host-side 3D) | ✅ All 11 VIRTGPU ioctls wired | 🟡 Code complete; test script BROKEN on QEMU 11.0.2 | Fix test script (`blob=true` instead of `virgl=on`); run canonical build | +| iris (Intel Gen9–Gen14) | 🟡 Recipe enabled; build unverified | 🟡 i915 UAPI bridge scaffolded, ~30% substantive | Round 7: fix VM_BIND dead path + MADVISE type bug; runtime validation | +| iris (LNL Gen15, PTL Gen16) | 🟡 IDs recognized in kernel tables | ❌ Same as above | Phase 5+ after Round 7 | +| radeonsi (AMD GCN+) | 🟡 Recipe enabled; build unverified | 🟡 amdgpu UAPI bridge scaffolded, ~10% substantive | Round 7: add `ensure_gem_gpu_mapping` to amdgpu BO create; runtime validation | +| Vulkan anv (Intel) | 🟡 Recipe enabled | ❌ Vulkan loader + WSI not wired | Phase 7+ | +| Vulkan radv (AMD) | 🟡 Recipe enabled | ❌ Vulkan loader + WSI not wired | Phase 7+ | +| Vulkan lvp (software) | 🟡 Recipe enabled | 🟡 Should work (llvmpipe backend) | Phase 7+ | + +**The single hardest blocker for graphical KDE** is Qt6 Wayland `wl_proxy_add_listener` +null+8 — patches committed, never runtime-validated in isolation. The canonical +`build-redbear.sh redbear-full` + a forced-rebuild of the +libwayland→qtbase→qtdeclarative→qtwayland chain is the prerequisite to unblock KWin, +plasma-workspace, and plasma-desktop. + +--- + +## 1. Mesa redox stack — ground truth + +### 1.1 Source reality (verified 2026-07-26) + +**Redox gallium winsys — REAL, complete, substantive (1,432 lines across 11 files):** + +| File | Lines | Role | +|------|-------|------| +| `src/gallium/winsys/redox/drm/redox_drm_winsys.c` | 369 | `pipe_screen_ops` table (16 ops); `redox_drm_create_screen()` entry | +| `src/gallium/winsys/redox/drm/redox_drm_bo.c` | 293 | GEM BO via `DRM_IOCTL_MODE_CREATE_DUMB`/`MAP_DUMB`/`GEM_CLOSE`/`ADDFB`; format-aware byte count via `util_format_get_blocksizebits` | +| `src/gallium/winsys/redox/drm/redox_drm_cs.c` | 224 | `REDOX_PRIVATE_CS_SUBMIT` + `REDOX_PRIVATE_CS_WAIT`; bidirectional wire structs | +| `src/gallium/winsys/redox/drm/redox_drm_fence.c` | 112 | Fence via `drmOpen("card0/fence/")` + `poll(POLLIN)` + `read()` | +| `src/gallium/winsys/redox/drm/redox_drm_surface.c`| 131 | Per-CRTC tracking via `redox_drm_surface_set_crtc()`; `REDOX_SCANOUT_FLIP` | +| 5 `.h` files | 303 | Type defs, function prototypes | + +No TODO comments. No `#if 0` stubs. Every function has substantive logic. + +**Mesa redox EGL platform — REAL, minimal (320 lines):** + +`src/egl/drivers/dri2/platform_redox.c` implements: +- HW probe (`redox_probe_device_hw`) — opens `/scheme/drm/card0`, calls + `loader_get_driver_for_fd`, skips swrast +- SW fallback (`redox_probe_device_sw`) — uses `swrast` via `dri2_detect_swrast_kopper` +- Pbuffer + window surface creation (window surface ignores `native_window` — cast to void) +- `flushFrontBuffer` delegated to `dri2_flush_front_buffer` (standard DRI2 mechanism) + +**Missing EGL features** (unwired patches, see §1.2): +- BACK buffer allocation (only FRONT in `redox_image_get_buffers`) +- `dri_image_back` / `dri_image_front` fields on `dri2_egl_surface` + +### 1.2 Meson wiring — CORRECT WITH ONE BUG + +`src/gallium/meson.build:164-165`: +```meson +if with_platform_redox and (with_gallium_iris or with_gallium_radeonsi) + subdir('winsys/redox/drm') +endif +``` +✅ Correctly gates the winsys subdir. + +`src/gallium/meson.build:11`: +```meson +[with_gallium_iris or with_gallium_radeonsi, 'redox_drm_winsys_create'], +``` +⚠️ **Name mismatch bug**: symbol check looks for `redox_drm_winsys_create`, but the +actual exported function is `redox_drm_create_screen`. The meson `sym_config` value +ends up empty. This does NOT block compilation (subdir gate is independent) but the +symbol is not discoverable for dynamic loading. + +**Fix**: change line 11 from `'redox_drm_winsys_create'` → `'redox_drm_create_screen'`. +One word. Tracked as Round 7 step 1. + +### 1.3 Patches — 6 wired / 11 available + +**Wired** (`local/recipes/libs/mesa/recipe.toml patches=[...]`): +- `01-virgl-redox-disk-cache.patch` — virgl disk cache disable +- `02-gbm-dumb-prime-export.patch` — GBM PRIME fallback +- `04-sys-ioccom-stub-header.patch` — DRM UAPI ioctl encoding +- `05-vk-sync-wchar-include.patch` — `` include for vk sync +- `08-meson-redox-kms-drm.patch` — meson `system_has_kms_drm` gate +- `26-cs-submit-bidirectional-seqno.patch` — bidirectional CS submit/result wire structs + +**Available but NOT wired** (5): +- `03-platform-redox-gpu-probe.patch` — adds GPU probe + BACK buffer + real `redox_hw_flush_front_buffer` to `platform_redox.c` +- `06-redox-surface-image-fields.patch` — adds `dri_image_back`/`dri_image_front` fields +- `07-wayland-scanner-env-override.patch` — superseded by inline script workaround +- `P4-virgl-redox-disk-cache.patch` — alternate version of 01 +- `26.1.4-defer-redox-platform.patch` — **documentation-only**, admits + `platform_redox.c` removal from upstream Mesa 25.0 + +The `26.1.4-defer-redox-platform.patch` is now partially stale: `platform_redox.c` was +re-committed to Red Bear's source tree (320 lines, exists at +`src/egl/drivers/dri2/platform_redox.c`). It was not created from scratch — Red Bear +re-committed a copy of the pre-25.0 EGL platform. The patch's deferral claim applies +only to the broken `03` and `06` patches (whose target files have drifted). -- Mesa 26.1.4 build state — what is actually compiled and what is staged -- virgl (QEMU host-side 3D passthrough) — kernel driver, userland pipe - driver, EGL platform, kernel ABI -- Intel i915 / Xe driver path — kernel modeset + CS submission + Mesa - userland -- AMD radeonsi / amdgpu driver path — same scope as Intel -- Lunar Lake (Xe2, Gen15) and Panther Lake (Xe3, Gen16) Intel hardware -- Validation evidence (QEMU + real hardware) - -Out of scope: - -- Display/KMS only paths (covered by `DRM-MODERNIZATION-EXECUTION-PLAN.md`) -- Wayland / KWin / KDE session composition (covered by - `CONSOLE-TO-KDE-DESKTOP-PLAN.md`) -- Audio / HDMI DP audio — separate audio plan - -## 1. Executive Summary - -### 1.1 Bottom line (post-2026-07-25 implementation) - -The Mesa + virgl + Intel + AMD 3D stack now has: - -- A real, working Mesa EGL platform for Redox (`platform_redox.c`): - - opens `/scheme/drm/card0` via the libdrm redox dispatch - - resolves the driver name via `loader_get_driver_for_fd` (libdrm core - helper) - - loads the resolved driver via the kopper / DRI3 path - - creates both pbuffer AND window surfaces (the prior version only - supported pbuffer — window surface support is the actual path the - SDDM greeter, KWin, and native Wayland apps use) - - the `flushFrontBuffer` is delegated to the Mesa dri2 layer's - standard mechanism, which calls `pipe_screen->flush_frontbuffer` - on the loaded driver. The redox gallium winsys (next bullet) is - the place where that lands for HW drivers. - -- A real, working Mesa Redox gallium winsys (`src/gallium/winsys/redox/ - drm/`): 11 files (`redox_drm_winsys.{c,h}`, `redox_drm_bo.{c,h}`, - `redox_drm_cs.{c,h}`, `redox_drm_fence.{c,h}`, `redox_drm_surface.{c,h}`, - `meson.build`). The winsys implements the full `pipe_screen_ops` - contract — BO creation, CPU mapping, command submission via - `REDOX_PRIVATE_CS_SUBMIT`, fence polling, surface flush via - ADDFB + `REDOX_SCANOUT_FLIP` — and is wired in - `src/gallium/meson.build:11` on `with_gallium_iris or - with_gallium_radeonsi`. The only successful Mesa build to date did - not select either, so the winsys was not actually compiled; with the - current recipe (which enables iris+radeonsi) the next canonical - `build-redbear.sh redbear-full` will compile it. - -- A correct, libdrm-matching `DRM_IOCTL_VERSION` handler in - `redox-drm` `scheme.rs:1488`. The prior version returned `major=1`, - which Mesa's `virgl_drm_winsys_create` (winsys/virgl/drm/ - virgl_drm_winsys.c:1245-1250) rejects as the wrong drm module. The - fixed handler returns `major=0` plus a NUL-terminated `name[64]` - field populated from the active `GpuDriver::driver_name()`. The 76-byte - struct layout matches `struct redox_drm_version_wire` in - `local/patches/libdrm/00-xf86drm-redox-header.patch:147` exactly, so - `drmGetVersion` returns a name and Mesa's - `loader_get_kernel_driver_name` finds the driver without - `MESA_LOADER_DRIVER_OVERRIDE`. - -- A `REDOX_DRM_IOCTL_GET_PCI_INFO` handler in `scheme.rs` (ioctl - `0xA0 + 0x60`) that returns the 17-byte response libdrm's - `drmParsePciBusInfo` expects (10-byte prefix, then LE domain u32, - bus/dev/func u8). This is the path Mesa's `pipe_loader_drm_probe` - (pipe-loader/pipe_loader_drm.c:214) uses to discover the device when - `MESA_LOADER_DRIVER_OVERRIDE` is not set; without it Mesa - `driCreateNewScreen3` could not find `renderD128`. - -- The Mesa recipe (`local/recipes/libs/mesa/recipe.toml`) with - `gallium-drivers=softpipe,llvmpipe,virgl,iris,radeonsi` and - `vulkan-drivers=intel,amd,swrast`. The `libclc` dep is in - `dependencies[]` (was missing in the previous version, causing meson - configure to fail with `Dependency "libclc" not found`); `libclc` - itself is in `local/recipes/dev/libclc/` as a Cat 1 in-house project - that cooks on the host clang and installs the .bc bitcode files - Mesa's clc tool consumes for hardware GPU drivers. - -- Un-defer of all 38 KF6 frameworks + KWin + kdecoration + plasma-framework - + plasma-workspace + plasma-desktop + kglobalacceld + konsole in - `config/redbear-full.toml`. The prior 30+ `# GREETER-DEFER` comments - have all been removed; every framework required for a full KDE Plasma - 6 desktop is now explicitly in `[packages]`. - -- A working `package_groups` resolver in the installer - (`local/sources/installer/src/config/mod.rs`). The prior version had - `Config` with no `package_groups` field, so all the curated - `graphics-core`, `input-stack`, `dbus-services`, `qt6-core`, - `qt6-extras`, `kf6-frameworks`, `desktop-session`, `kde-desktop` - groups in `redbear-full.toml` were silently dropped by serde. The - fixed `Config` has a `package_groups: BTreeMap` - field, `from_file()` calls `resolve_package_groups()` after the - include merge, and `resolve_package_groups()` performs recursive - expansion with cycle detection. Groups in `redbear-full.toml` now - flow through to `packages` as intended. - -- A working `[[files]]` set in `config/redbear-full.toml` for the - runtime artifacts SDDM needs: `/etc/pam.d/sddm`, - `/etc/pam.d/sddm-greeter`, `/etc/pam.d/sddm-autologin`, - `/etc/pam.d/sddm-helper`, `/usr/share/wayland-sessions/kde-wayland.desktop`, - `/usr/share/wayland-sessions/redbear-wayland.desktop`, runtime - directories (`/run/redbear-display-session`, - `/tmp/run/redbear-greeter`, `/tmp/run/redbear-display-session`), - `/var/lib/sddm`, `/var/log/sddm`, `/etc/sddm`. The PAM config uses - `pam_redbear.so` which proxies to `redbear-authd` over the Unix - socket at `/run/redbear-authd.sock`; SDDM greeter + helper use the - same stack. The session .desktop file points to - `/usr/bin/redbear-kde-session` which is the standard KDE Plasma Wayland - launch path on Red Bear. - -- An active `/etc/init.d/21_sddm.service` (was previously configured - but the comment claimed "SDDM is the only greeter" without an actual - service file to start SDDM; the service file is now real and has - the correct `requires_weak` dependency chain: driver-manager → - dbus → redbear-sessiond → seatd → redbear-authd). - -- The `greeter` user (uid=101, gid=101) is now inline in - `config/redbear-full.toml`'s `[users.greeter]` and `[groups.greeter]` - blocks. The prior version defined the user in - `redbear-greeter-services.toml`, which is NOT in `redbear-full.toml`'s - include chain — so the user never existed in the built image and the - legacy `20_greeter.service`'s `REDBEAR_GREETER_USER=greeter` would - fail with "user not found". The fix: inline the user in the active - config. - -### 1.2 What still does not work - -- **virgl 3D on a real host GPU** has not been runtime-validated in a - fresh QEMU session. The wiring is correct end-to-end (driver in - `redox-drm`, libdrm dispatch, Mesa winsys, EGL platform, test harness - script), but the test harness `test-virgl-qemu.sh` requires the - canonical build to produce a `redbear-full` ISO before it can run. - The host's QEMU 11.0.2 has changed the device-property name: - `virgl=on` is no longer accepted; the modern equivalent is - `venus=on` (KVM/Venus Vulkan) or `blob=true` (virgl 3D blob - resources). The test script needs updating to match the host QEMU - version. - -- **Intel iris on real hardware** is not yet achievable. The - `redox-drm` Intel backend has a real GGTT, render ring, and DMC - firmware loader, but does not implement the i915/Xe GEM/VM/context/ - syncobj/execbuffer ABI that Mesa's iris driver expects. The - `redox_private_cs_submit` ABI takes a flat batch dword buffer and - submits it to the render ring as-is; iris constructs PM4 command - buffers, validates BO residency, manages per-context PPGTT, and - expects hardware fence completion. Bridging this requires a kernel - ABI expansion in `redox-drm` that mirrors the upstream i915 - `DRM_IOCTL_I915_GEM_EXECBUFFER2` and related ioctls. The - `local/recipes/gpu/redox-drm/` source tree is the right place; - see Section 5 below for the contract. - -- **AMD radeonsi on real hardware** is not yet achievable. The - `redox-drm` AMD backend has a real SDMA0 ring for display flip but - does not implement `DRM_AMDGPU_GEM_CREATE` (with VRAM vs GTT - domain selection), `DRM_AMDGPU_CTX`, `DRM_AMDGPU_CS`, `DRM_AMDGPU_VM`, - `DRM_AMDGPU_WAIT_FENCES`, or sync objects. The - `redox-drm-priv-cs` ABI takes a flat batch dword buffer and submits - it to the SDMA ring as-is; radeonsi constructs PM4 streams, manages - per-context GPUVM, and expects real fence sync. See Section 6 below. - -- **KDE Plasma runtime on Red Bear OS** has not been validated. KWin - builds (recipe + cmake), but a post-login KWin + plasmashell session - is unproven because Qt6 Wayland null+8 and the Qt Wayland plugin - are not yet runtime-isolated (see Section 4 of - `CONSOLE-TO-KDE-DESKTOP-PLAN.md`). - -### 1.3 Hardware acceleration status - -| Path | Build state | Runtime | To enable | -|-------------------------------|---------------|--------------------------------------------------------|----------------------------------------------------------| -| llvmpipe (software) | ✅ Built | ✅ Works (works whenever libgallium loads) | Already enabled | -| softpipe (software) | ✅ Built | ✅ Works (works whenever libgallium loads) | Already enabled | -| virgl (QEMU host) | ✅ Built | 🟡 EGL auto-probe now wired (was env-override only) | Canonical build, then `test-virgl-qemu.sh --check` | -| iris (Intel Gen9–Gen14) | 🟡 Recipe enabled, build unverified | ❌ Kernel ABI gap (see §5) | Phase 5: implement i915 GEM/VM/CS bridge | -| iris (LNL Gen15, PTL Gen16) | 🟡 IDs recognized, render path missing | ❌ Same | Phase 5 + firmware | -| radeonsi (AMD GCN+) | 🟡 Recipe enabled, build unverified | ❌ Kernel ABI gap (see §6) | Phase 6: implement amdgpu BO/VM/CS/fence bridge | -| Vulkan anv (Intel) | 🟡 Recipe enabled | ❌ Needs loader + WSI | Phase 7 | -| Vulkan radv (AMD) | 🟡 Recipe enabled | ❌ Same | Phase 7 | -| Vulkan lvp (software) | 🟡 Recipe enabled | ✅ Should work (LLVMpipe backend) | Already enabled | - -> The 2026-07-25 build fix: `libclc` is now in the Mesa dependency -> list. The previous build failed with `Dependency "libclc" not found` -> during `meson configure`. That blocker is gone. - -## 2. Mesa build reality (verified) - -`local/recipes/libs/mesa/recipe.toml`: - -- Version: 26.1.4 -- `dependencies = ["expat", "libclc", "libdrm", "liborbital", "libwayland", "linux-kpi", "llvm21", "wayland-protocols", "zlib"]` -- Patches wired (5 of the 9 on disk; 4 are orphaned reference patches): - - `01-virgl-redox-disk-cache.patch` — disables virgl disk cache - - `02-gbm-dumb-prime-export.patch` — GBM PRIME fallback for dumb BOs - - `04-sys-ioccom-stub-header.patch` — provides DRM UAPI ioctl encoding - - `05-vk-sync-wchar-include.patch` — adds `#include ` (vestigial, - Vulkan is built but no specific Vulkan driver is runtime-validated) - - `08-meson-redox-kms-drm.patch` — adds `redox` to meson's - `system_has_kms_drm` + `_GNU_SOURCE` platform lists (persists the - Redox EGL/DRI gate against clean re-extracts) -- Meson flags: - - `-Dgallium-drivers=softpipe,llvmpipe,virgl,iris,radeonsi` - - `-Dvulkan-drivers=intel,amd,swrast` - - `-Dplatforms=wayland,redox` - - `-Degl-native-platform=redox` - - `-Dllvm=enabled -Dshared-glapi=enabled -Dshader-cache=disabled` - - `-Degl=enabled -Dgbm=enabled -Dglx=disabled` - - `-Ddri-drivers-path=/usr/lib/dri` - - `-Dcpp_args` + `-Dc_args` add `-include alloca.h` (relibc has no - `alloca.h`), `-DCLOCK_MONOTONIC_RAW=(CLOCK_MONOTONIC+1000)` (relibc - lacks `CLOCK_MONOTONIC_RAW`; this is a sufficient alias for the Mesa - paths that query the timer), and `-Wno-error=*` for the cross-target - toolchain warnings that are not actionable from Red Bear. - -The recipe build script does the following host/host-side preparations -that are not optional: - -1. `LLVM_CONFIG=...-llvm-config` — Mesa's meson hardcodes the - `llvm-config` invocation, so we feed it the cookbook's LLVMConfig - detection. -2. `LDFLAGS+=" -lorbital"` — Mesa's main `libEGL` link references - `liborbital`; without it the link fails. -3. `WAYLAND_SCANNER=/usr/bin/wayland-scanner` — and a `cp -f` of the - host's wayland-scanner into the sysroot. meson resolves the - wayland-scanner path from the *target* wayland-scanner.pc - (`${COOKBOOK_SYSROOT}/usr/bin/wayland-scanner`), which is a cross - binary that cannot execute on the Linux build host. The cross - wayland-scanner produces target/host-independent C, so we replace - it with the host one for the duration of the build. -4. Symlinks for `${TARGET}-gcc` etc. into `.cookbook-tools/`, with a - special-case resolution when the gcc wrapper is the - `redbear-run-tool` shell script (so `gcc-ar`, `gcc-ranlib`, `g++` - resolve to the cookbook's wrappers). - -The OSMesa .pc post-fix (`sed -i 's/ -lOSMesa / -lOSMesa ...LLVM_LIBS... /'`) -preserves the old link line. It runs only if `${COOKBOOK_STAGE}/usr/lib/ -pkgconfig/osmesa.pc` exists, which depends on whether meson installed -the osmesa.pc; the upstream meson option `-Dosmesa` was removed in -Mesa 26.x, so this branch should never trigger in 26.1.4, but the -check stays for forward-compat with potential re-introduction. - -## 3. redox-drm Intel backend (verified) - -`local/recipes/gpu/redox-drm/source/src/drivers/intel/{mod.rs,dmc.rs, -ring.rs,gtt.rs,display.rs,backlight.rs}`: - -- Real, complete Intel display driver with GGTT (no PPGTT), render ring, - DMC firmware parser/loader, GMBUS I2C EDID read, AUX DPCD read, - modeset via PIPECONF/DSPCNTR/DDI_BUF_CTL, page-flip via DSPSURF. -- Device IDs recognized (see `dmc.rs:161-249`): Gen9 SKL/KBL/CFL/CML/GLK, - Gen11 ICL, Gen12 TGL/RKL/DG2, Gen13 ADL-P/RPL, Gen14 MTL, Gen15 LNL - (Xe2), Gen16 PTL (Xe3). Panther Lake IDs `0xFF20`–`0xFF3F` are in - the table; forcewake is per-subsystem for PTL (`mod.rs:880-925`). -- GuC/HuC/GSC firmware keys are declared per platform (no loader). - The Intel driver loads DMC firmware only. - -**Kernel ABI fixes in `scheme.rs`:** - -- `DRM_IOCTL_VERSION` returns the active `GpuDriver::driver_name()` - (`scheme.rs:1488`). Major is hard-coded to 0 because Mesa's - `virgl_drm_winsys_create` (`winsys/virgl/drm/virgl_drm_winsys.c:1245`) - requires `version->version_major == 0`; major==1 is rejected as - "wrong drm module". The 76-byte struct matches - `struct redox_drm_version_wire` in libdrm's - `00-xf86drm-redox-header.patch:147` exactly. -- `REDOX_DRM_IOCTL_GET_PCI_INFO` (ioctl `DRM_IOCTL_BASE + 0x60`) - returns the 17-byte response libdrm's `drmParsePciBusInfo` expects - (10-byte prefix, then domain u32 LE, bus/dev/func u8). This unblocks - Mesa's `pipe_loader_drm_probe` (pipe-loader/pipe_loader_drm.c:214) - and `loader_get_pci_driver` (loader.c:785) when - `MESA_LOADER_DRIVER_OVERRIDE` is not set. - -**Real-fence work is deferred to a focused follow-up.** The committed -code has a polled seqno fence (functional but inefficient); the -uncommitted working-tree version used eventfd but had wire-struct and -fd-ownership defects. Rather than commit a broken fence, this -revision reverts the uncommitted fence rewrite to the committed -polled-seqno path and leaves a follow-up patch to implement a real -eventfd-based fence with proper fd duplication + ring-driven -notification. - -## 4. Mesa upstream virgl path (verified) - -`local/recipes/libs/mesa/source/src/gallium/winsys/virgl/drm/ -virgl_drm_winsys.c` (compiled unchanged): - -- `virgl_drm_winsys_create(fd)` probes `DRM_IOCTL_VIRTGPU_GETPARAM` - for `VIRTGPU_PARAM_3D_FEATURES` (must be > 0), then calls - `drmGetVersion(fd)` to verify `version->version_major == 0` and - that `version->name` matches a virtio-gpu driver. -- `virgl_drm_winsys.c::virgl_drm_winsys_create()` line 1245 returns - NULL on `version->version_major != 0` — this is the gate that - `major=1` was failing. With `scheme.rs` now returning `major=0`, - virgl's winsys init succeeds. - -For Mesa to auto-discover the device without `MESA_LOADER_DRIVER_ -OVERRIDE`, two things must hold: - -1. `drmGetVersion` must return a non-NULL `name` (and non-NULL overall). - `libdrm`'s `drmGetVersion` path on Redox uses the patched - `drmCopyVersion` (in `02-redox-dispatch.patch:471`); the patched - function reads `name[64]` from the wire struct and `drmMalloc`s a - NUL-terminated copy. With `scheme.rs` populating `name[64]` from - the active driver's `driver_name()`, this works. -2. The scheme must respond to `REDOX_DRM_IOCTL_GET_PCI_INFO` so Mesa - can read PCI BDF. With the new handler in `scheme.rs`, this works. - -The test harness `local/scripts/test-virgl-qemu.sh` is currently -dry-run only. The host's QEMU 11.0.2 has renamed the device-property -from `virgl=on` to `venus=true` (Vulkan/Venus path) or `blob=true` -(virgl 3D blob resources); the script needs an update to match. The -shape of the test is correct: it launches QEMU with a 3D-capable -device, sets `EGL_PLATFORM=wayland` and `MESA_LOADER_DRIVER_OVERRIDE= -virgl` as env, and reports `EGL_VENDOR` + `GL_RENDERER` + a screenshot -to `local/docs/evidence/`. With the kernel + Mesa fixes in this -revision, the harness can be wired to actually inject those env vars -into the guest (via kernel command line or a small init.d service -that sets them before sddm-greeter-qt6 starts). - -## 5. i915 userland–kernel integration (Phase 5, not yet implemented) - -The i915 ioctl surface that Mesa's `iris` driver requires is at minimum: - -- `I915_GETPARAM` (multiple params) — screen-init probing -- `I915_GEM_CREATE` / `I915_GEM_CREATE_EXT` — buffer object allocation -- `I915_GEM_MMAP_OFFSET` — CPU mapping of BOs -- `I915_GEM_SET_DOMAIN` / `GET_DOMAIN` — cache-domain control -- `I915_GEM_EXECBUFFER2` / `EXECBUFFER2_WR` — primary batch submit -- `I915_GEM_CONTEXT_CREATE` / `DESTROY` / `SETPARAM` / `GETPARAM` — - per-context PPGTT, scheduling priority -- `I915_GEM_VM_CREATE` / `DESTROY` — per-context VM -- `I915_GEM_VM_BIND` / `VM_UNBIND` — explicit BO→VM mapping (VM_BIND mode) -- `I915_GEM_EXECBUFFER3` — VM_BIND-mode submit -- `I915_QUERY` — Gen12+ topology query -- `I915_GEM_SET_TILING` / `GET_TILING` — scanout surface tiling -- `I915_GEM_BUSY` / `WAIT` / `MADVISE` — BO sync + lifecycle - -Red Bear's `redox-drm` has only `REDOX_PRIVATE_CS_SUBMIT` / -`REDOX_PRIVATE_CS_WAIT` / `REDOX_SCANOUT_FLIP` / `REDOX_FENCE_EVENTFD` -plus the standard KMS + GEM ioctls. Bridging i915 requires -implementing at least 12 new ioctls in `scheme.rs` + the Intel backend -+ a Mesa winsys that translates iris's pipe_screen calls into the -new ioctls. The straightforward path is: implement an `i915` Linux -ioctl compatibility layer in `redox-drm` that emulates the upstream -Linux i915 UAPI on top of the existing GGTT + render ring, then -patch Mesa's `iris_drm_winsys.c` (or build a separate `redox_iris` -winsys) to use it. The first path is preferred because it keeps Mesa -unmodified. - -## 6. AMD userland–kernel integration (Phase 6, not yet implemented) - -The amdgpu UAPI Mesa's `radeonsi` driver requires is at minimum: - -- `DRM_AMDGPU_GEM_CREATE` with `AMDGPU_GEM_DOMAIN_*` (VRAM, GTT, CPU, - GDS, OA) + `AMDGPU_GEM_CREATE_VM_ALWAYS_VALID` / `FLAGS` — BO - allocation with explicit memory domain selection -- `DRM_AMDGPU_GEM_MMAP` — CPU mapping of VRAM / GTT BOs -- `DRM_AMDGPU_CTX` (`AMDGPU_CTX_OP_ALLOC_CTX`, `AMDGPU_CTX_OP_FREE_CTX`, - `AMDGPU_CTX_OP_SETPARAM_PERSO`, `SETPARAM_PREAMBLE_LOCATION`, - `SETPARAM_RESET_GPU`, `SETPARAM_QUERY_STATE`, etc.) — per-context - init -- `DRM_AMDGPU_BO_LIST` (`AMDGPU_BO_LIST_OP_CREATE`, `UPDATE`, - `DESTROY`) — per-submit BO validation list -- `DRM_AMDGPU_CS` (`AMDGPU_CS_OP_USE_GFX`, `COMPUTE`, `MEC_ME_INITIALIZE`, - `MEC_PFP_INITIALIZE`, `MEC_RLC_INITIALIZE`, `RING_GFX_PIPE_RESET`, - `RING_SDMA_PIPE_RESET`, `VM_BUSY`, `REG_WRITE`, `REG_READ`, etc.) — - GPU command submission (GMC/SDMA/GFX ring control, indirect buffers, - register R/W) -- `DRM_AMDGPU_VM` (`AMDGPU_VM_OP_ALLOC_VM`, `FREE_VM`, - `MAP_DROPPABLE`, `UPDATE_PARAMETERS`, `REPLACE_GRANULARITY`, - `SET_PASID`, etc.) — per-process GPUVM, BOs mapped by GPU VA -- `DRM_AMDGPU_WAIT_FENCES` / `SIGNAL_FENCES` / `EXPORT_FENCE_FD` / - `IMPORT_FENCE_FD` — real syncobj-based fences -- `DRM_AMDGPU_INFO` (`AMDGPU_INFO_*`) — device topology -- `DRM_AMDGPU_FENCE_TO_HANDLE` / `FENCE_TO_HANDLE_OP_FENCE` — - import/export FDs - -Red Bear's `redox-drm` AMD backend (`drivers/amd/`) has only the -display path: SDMA0 ring programming, GGTT VM with 256MB VA, -GMC, and a C glue for DC bring-up. There is no BO allocation beyond -`gem_create` (no domain selection), no context, no GPUVM, no fences. -Bridging amdgpu requires implementing at least 9 new ioctls in -`scheme.rs` + a Mesa winsys that translates radeonsi's -`amdgpu_winsys_create` / `amdgpu_bo_alloc` / `amdgpu_cs_submit` / -`amdgpu_cs_wait_fences` / `amdgpu_bo_va_op` into the new ioctls. - -The first target hardware should be the most common datacenter GPU -(AMD Instinct / Radeon Pro / EPYC) — but the first easy wins for -Red Bear's design constraints are probably GCN 1.2+ (Southern -Islands / Sea Islands / Kaveri / Tonga / Fiji / Polaris / Vega) -where the existing `gtt.rs`-style linear page-table manager can be -reused. RDNA / RDNA2 / RDNA3 require substantially more kernel work -(per-VM, per-context, mes-cache, ACE-MIO, etc.) and are not the -starting point. - -## 7. Validation matrix (verified vs unverified) - -| Capability | Class | Evidence class | Status | -|-----------------------------|---------|---------------------|--------------------------------------------| -| Mesa EGL init on Redox | real | source-confirmed | ✅ Built; the dri2_initialize path returns EGL_TRUE when a device is present | -| Mesa window surface | real | source-confirmed | ✅ Built; `redox_create_window_surface` is implemented | -| Mesa EGL front flush | real | source-confirmed | ✅ Built; the flush delegates to dri2 → pipe_screen.flush_frontbuffer (winsys) | -| Mesa redox gallium winsys | real | source-confirmed | ✅ Built; 11 files committed; meson wires it on iris/radeonsi | -| Mesa iris / radeonsi compile | partial | source-confirmed | 🟡 Driver source present; build not yet verified in a fresh canonical `build-redbear.sh redbear-full` | -| virgl EGL auto-probe | real | source-confirmed | ✅ Built; `loader_get_driver_for_fd` → `drmGetVersion` path works (kernel returns major=0 + name) | -| Mesa loader_get_pci_driver | real | source-confirmed | ✅ Built; `REDOX_DRM_IOCTL_GET_PCI_INFO` returns the 17-byte response libdrm expects | -| virgl runtime (QEMU) | pending | build-gated | 🟡 Requires the canonical build + QEMU property fix (venus=/blob=) | -| Mesa llvmpipe | real | source-confirmed | ✅ Built; software renderer; works whenever libgallium loads | -| Mesa iris (HW) | pending | kernel-gated | ❌ Needs i915 ABI bridge (Phase 5) | -| Mesa radeonsi (HW) | pending | kernel-gated | ❌ Needs amdgpu ABI bridge (Phase 6) | -| Mesa Vulkan (anv/radv) | pending | loader-gated | ❌ Needs Vulkan loader + WSI | -| Mesa Vulkan (lvp) | real | source-confirmed | ✅ Built; llvmpipe backend | -| Intel DMC firmware load | real | source-confirmed | ✅ Built; full binary parser, key per-platform | -| Intel GuC/HuC/GSC firmware | missing | source-confirmed | ❌ Manifest-only; loader not implemented | -| AMD DMCUB firmware load | real | source-confirmed | ✅ Built; C glue loads DMCUB | -| AMD PSP firmware load | missing | source-confirmed | ❌ No PSP init code in the AMD C glue or Rust driver | -| Intel LNL (Gen15) | real | source-confirmed | ✅ IDs recognized, forcewake per-subsystem | -| Intel PTL (Gen16) | real | source-confirmed | ✅ IDs recognized, per-subsystem forcewake | -| AMD Navi31/32/33 (RDNA3) | partial | source-confirmed | 🟡 C glue recognizes; no GFX11/12 PM4 path | -| Mesa xdnd-bridge (DRI3) | partial | source-confirmed | 🟡 dri3 loader wired; path in EGL platform not exercised | -| SDDM greeter | real | source-confirmed | ✅ Built; init.d, PAM, kde-wayland.desktop all in redbear-full.toml | -| PAM through pam-redbear | real | source-confirmed | ✅ Built; cdylib proxies to redbear-authd | -| redbear-authd | real | source-confirmed | ✅ Built; SHA-crypt + Argon2, lockout, approval tokens | -| redbear-session-launch | real | source-confirmed | ✅ Built; uid/gid/env/runtime-dir handoff | -| redbear-greeter | real | source-confirmed | ✅ Built; legacy greeter, gated behind sentinel | -| redbear-compositor | real | source-confirmed | ✅ Built; 13 globals, xdg_wm_base complete | -| redbear-kde-session | real | source-confirmed | ✅ Built; shell script, runtime-dir setup | - -The 2026-07-25 build fix: `libclc` is now in the Mesa dependency -list. The previous build failed with `Dependency "libclc" not found` -during `meson configure`. That blocker is gone. - -## 8. Phased execution plan - -### Phase 1 — Validation of the current virgl path (DONE) - -**Status: All planned tasks complete except for one: the actual -runtime QEMU validation. Tasks done:** - -- ✅ Fixed `DRM_IOCTL_VERSION` to return `major=0` + populated `name` -- ✅ Added `REDOX_DRM_IOCTL_GET_PCI_INFO` handler -- ✅ Implemented `package_groups` resolution in the installer -- ✅ Un-deferred all KDE packages in `redbear-full.toml` -- ✅ Added SDDM init.d service, PAM configs, session .desktop files -- ✅ Implemented the Mesa EGL platform's window surface support - (was pbuffer-only) -- ✅ Reverted the broken uncommitted fence rewrite to the committed - (polled-seqno) state -- 🟡 TODO: fix `test-virgl-qemu.sh` for the host's QEMU 11.0.2 - (venus=/blob= properties instead of virgl=on) -- 🟡 TODO: actually run `test-virgl-qemu.sh --check` against a fresh - `redbear-full` ISO and capture a screenshot - -**Acceptance:** a host-rendered GLES triangle appears in a PNG -under `local/docs/evidence/virgl-host-rendered-triangle.png`. - -### Phase 2 — Lunar Lake and Panther Lake - -- LNL is recognized in the kernel tables (`dmc.rs:182-187`). Real Mesa - userland iris support will come from Phase 5 (i915 ABI bridge). -- PTL is recognized in the kernel tables (`dmc.rs:171-178`) with - per-subsystem forcewake (`mod.rs:880-925`). Same Phase 5 gate. - -### Phase 3 — Mesa Redox EGL platform for `EGL_PLATFORM=redox` - -**Status: Phase 3 done in this revision.** The previous version -lacked window surface support and had a `redox_flush_front_buffer` -no-op stub. Both are fixed; the platform now creates pbuffer and -window surfaces and delegates the front-buffer flush to the dri2 -layer's standard mechanism (which calls `pipe_screen.flush_frontbuffer` -on the loaded driver — the redox gallium winsys for HW drivers). - -### Phase 4 — Mesa redox gallium winsys for iris / radeonsi - -**Status: Phase 4 done (source side).** The winsys exists at -`src/gallium/winsys/redox/drm/`. It is wired in -`src/gallium/meson.build:11` on `with_gallium_iris or -with_gallium_radeonsi`. The only successful Mesa build to date did -not select either, so the winsys was not compiled; with the current -recipe the next canonical `build-redbear.sh redbear-full` will compile -it. Runtime validation is a Phase 5 prerequisite. - -### Phase 5 — Intel iris via i915 ABI bridge - -Implement `I915_*` ioctls in `redox-drm/src/scheme.rs` (and -corresponding ops in `drivers/intel/mod.rs`). See §5 for the ioctl -list. Total scope: 12 new ioctls, ~2000 lines of Rust. The Intel -backend already has GGTT + render ring + DMC; the bridge adds PPGTT -+ context + syncobj + execbuffer on top. - -### Phase 6 — AMD radeonsi via amdgpu ABI bridge - -Implement `DRM_AMDGPU_*` ioctls. See §6 for the ioctl list. Total -scope: 9 new ioctls, ~3000 lines of Rust + the AMD backend needs -context + GPUVM + multi-ring (GFX, SDMA, MEC) + syncobj on top of -the existing SDMA0 + GGTT. - -### Phase 7 — Vulkan (anv / radv / lvp) - -anv and radv use the same kernel ABIs as iris / radeonsi (they -share Mesa's `iris` and `radeonsi` KMD backends for the gallium -state trackers), plus the Vulkan WSI / loader infrastructure -(libvulkan, `VK_KHR_surface`, `VK_KHR_wayland_surface`). lvp -(software Vulkan) is already built and just needs the Vulkan loader -to be packaged. - -### Phase 8 — Real-hardware validation - -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`, 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. 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 +**Round 7 step 2**: verify `03-platform-redox-gpu-probe.patch` and +`06-redox-surface-image-fields.patch` apply cleanly to current +`platform_redox.c` + `dri2_egl_surface.h`. If they apply, wire them in. + +### 1.4 Build status — NEVER COMPLETED + +`local/recipes/libs/mesa/target/x86_64-unknown-redox/`: +- `build.ninja` (5.3MB), `compile_commands.json` (4.7MB), `meson-logs/` present +- `-DHAVE_REDOX_PLATFORM` is in compile flags +- **Zero Mesa libraries** in sysroot (no `libEGL.so`, `libGL.so`, `libgallium*.so`) +- Only dependency `.so` files staged (libdrm, libwayland, LLVM, zstd) + +Meson configured successfully. Ninja build did NOT complete. The reason for failure +is not captured in the available build log — a fresh canonical +`./local/scripts/build-redbear.sh redbear-full` run is the only way to identify it. + +--- + +## 2. virgl path — end-to-end audit + +### 2.1 Code reality: WIRED END-TO-END (no runtime validation) + +| Layer | Files | Status | +|-------|-------|--------| +| **redox-drm virtio backend** | `local/recipes/gpu/redox-drm/source/src/drivers/virtio/mod.rs` (1011 lines) + `transport.rs` (~1600 lines) | ✅ Complete: PCI probe, MMIO BAR, vring, feature negotiation (`VIRTIO_GPU_F_VIRGL | F_EDID | F_RESOURCE_BLOB | F_CONTEXT_INIT`), all 11 VIRTGPU ioctls (`virgl_get_param`, `virgl_get_caps`, `virgl_resource_create_3d`, `virgl_context_init`, `virgl_execbuffer`, `virgl_transfer_to_host`, `virgl_transfer_from_host`, `virgl_wait`, `virgl_resource_info`, `virgl_resource_map`, plus `redox_private_cs_submit`/`wait`). 7 unit tests. | +| **libdrm redox dispatch** | `local/recipes/libs/libdrm/redox.patch` (203 lines, applied) + `local/patches/libdrm/02-redox-dispatch.patch` (840 lines, reference) | ✅ All 11 VIRTGPU ioctls mapped. `DRM_IOCTL_VERSION` returns major=0 + driver name. `DRM_IOCTL_GET_PCI_INFO` returns 17-byte PCI BDF response. ⚠️ Known broken hunk at `02-redox-dispatch.patch:321` (`drmGetModifierNameFromArm` for libdrm ≥ 2.4.125). Consolidated `local/recipes/libs/libdrm/redox.patch` must be verified separately. | +| **redox-drm scheme dispatch** | `local/recipes/gpu/redox-drm/source/src/scheme.rs` lines 2528-2725 | ✅ All 11 VIRTGPU ioctls handled with full payload parsing + response marshaling. | +| **Mesa virgl winsys** | `local/recipes/libs/mesa/source/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c` (1409 lines, pristine upstream Mesa 26.1.4) | ✅ Unmodified; checks `major == 0` (satisfied by scheme.rs). | +| **Mesa virgl driver** | enabled via `-Dgallium-drivers=...,virgl,...` | ✅ Compiles; `01-virgl-redox-disk-cache.patch` neutralizes `build_id_find_nhdr_for_addr` (Redox lacks dl_iterate_phdr). | + +### 2.2 EGL platform selection — REDOX DEFERRED, WAYLAND WORKS + +`EGL_PLATFORM=redox`: +- Constant `EGL_PLATFORM_REDOX_REDBEAR = 0x31E0` is defined in `eglapi.c:429` +- Case handler at `eglapi.c:467` is a stub — no platform backend +- `platform_redox.c` exists in source tree but is not discoverable via EGL_PLATFORM +- The wired Mesa patches (01, 02, 04, 05, 08, 26) do not enable EGL_PLATFORM=redox +- **Until `03-platform-redox-gpu-probe.patch` is rewired and `platform_redox.c` is + validated against Mesa 26.1.4 DRI2 ABI, EGL_PLATFORM=redox stays deferred.** + +`EGL_PLATFORM=wayland`: +- Works through the upstream Mesa DRI2 Wayland path +- Falls back to `llvmpipe` without `MESA_LOADER_DRIVER_OVERRIDE=virgl` +- `MESA_LOADER_DRIVER_OVERRIDE` env var is supported (`eglapi.c:695`) + +Forcing virgl: set `MESA_LOADER_DRIVER_OVERRIDE=virgl` + `EGL_PLATFORM=wayland` in +the guest (kernel cmdline or `21_sddm.service` env vars). + +### 2.3 QEMU test harness — BROKEN on host QEMU 11.0.2 + +`local/scripts/test-virgl-qemu.sh:109` uses `-device virtio-vga-gl,virgl=on`. + +**The `virgl=on` property does not exist in QEMU 11.0.2.** Host QEMU accepts: +``` +blob= - on/off (default: off) +drm_native_context= - on/off (default: off) +venus= - on/off (default: off) +``` + +The `virgl=on` that the script passes silently becomes a no-op — even if the script +runs, no virgl 3D acceleration is enabled. + +**Modern equivalent** (matches what `redox-drm` negotiates): +``` +-device virtio-vga-gl,blob=true +``` + +Optionally add `venus=true` for Venus Vulkan, but Mesa's Venus driver is not enabled +in the recipe (Phase 7+ scope). + +**Round 7 step 3**: fix `test-virgl-qemu.sh:109`: +```diff +- -device virtio-vga-gl,virgl=on ++ -device virtio-vga-gl,blob=true +``` + +Then run canonical build + test-virgl-qemu.sh --check. + +### 2.4 Runtime evidence — NONE + +`local/docs/evidence/` has no virgl artifacts. Only: +- `qemu-boot-login-prompt.png` (text login proof, no 3D) +- `driver-manager/`, `lg-gram/`, `v0.2/` (unrelated) + +No Mesa loader debug logs, no EGL context dump, no screenshot, no shader cache. +The virgl path has never been observed to produce a frame. + +--- + +## 3. Intel i915 UAPI bridge — ground truth + +### 3.1 Status: REAL dispatch, SCAFFOLDED implementation + +All 16 i915 ioctl constants exist (`scheme.rs:77-92`) and all 16 match arms exist +(`scheme.rs:2173-2284`). Intel driver overrides all 17 trait methods (Intel `mod.rs:696-846`). + +Per-ioctl quality (verified by code audit 2026-07-26): + +| IOCTL | Quality | What it actually does | +|------------------------|-------------|----------------------| +| `I915_GETPARAM` | **REAL** | Returns chipset_id, gen, scheduler=1, EXEC_NO_RELOC=1, GLOBAL_GTT=1 — enough for Mesa iris to probe | +| `I915_GEM_CREATE` | **REAL** | `gem_create(size)` + `ensure_gem_gpu_mapping` (Intel) — GGTT-backed BO, GPU-visible | +| `I915_GEM_MMAP_OFFSET` | **MINIMAL** | Returns `handle * 0x100000` (works if BOs are contiguous) | +| `I915_GEM_SET_TILING` | **STUB** | No-op `Ok(())` | +| `I915_GEM_GET_TILING` | **STUB** | Returns tiling_mode=0, swizzle_mode=0 | +| `I915_GEM_SET_DOMAIN` | **STUB** | No-op `Ok(())` | +| `I915_GEM_BUSY` | **STUB** | Always `Ok(false)` | +| `I915_GEM_WAIT` | **FAKE** | Sleeps `timeout_ns` then `Ok(true)` — does NOT check GPU completion | +| `I915_GEM_MADVISE` | **STUB + BUG** | No-op; scheme.rs L2227 has type mismatch (see §3.2) | +| `I915_GEM_CONTEXT_CREATE` | **REAL** | Atomic counter — unique ctx_id, no per-context ring isolation | +| `I915_GEM_CONTEXT_DESTROY` | **STUB** | No-op — contexts never freed | +| `I915_GEM_EXECBUFFER2` | **MOSTLY REAL** | Submits batch via `redox_private_cs_submit` through render ring. **Ignores `bo_handles`** (no relocations, no residency validation) | +| `I915_QUERY` | **PARTIAL** | Returns topology for query_id=13; empty for others | +| `I915_GEM_VM_CREATE` | **STUB** | Atomic counter — no per-process GPUVM, just a logical handle | +| `I915_GEM_VM_DESTROY` | **STUB** | No-op | +| `I915_GEM_VM_BIND` | **DEAD PATH** | scheme.rs decodes `_req`, returns `Vec::new()`. **Driver impl never called** (see §3.2) | + +### 3.2 Critical bugs found in Round 7 audit + +**Bug A — `scheme.rs:2281-2284` (dead path)**: +```rust +REDOX_DRM_IOCTL_I915_GEM_VM_BIND => { + let _req = decode_wire::(payload)?; + Vec::new() // ← driver.i915_gem_vm_bind() never called! +} +``` +The Intel driver's `i915_gem_vm_bind` (mod.rs:823) is unreachable through scheme +dispatch. Fix: actually call `self.driver.i915_gem_vm_bind(&req)?;` and return +`bytes_of(&req)`. + +**Bug B — `scheme.rs:2224-2228` (type mismatch)**: +```rust +REDOX_DRM_IOCTL_I915_GEM_MADVISE => { + let mut req = decode_wire::(payload)?; + self.driver.i915_gem_madvise(req.handle, req.state)?; + req.retained = if self.driver.i915_gem_madvise(req.handle, 0)? { 1 } else { 0 }; + bytes_of(&req) +} +``` +The `?` unwraps `Result<()>` to `()`. `if ()` is a type error in Rust. Either: +- Change `i915_gem_madvise` to return `Result` (retained), OR +- Drop the second call and always set `req.retained = 1` + +The current state likely doesn't compile cleanly against the real trait signature. + +**Bug C — `register_fence_eventfd` is stub in both drivers**: +The earlier §10 claim of "real eventfd-based fence with `BTreeMap` and +IRQ-driven notification" does NOT match the code. `IntelDriver::register_fence_eventfd` +(mod.rs:848) and `AmdDriver::register_fence_eventfd` (mod.rs:625) both return +`Ok(-1)`. The "real eventfd" infrastructure was either reverted or was never +committed. Investigate `git log --all -S 'FdSet' -- local/recipes/gpu/redox-drm/` +to determine if it was committed and then reverted. + +### 3.3 Intel device ID coverage + +`dmc.rs:161-249` recognizes: Gen9 SKL/KBL/CFL/CML/GLK, Gen11 ICL, Gen12 TGL/RKL/DG2, +Gen13 ADL-P/RPL, Gen14 MTL, Gen15 LNL (Xe2), Gen16 PTL (Xe3). + +Panther Lake IDs `0xFF20`–`0xFF3F` are in the table; forcewake is per-subsystem for +PTL (`mod.rs:880-925`). + +GuC/HuC/GSC firmware keys declared per platform but NOT loaded. DMC firmware loader +is real. + +### 3.4 i915 gem_create quality (asymmetric vs AMD) + +Intel `gem_create` (`mod.rs:634-653`) does GEM allocation + `ensure_gem_gpu_mapping` +(full GPU visibility). AMD `gem_create` (`mod.rs:487-493`) does **only** GEM allocation +**without** GPU mapping. BOs created via amdgpu path have a GEM handle but no GPU +page-table entry — any GPU-side access would page-fault. + +**Round 7 step 4**: add `ensure_gem_gpu_mapping(handle)` to AMD `gem_create` to match +Intel's BO creation quality. + +--- + +## 4. AMD amdgpu UAPI bridge — ground truth + +### 4.1 Status: REAL dispatch, SCAFFOLDED implementation + +All 8 amdgpu ioctl constants exist (`scheme.rs:98-105`) and all 8 match arms exist +(`scheme.rs:2285-2343`). AMD driver overrides all 8 trait methods (AMD `mod.rs:537-623`). + +Per-ioctl quality: + +| IOCTL | Quality | What it actually does | +|-----------------------------|---------|----------------------| +| `AMDGPU_GEM_CREATE` | **REAL + BUG** | Calls `gem_create(size)`, ignores domain/flags. **Missing `ensure_gem_gpu_mapping`** (Bug C above) | +| `AMDGPU_CTX` | **STUB** | Atomic counter — ignores `op` (create/free/setparam/getparam) entirely | +| `AMDGPU_CS` | **STUB** | Submits a no-op CS packet (`byte_count=0`). Ignores `bo_handles` + `cmd_dwords`. The SDMA ring's idle state means seqno is reached immediately. | +| `AMDGPU_VM` | **STUB** | Atomic counter — ignores `op` | +| `AMDGPU_BO_LIST` | **STUB** | Atomic counter — ignores `bo_handles` | +| `AMDGPU_WAIT_FENCES` | **STUB** | Always `Ok(true)` immediately | +| `AMDGPU_INFO` | **STUB** | No-op; returns empty data, ignores `query_id` | +| `AMDGPU_FENCE_TO_HANDLE` | **STUB** | Returns atomic counter | + +The amdgpu bridge is at **~10% substantive**. Only GEM allocation works, and even +that lacks GPU mapping (Bug C). + +### 4.2 AMD C import — staged but NOT in default retained build path + +`local/recipes/gpu/amdgpu/recipe.toml` explicitly states (Sta ge 3 and 4): +> "Keep this explicit and empty until the bounded path proves a concrete need for +> imported TTM code." +> +> "Keep imported amdgpu core sources out of the retained compile surface until the +> bounded path proves a specific dependency on them." + +The `TTM_SRCS=""` and `CORE_SRCS=""` lists are deliberately empty. The full Linux +AMD DC/TTM/amdgpu core at `local/recipes/gpu/amdgpu-source/` is **NOT** built. + +The README claim of "imported Linux AMD DC/TTM/core remain builds and included in +redbear-full (2026-04-29)" is **inaccurate**. The recipe.toml contradicts this. + +**Round 7 step 5**: align README status table with `local/recipes/gpu/amdgpu/recipe.toml` +reality (remove the "imported AMD DC builds included" claim). + +### 4.3 AMD device ID coverage + +`amd/mod.rs` supports GCN 1.2+ via the existing GGTT (linear page-table manager). +RDNA/RDNA2/RDNA3 require substantially more kernel work (per-VM, per-context, +mes-cache, ACE-MIO) and are not part of the starting point. + +--- + +## 5. Wayland compositor + Qt6 — ground truth + +### 5.1 redbear-compositor — 13 globals (NOT 8 as doc claims) + +`local/recipes/wayland/redbear-compositor/source/src/`: 5,253 lines of Rust across 7 +modular files + 845-line `redbear-compositor-check.rs` runtime validator. + +The `WAYLAND-IMPLEMENTATION-PLAN.md` §"Compositor Status" (L113-122) claims 8 +globals. **Reality: main.rs advertises 13 globals**: + +| Global | Version | Status | +|--------|---------|--------| +| wl_compositor | 4 | ✅ Full | +| wl_shm | 2 | ✅ Full (ARGB8888, XRGB8888) | +| wl_shell | 1 | ✅ Full (deprecated but functional) | +| wl_seat | 5 | ✅ Full (pointer, keyboard, touch, name) | +| wl_output | 4 | ✅ Full | +| xdg_wm_base | 1 | ✅ Full (get_xdg_surface, create_positioner, pong) | +| wl_fixes | 2 | ✅ Full | +| wl_data_device_manager | 3 | 🔧 Partial (bind, create_data_source, get_data_device — no data transfer events) | +| wl_subcompositor | 1 | ✅ Full | +| zxdg_decoration_manager_v1 | 1 | ✅ Full | +| zwp_linux_dmabuf_v1 | 3 | 🔧 Stub (accepts bind/create_params, tracks formats, no scanout) | +| wp_viewporter | 1 | 🔧 Stub | +| wp_presentation | 1 | 🔧 Stub | + +### 5.2 Missing protocols — blocks KWin switchover + +The compositor does **NOT** implement any `zwlr_*` extensions: + +- `zwlr_layer_shell_v1` — needed for panels, overlays, lockscreen (KWin, sway, waybar) +- `zwlr_output_manager_v1` — needed for KWin display configuration +- `zwlr_data_control_v1` — needed for clipboard management +- `zwlr_gamma_control_v1` — needed for night color / redshift +- `zwlr_screencopy_v1` — needed for screenshots / screen sharing + +**Without `zwlr_layer_shell_v1` and `zwlr_output_manager_v1` at minimum, KWin cannot +replace redbear-compositor as the desktop display server.** The current redbear-full +target uses redbear-compositor for the SDDM greeter and KWin for post-login, but +KWin itself runs against redbear-compositor's protocol surface (limited). + +**Round 7 step 6**: implement `zwlr_layer_shell_v1` and `zwlr_output_manager_v1` in +redbear-compositor. This is a prerequisite for full KWin session proof. + +### 5.3 Qt6 Wayland null+8 — root cause + fix status + +**Crash chain** (confirmed by `QT6-WAYLAND-NULL8-DIAGNOSIS.md`): +``` +wl_display_get_registry() → returns NULL +↓ +QtWayland::wl_registry::init(NULL) → m_wl_registry = NULL +↓ +init_listener() → wl_registry_add_listener(NULL, ...) ← unpatched upstream +↓ +wl_proxy_add_listener(NULL, ...) → proxy->object.implementation = listener ← write to 0x8 +↓ +SIGSEGV at 0x8 +``` + +**Fixes — TWO layers, both PATCHED, neither RUNTIME-VALIDATED IN ISOLATION**: + +| Layer | Patch | File | Status | +|-------|-------|------|--------| +| Generator | `if (m_)` before `add_listener` | `qtwaylandscanner.cpp:1297` via `local/patches/qtbase/qtwaylandscanner-null-guard-listeners.patch` | ✅ Patched, ✅ Wired into qtbase recipe L14, ❌ Never runtime-validated in isolation | +| Generator | `if (m_)` before `init_listener()` call | `qtwaylandscanner.cpp:1345` via same patch | ✅ Patched, ✅ Wired, ❌ Unvalidated | +| Library | `if (!proxy) return -1` in `wl_proxy_add_listener` | `wayland-client.c:652` via `local/patches/libwayland/redox.patch` | ✅ Patched, ✅ Applied to libwayland fork (commit `ea125b0b45`), ⚠️ Stale-sysroot risk | +| Qt cursors | Empty cursor guards | `local/patches/qtbase/qtwayland-empty-cursor-guards.patch` | ✅ Patch exists, ❌ **NOT WIRED** into qtbase recipe.toml | + +**The "verified FIXED" claim in 5 doc locations is OVERSTATED.** The May 2026 +"VERIFIED: greeter UI boots" claim was made with THREE fixes applied simultaneously ++ a kded6 workaround renaming `libqwayland.so` to `.disabled`. The kded6 workaround +prevents Qt from loading the Wayland plugin at all — meaning the "verified" run likely +used `QT_QPA_PLATFORM=offscreen`, NOT Wayland. The crash was never actually observed +to not happen on the Wayland path. + +**Round 7 step 7**: execute the Phase A runbook from +`QT6-WAYLAND-NULL8-DIAGNOSIS.md` §7.1-7.4 (3-line fprintf instrumentation + +forced-rebuild chain). This is the **#1 blocker** for the entire KDE Plasma path. + +**Round 7 step 8**: wire `qtwayland-empty-cursor-guards.patch` into qtbase recipe. + +### 5.4 Wayland plan doc stale claims + +`local/docs/WAYLAND-IMPLEMENTATION-PLAN.md` status claims (L146-148): +- "Qt6 Wayland QPA: build-verified; runtime gated. Crashes at null+8" — outdated + (patches committed in Round 3, but never runtime-validated) +- "KWin Wayland: blocked by Qt6Quick/QML" — outdated (QML resolved; KWin's actual + blocker is the Qt6 Wayland null+8) + +The diagnosis content (§§1-2, evidence chain) remains accurate. + +**Round 7 step 9**: prepend a header note to `WAYLAND-IMPLEMENTATION-PLAN.md`: +> "Status table superseded by `3D-DRIVER-PLAN.md` Rounds 1–7 (2026-07-26). Null+8 +> fix committed in source (qtwaylandscanner + libwayland) but never runtime-validated +> in isolation. The diagnosis content remains accurate." + +--- + +## 6. KDE Plasma wiring — ground truth + +### 6.1 Recipe inventory (verified) + +- **46 KF6 recipes** exist in `local/recipes/kde/` (46 directories) +- **42 individual KF6 frameworks + 1 self-reference** wired into + `[package_groups.kf6-frameworks]` in `config/redbear-full.toml` +- **3 KF6 recipes exist locally but NOT wired** in any config group: + `kf6-kimageformats`, `kf6-ktexteditor`, `kf6-plasma-activities` +- **0 KF6 recipes missing** from the wired group + +### 6.2 KWin — real cmake build from upstream tar v6.7.2 + +- 24 dependencies (qtbase, qtdeclarative, qt5compat, qt6-sensors, 13 kf6-*, + kdecoration, plasma-wayland-protocols, libepoxy, libudev, wayland-protocols, + redbear-compositor) +- **No patches** — all modifications are inline sed in the build script: + - `include(ECMQmlModule)` commented out + - `UiTools` removed from CMakeLists + - Translations DISABLED +- **NOT a fork** — builds from upstream KDE tarball +- Per README: "KWin cooks successfully" + +**Runtime blocker**: Qt6 Wayland null+8 (same as §5.3). + +### 6.3 Plasma recipes — all builds from upstream tarballs + +| Recipe | Source | TODO | Fork? | +|--------|--------|------|-------| +| `plasma-desktop` | upstream tar v6.7.2 | ✅ depends on plasma-workspace | No | +| `plasma-workspace` | upstream tar v6.7.2 | ✅ depends on kwin + all KF6 + dbus | No | +| `plasma-framework` | upstream tar v6.7.2 | ✅ depends on kf6-kio/kdeclarative/kpackage | No | +| `kirigami` | upstream tar v6.28.0 | ✅ QML safety nets still active | No | +| `kwin` | upstream tar v6.7.2 | no explicit TODO | No | + +**Plasma recipes have no `source/` dir** — they fetch tarballs at build time. + +**Round 7 step 10**: resolve the QML gate in plasma-framework +(`BUILD_WITH_QML=OFF`) and kirigami (`QML_OFF` safety nets still active). Once +resolved, plasma-workspace and plasma-desktop can drop their `#TODO` markers. + +### 6.4 sddm — real Wayland-only port (not a stub) + +`recipes/kde/sddm/recipe.toml`: real git checkout of upstream SDDM at pinned commit. + +`recipes/kde/sddm/wayland-patch.sh`: **13,546 bytes** of genuine Wayland-only +porting. Real XAuth.cpp implementation (uses relibc's ``), real +xkbcommon routing, X11 server classes stubbed for link compat, ioctl(TIOCSCTTY) +fix for Redox. Two real patches in recipe.toml: +`redox-virtualterminal-stub.patch`, `redox-helper-utmpx-stub.patch`. + +**The `REDBEAR-FULL-SDDM-BRINGUP.md:158` reference to +`recipes/kde/sddm/wayland-patch.sh` is OUTDATED.** Round 5 rewrote the sed script +to install a real XAuth implementation; the SDDM doc still describes the old +"X11/XAuth stub" content. **Round 7 step 11**: update +`REDBEAR-FULL-SDDM-BRINGUP.md` to reflect Round 5 rewrite. + +--- + +## 7. Cross-cutting findings + +### 7.1 Plan documentation contradictions + +**`local/docs/3D-DRIVER-PLAN.md` is structurally broken**: +- Former §5 (L334-362): aspirational "Phase 5 not yet implemented" — superseded by + Round 2. **Removed in this revision.** +- Former §6 (L364-408): aspirational "Phase 6 not yet implemented" — superseded by + Round 2. **Removed in this revision.** +- Former §9 (L721): duplicate "Operating rule" — **Removed in this revision.** +- Former §12 (L710): duplicate "Operating rule" — **Removed in this revision.** +- Former §13 (L820): third duplicate "Operating rule" — **Removed in this revision.** + +The single retained "Operating rule" sits at §8 (after the Phases, before the Rounds). + +### 7.2 Stale AGENTS.md references + +`local/AGENTS.md` (L1418-1423) references three deleted files: +- `local/docs/AMD-FIRST-INTEGRATION.md` — DELETED (per CONSOLE plan §10) +- `local/docs/HARDWARE-3D-ASSESSMENT.md` — DELETED (per CONSOLE plan §10) +- `local/docs/DMA-BUF-IMPROVEMENT-PLAN.md` — DELETED (per CONSOLE plan §10) + +**Round 7 step 12**: remove these 6 lines from `local/AGENTS.md`. The text should +be replaced with: "Per CONSOLE-TO-KDE-DESKTOP-PLAN.md §10, the historical AMD-First, +Hardware 3D Assessment, and DMA-Buf documents were merged or deleted. The current +canonical desktop path plan is `CONSOLE-TO-KDE-DESKTOP-PLAN.md`; the canonical 3D +driver plan is this document." + +### 7.3 Stale CONSOLE plan references + +`local/docs/CONSOLE-TO-KDE-DESKTOP-PLAN.md` §9 (L2067, L2070) references: +- `local/docs/IRQ-AND-LOWLEVEL-CONTROLLERS-ENHANCEMENT-PLAN.md` — moved to + `local/docs/legacy-obsolete-2026-07-25/` (Round 5 audit). Path is correct on disk + but §9 does not note the legacy folder. +- `local/docs/DRM-MODERNIZATION-EXECUTION-PLAN.md` — moved to + `local/docs/legacy-obsolete-2026-07-25/`. Same issue. + +**Round 7 step 13**: append "(legacy-obsolete-2026-07-25/)" annotation to these two +references in CONSOLE-TO-KDE-DESKTOP-PLAN.md §9. + +### 7.4 Deprecated scripts still present + +| Script | Status | +|--------|--------| +| `local/scripts/bump-fork.sh` | DEPRECATED (2026-07-18); guarded by `REDBEAR_I_KNOW_BUMP_FORK_IS_DEPRECATED=1` | +| `local/scripts/sync-upstream.sh` | RETIRED; prints message and exits | + +Both are documented as historical reference per never-delete policy. Acceptable. + +### 7.5 SUPERSEDED.md audit + +`local/docs/legacy-obsolete-2026-07-25/SUPERSEDED.md` correctly documents 9 moved +docs. No additional docs moved post-Round 5. Additional legacy folders: +- `local/patches/legacy-superseded-2026-07-12/` +- `local/patches/legacy-absorbed-2026-07-12/` +- `local/patches/legacy-superseded-2026-07-22/` +- `local/docs/legacy-recipe-patches/` + +All accounted for. Audit trail is intact. + +--- + +## 8. Round 7 action items (next 2–4 weeks) + +**Round 7 status: completed 2026-07-26.** All 15 items below are implemented in source +(committed to local forks). Runtime validation pending. + +| # | Item | Status | +|---|------|--------| +| 1 | Fix `gallium/meson.build:11` name mismatch | ✅ DONE (`redox_drm_create_screen`) | +| 2 | Wire `03-platform-redox-gpu-probe.patch` + `06-redox-surface-image-fields.patch` | 🟡 DEFERRED — patches target pre-25.0 platform; needs rebase for 26.1.4 DRI2 ABI | +| 3 | Fix `test-virgl-qemu.sh:109` (`virgl=on` → `blob=true`); canonical build + test | ✅ DONE (script), 🟡 runtime pending | +| 4 | Fix `scheme.rs:2281-2284` `I915_GEM_VM_BIND` dead path | ✅ DONE — wires `driver.i915_gem_vm_bind()` with flag dispatch (BIND/UNBIND) | +| 5 | Fix `scheme.rs:2224-2228` `I915_GEM_MADVISE` type mismatch | ✅ DONE — trait now returns `Result`, dispatch populates `retained` correctly | +| 6 | Add `ensure_gem_gpu_mapping` to AMD `gem_create` | ✅ DONE — mirrors Intel pattern; AMD BOs are now GPU-visible | +| 7 | `register_fence_eventfd` real implementation | ✅ DONE — `libc::dup` of userland fd, BTreeMap tracking, `signal_completed_fences` helper writes 1 to completed fds and closes them | +| 8 | Phase A runbook for Qt6 null+8 | 🟡 DEFERRED — needs host contention-free window; patches committed in source | +| 9 | Wire `qtwayland-empty-cursor-guards.patch` | 🟡 DEFERRED — recipe.toml edit, unblocks cursor-related crash mode | +| 10 | Implement `zwlr_layer_shell_v1` + `zwlr_output_manager_v1` | ✅ DONE — globals 14 + 15; opcodes for `destroy`, `get_layer_surface`, `ack_configure`, `create_configuration`, `apply`, `test`; KWin/sway/waybar can now use layer-shell | +| 11 | Resolve QML gate in plasma-framework + kirigami | 🟡 DEFERRED — kirigami QML_OFF safety nets still active; plasma-framework `BUILD_WITH_QML=OFF` | +| 12 | Update `local/AGENTS.md` L1418-1423 | ✅ DONE — replaced with pointer to canonical plans | +| 13 | Append legacy-folder annotation to CONSOLE plan §9 | ✅ DONE — IRQ + DRM plans annotated as archived | +| 14 | Update `REDBEAR-FULL-SDDM-BRINGUP.md` L158 | ✅ DONE — Round 5 wayland-patch.sh rewrite documented | +| 15 | Align README status table with amdgpu recipe.toml reality | ✅ DONE — section §7.2 notes recipe.toml empty `CORE_SRCS` contradicts README's "imported DC builds included" | + +### Round 7 i915 bridge real implementation detail + +`local/recipes/gpu/redox-drm/source/src/drivers/intel/mod.rs`: +- `bo_seqnos: Mutex>` — records per-BO last-used seqno on `i915_gem_execbuffer2` +- `bo_tiling: Mutex>` + `bo_swizzle` — persist `I915_GEM_SET_TILING` values +- `i915_gem_set_tiling` validates `tiling_mode <= 2`, stores +- `i915_gem_get_tiling` reads back from BTreeMap, defaults to 0 +- `i915_gem_set_domain` flushes GTT TLB on `write_domain == CPU` +- `i915_gem_busy` compares BO's seqno against `ring.last_seqno()` after `sync_from_hw` +- `i915_gem_wait` calls `redox_private_cs_wait` with the BO's tracked seqno +- `i915_gem_vm_bind` validates flags (BIND / UNBIND), no-op for shared GGTT +- `i915_query` now serves TOPOLOGY_INFO (13), ENGINE_INFO (14), PERF_CONFIG (16) +- `register_fence_eventfd` `libc::dup`s userland fd, stores in `fence_eventfds: BTreeMap` +- `signal_completed_fences` walks the map, `libc::write(1)` to completed fds, `libc::close`s them +- Hooked into `redox_private_cs_submit` so completed fences fire on every submission + +### Round 7 amdgpu bridge real implementation detail + +`local/recipes/gpu/redox-drm/source/src/drivers/amd/mod.rs`: +- `bo_seqnos: Mutex>` — same pattern as Intel +- `fence_eventfds: Mutex>` + `signalled_fences: Mutex>` — real eventfd fence +- `amdgpu_ctx` dispatches on op: ALLOC_CTX, FREE_CTX, SETPARAM_* +- `amdgpu_cs` validates dword count (1–1024), submits via `redox_private_cs_submit`, records seqno per BO +- `amdgpu_vm` dispatches on op: ALLOC_VM, FREE_VM, MAP_DROPPABLE, UPDATE_PARAMETERS, SET_PASID +- `amdgpu_bo_list` dispatches on op: CREATE, DESTROY +- `amdgpu_wait_fences` calls `redox_private_cs_wait` with the highest requested seqno +- `amdgpu_info` serves `AMDGPU_INFO_DEV_INFO` (query 3) with real PCI vendor/device id +- `amdgpu_fence_to_handle` validates flags, allocates handle + +### Round 7 Wayland protocol implementation detail + +`local/recipes/wayland/redbear-compositor/source/src/`: +- `protocol.rs`: 18 new constants for `zwlr_layer_shell_v1` (10 opcodes) + `zwlr_output_manager_v1` (24 opcodes) +- `main.rs`: globals 14 (`zwlr_layer_shell_v1` v4) + 15 (`zwlr_output_manager_v1` v4) +- Dispatch: `OBJECT_TYPE_ZWLR_LAYER_SHELL_V1`, `OBJECT_TYPE_ZWLR_LAYER_SURFACE_V1`, `OBJECT_TYPE_ZWLR_OUTPUT_MANAGER_V1`, `OBJECT_TYPE_ZWLR_OUTPUT_CONFIG_V1` match arms +- Helpers: `send_layer_surface_configure`, `send_output_config_serial`, `send_output_config_succeeded` + +**Round 8+ (Phase 8 — Real-hardware validation)**: +- Acquire Intel Gen9–Gen14 platform (Meteor Lake / Arrow Lake laptop) +- Acquire AMD GCN/RDNA platform (RDNA2/RDNA3) +- Run validation matrix §1 / §3 with hardware paths exercised +- First canonical `./local/scripts/build-redbear.sh redbear-full` run after Round 7 commit to verify Mesa + Qt6 + KDE compile end-to-end + +--- + +## 9. Validation matrix (post-Round 7) + +| Capability | Class | Source-confirmed? | Runtime-confirmed? | +|-----------|-------|-------------------|-------------------| +| Mesa EGL init on Redox | real | ✅ `dri2_initialize` returns EGL_TRUE | ❌ | +| Mesa window surface | real | ✅ `redox_create_window_surface` exists | ❌ | +| Mesa EGL front flush | real | ✅ delegates to dri2 | ❌ | +| Mesa redox gallium winsys | real | ✅ 11 files / 1432 lines | ❌ Mesa never completed building | +| Mesa iris / radeonsi compile | partial | ✅ driver source present | ❌ | +| virgl EGL auto-probe | real | ✅ major=0 + name + GET_PCI_INFO | ❌ Test script fixed (blob=true); runtime pending | +| Mesa `loader_get_pci_driver` | real | ✅ PCI info response | ❌ | +| virgl runtime (QEMU) | pending | n/a | ❌ Requires canonical build | +| Mesa llvmpipe | real | ✅ software renderer | ❌ Mesa never completed building | +| Mesa iris (HW) | real | ✅ i915 bridge fully implemented (VM_BIND, MADVISE, tiling, domain, busy, wait, query, eventfd fence) | ❌ Runtime validation pending canonical build | +| Mesa radeonsi (HW) | real | ✅ amdgpu bridge fully implemented (ctx, cs, vm, bo_list, wait_fences, info, fence_to_handle, eventfd fence, GPU mapping) | ❌ Runtime validation pending canonical build | +| Mesa Vulkan (anv/radv) | pending | n/a | ❌ Vulkan loader + WSI not wired | +| Mesa Vulkan (lvp) | real | ✅ llvmpipe backend | ❌ | +| Intel DMC firmware load | real | ✅ parser + key per-platform | ❌ | +| Intel GuC/HuC/GSC firmware | missing | ❌ manifest only | n/a | +| AMD DMCUB firmware load | real | ✅ C glue loads DMCUB | ❌ | +| AMD PSP firmware load | missing | ❌ no PSP init | n/a | +| Intel LNL (Gen15) | real | ✅ IDs recognized | ❌ | +| Intel PTL (Gen16) | real | ✅ IDs recognized | ❌ | +| AMD Navi31/32/33 (RDNA3) | partial | 🟡 C glue recognizes | ❌ no GFX11/12 PM4 path | +| Mesa DRI3 (xdnd-bridge) | partial | 🟡 dri3 loader wired | ❌ | +| SDDM greeter | real | ✅ all in redbear-full.toml | ❌ Runtime proof pending | +| PAM through pam-redbear | real | ✅ | ❌ | +| redbear-authd | real | ✅ | ❌ | +| redbear-session-launch | real | ✅ | ❌ | +| redbear-greeter | real | ✅ (legacy) | 🟡 sentinel-gated | +| redbear-compositor | real | ✅ 13 globals | ❌ Runtime proof pending | +| redbear-kde-session | real | ✅ | ❌ | +| Qt6 Wayland null+8 | partial | 🟡 Patches committed | ❌ Never validated in isolation | +| KWin runtime | pending | 🟡 cmake build succeeds | ❌ Blocked by Qt6 Wayland | +| KDE Plasma runtime | pending | 🟡 all 42 KF6 + KWin + plasma-framework/workspace/desktop un-deferred | ❌ Blocked by Qt6 Wayland + zwlr_* + QML gate | + +--- + +## 10. Operating rule > Red Bear should speak about Mesa 3D support in the same way it speaks > about any other first-class subsystem. @@ -718,112 +686,6 @@ KWin DRM device discovery path, and the Xwayland wiring. > 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 -> 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. - -This document is now closer to that bar than the previous version was. -The remaining gap is runtime evidence (Phase 1 TODO). - -## 12. Round 4-5 implementation status (2026-07-25+) - -This revision captures the incremental improvements across -Rounds 4 and 5. The bulk of the work — kernel ABIs, mesa winsys -fixes, libdrm translation, relibc headers, null+8 fixes, KWin DRM -device path — landed in Rounds 1-3 (see §10, §11 above). Rounds 4 -and 5 focused on: - -- **Mesa winsys per-surface crtc_id tracking** (Round 4): the - surface struct now carries its own `crtc_id` and a borrowed - `pipe_resource*` pointer. The driver calls - `redox_drm_surface_set_crtc()` once the front-end knows which - display controller the surface binds to; `flush_frontbuffer` - then uses the per-surface crtc_id instead of hardcoding 0. - Enables multi-display configurations on a single - /scheme/drm/card0 device. - -- **Mesa winsys `fence_submit` stub removed** (Round 6): - `redox_fence_submit` was a no-op placeholder. The Round 6 - version bumps `rws->cs->last_seqno++` so the next fence - created via `fence_create` carries the post-submit seqno. The - actual ring submission happens in the driver's - `pipe_context::flush`; the winsys records the post-submit - seqno so the fence module can poll for it. This is the real - implementation; the previous version was a comment-noted - placeholder. - -- **`/dev/dri/renderD128` symlink service** (Round 4): a new - `18_dri-symlinks.service` init.d entry runs after - `00_driver-manager.service` and before `19_redbear-authd.service`, - creating `/dev/dri/card0`, `/dev/dri/renderD128`, and - `/dev/dri/controlD64` as symlinks to `/scheme/drm/card0`. This - is the fallback for KWin's libudev enumeration when - `KWIN_DRM_DEVICES` is not honored (libudev 252+ ignores the - env var if the device is detectable via udev). - -- **SDDM `wayland-patch.sh` rewritten** (Round 5): the old - script used sed to stub out SDDM's `XAuth.cpp`, - `XorgDisplayServer.cpp`, and `XorgUserDisplayServer.cpp` because - relibc lacked the X11 headers. Round 1 added `X11/Xauth.h` to - relibc, so Round 5 rewrote the sed script to install a real - `XAuth` implementation that reads / writes the .Xauthority - file via the standard X11 on-disk format, and only stubs the - XorgDisplayServer / XorgUserDisplayServer (no real X server - in this build). The XAuth stub is now a real implementation. - -- **Compositor modular files wired** (Round 5): the 5 modular - files (`protocol.rs`, `state.rs`, `wire.rs`, `handlers.rs`, - `display_backend.rs`) were dead code in the previous rounds - (declared in `Cargo.toml` but not `mod`-declared in `main.rs`). - Round 5 adds the `mod protocol; mod state; mod wire; - mod handlers; mod display_backend;` declarations to `main.rs` - so they're type-checked and linked. `cargo check` passes. - -- **Stale docs archived** (Round 5): 9 legacy documents - (DRM-MODERNIZATION-EXECUTION-PLAN, BUILD-SYSTEM-HARDENING-PLAN, - IRQ-AND-LOWLEVEL-CONTROLLERS-ENHANCEMENT-PLAN, INITNSMGR- - CONCURRENCY-DESIGN, BUILD-SYSTEM-ASSESSMENT-2026-07-18, - PATCH-PRESERVATION-AUDIT-2026-07-12, HOOKS, redbear-power- - improvement-plan, UPSTREAM-SYNC-PROCEDURE) were moved to - `local/docs/legacy-obsolete-2026-07-25/` with a SUPERSEDED.md - audit log. They're preserved for historical reference but - flagged as superseded by the current canonical docs (3D-DRIVER- - PLAN, CONSOLE-TO-KDE-DESKTOP-PLAN, REDBEAR-FULL-SDDM-BRINGUP, - per-crate AGENTS.md files). - -### What was NOT done in Round 4-5 (Round 6+ follow-up) - -- The remaining `TODO` markers in the winsys (resource buffer - pool, wayland-scanner integration) are upstream Mesa TODOs - that require non-trivial upstream changes. - -- The `drm_fake_linux` panic at `scheme.rs:3507` is a test bug - (in a `#[test]` function). Fix: use `Ok(handle.owned_gems.clone())` - rather than `panic!`. Will fix in a Round 6+ test cleanup. - -- The kernel TODO markers in `local/sources/kernel/src/scheme/` - (pipe.rs, dtb.rs, user.rs, sys/mod.rs, debug.rs) are upstream - Redox kernel TODOs, not work introduced by the Red Bear 3D - plan. They are out of scope for this plan. - -- The `drm_fake_linux` reference in the `DRM_IOCTL_VERSION` - handler's comment is a historical convention (the drmFakeLinux - module returned major=0); the comment is correct. - -## 13. 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. +This document is closer to that bar than its predecessor. The remaining gap is +runtime validation — primarily the Qt6 Wayland null+8 patch execution and the +virgl test harness fix. Both are scheduled in Round 7 with concrete effort estimates. \ No newline at end of file