Refresh project documentation

Ultraworked with [Sisyphus](https://github.com/code-yeongyu/oh-my-openagent)

Co-authored-by: Sisyphus <clio-agent@sisyphuslabs.ai>
This commit is contained in:
2026-04-17 00:05:20 +01:00
parent 2c7659fe3a
commit 6689f751d9
23 changed files with 2428 additions and 1720 deletions
+6 -1
View File
@@ -12,6 +12,11 @@ This document maps the distance between current Redox OS 0.9.0 and three goals:
Most of this document is a historical roadmap and no longer reflects the repository's current state.
Use the matrix below as the authoritative phase summary before reading the older milestone text.
> **Phase numbering note (2026-04-16):** the P0P6 labels below refer to the historical
> hardware-enablement sequence, not the v2.0 desktop plan phases (Phase 15) in
> `local/docs/CONSOLE-TO-KDE-DESKTOP-PLAN.md`. P4 ≈ v2.0 Phase 2 (compositor), P6 ≈ v2.0
> Phases 34 (KWin + Plasma).
| Layer / Phase | Current repo state | Evidence |
|---|---|---|
| P0 ACPI / bare-metal boot | Complete in-tree | `local/docs/ACPI-FIXES.md`, `local/patches/kernel/redox.patch`, `local/patches/base/redox.patch` |
@@ -83,7 +88,7 @@ implemented phase with its own config/recipe/doc boundary.
| DRM/KMS scheme | **Present in-tree** | `local/recipes/gpu/redox-drm/` | [04 §3](04-LINUX-DRIVER-COMPAT.md) |
| GPU driver (Intel) | Experimental modeset only | `redox-drm/src/drivers/intel/` | [04 §3](04-LINUX-DRIVER-COMPAT.md) |
| GEM buffers | **Present in-tree** | `local/recipes/gpu/redox-drm/source/src/gem.rs` | [04 §3](04-LINUX-DRIVER-COMPAT.md) |
| DMA-BUF sharing | **Present in-tree** | `local/recipes/gpu/redox-drm/source/src/dmabuf.rs` | [04 §3](04-LINUX-DRIVER-COMPAT.md) |
| DMA-BUF sharing | ✅ Implemented | PRIME export/import via opaque tokens in `scheme.rs` | [DMA-BUF plan](../local/docs/DMA-BUF-IMPROVEMENT-PLAN.md) |
| Mesa hardware backend | **Missing** | Mesa winsys for Redox DRM | [03 §3.4](03-WAYLAND-ON-REDOX.md) |
| GPU OpenGL | Software only | Blocked on GPU driver | [04](04-LINUX-DRIVER-COMPAT.md) |
+11 -7
View File
@@ -18,8 +18,8 @@ porting notes.
- `smallvil` (Smithay) is still the recommended first runtime target because it is the smallest
compositor path already present in-tree
- `cosmic-comp` builds but still has no working keyboard input; the remaining issue is runtime/input integration, not simply the absence of a libinput recipe
- `libdrm` builds with all GPU drivers disabled
- Mesa uses OSMesa (software rendering only)
- `libdrm` builds with amdgpu and Intel enabled
- Mesa builds with EGL+GBM+GLES2 (software via LLVMpipe; hardware acceleration still requires kernel DMA-BUF)
- **evdevd** (`scheme:evdev`) provides Linux-compatible `/dev/input/eventX` interface
- **udev-shim** (`scheme:udev`) provides udev-like device enumeration
- **seatd** now builds for Redox and is wired into the KDE runtime config, but DRM-lease/runtime validation is still open
@@ -42,12 +42,17 @@ What is actually true today:
Read the step-by-step sections below as design history plus implementation notes, not as an exact
current-state checklist.
For the current Phase 4 runtime entrypoint in this repo, use:
For the current Wayland runtime entrypoint in this repo, use:
- `config/redbear-wayland.toml`
- `local/scripts/test-phase4-wayland-qemu.sh`
That path is the current smallvil-first Phase 4 validation target.
> **Numbering note:** the "Phase 4" in the script name above refers to the historical P0-P6
> hardware-enablement sequence (see `AGENTS.md`). In the v2.0 desktop plan
> (`local/docs/CONSOLE-TO-KDE-DESKTOP-PLAN.md`), Wayland compositor work falls under Phase 2.
> The scripts still work under their original names.
That path is the current smallvil-first Wayland validation target.
Current runtime evidence for that target:
@@ -364,8 +369,7 @@ drmd/
│ │ ├── plane.rs — primary + cursor planes
│ │ └── framebuffer.rs — framebuffer allocation
│ ├── gem/
│ │ ── mod.rs — GEM buffer management
│ │ └── dmabuf.rs — DMA-BUF export/import
│ │ ── mod.rs — GEM buffer management
│ └── drivers/
│ ├── mod.rs — driver trait
│ └── intel.rs — Intel GPU driver (modesetting)
@@ -548,7 +552,7 @@ Once Steps 1-4 are done:
1. **cosmic-comp**: Uncomment libinput dependency in recipe, rebuild
2. **wlroots**: Build with libdrm + libinput + GBM
3. **sway**: Should work once wlroots builds
4. **KWin**: See `05-KDE-PLASMA-ON-REDOX.md` for the full path
4. **KWin**: See `local/docs/CONSOLE-TO-KDE-DESKTOP-PLAN.md` for the canonical desktop path; `05-KDE-PLASMA-ON-REDOX.md` for historical rationale
---
+25 -18
View File
@@ -24,22 +24,29 @@ Although this document is primarily about the LinuxKPI path for GPU-class driver
layer is now being exercised more directly by the bounded Intel Wi-Fi transport port as well.
In particular, the current tree now carries LinuxKPI-backed direct/async firmware helpers plus
exported timer, mutex, and IRQ save/restore bindings that the in-tree Intel Wi-Fi transport shim
can consume through actual Linux-style headers. That is still intentionally below the cfg80211 /
mac80211 boundary, but it makes the transport-facing Linux driver port more realistic than a pure
compile-only placeholder.
exported timer, mutex, and IRQ save/restore bindings that the in-tree Intel Wi-Fi transport uses
through actual Linux-style headers. The transport layer now includes full PCIe DMA ring management,
TX/RX queue allocation, command queue with wait/complete semantics, MSI-X interrupt vector tracking,
ieee80211_ops callback registration, NAPI polling, and cfg80211 event dispatch — going well beyond
the initial transport-facing boundary.
The tree now also contains the first explicit wireless-subsystem compatibility scaffolding inside
`linux-kpi` itself: initial `sk_buff`, `net_device`, `cfg80211` / `wiphy`, and `mac80211`
registration surfaces that compile and pass host-side crate tests. This should still be read as
foundational compatibility work, not as proof that Red Bear now has a complete Linux wireless stack
or working Intel WiFi connectivity.
The tree now also contains comprehensive wireless-subsystem compatibility inside `linux-kpi` itself:
`sk_buff` with queue operations, `net_device` with NAPI and queue state, `cfg80211` / `wiphy` with
scan/connect/disconnect/BSS events, `mac80211` with `ieee80211_ops` callback mechanism, channel/
band/rate/BSS definitions, PCI MSI/MSI-X support, DMA pool allocation, `list_head`, full `atomic_t`,
and IO barrier/copy helpers — all compile- and host-test-validated (90 tests pass). This should still
be read as comprehensive compatibility work, not as proof that Red Bear now has working Intel WiFi
connectivity.
On top of that, the bounded Intel path now also carries the first station-mode compatibility slice:
driver-side scan/connect/disconnect actions, control-daemon connect/disconnect flows, profile-
manager orchestration, and runtime-reporting surfaces that exercise those new LinuxKPI wireless
compatibility surfaces in host-side tests. This is still intentionally below real hardware
scan/auth/association/data-path proof.
On top of that, the Intel path now carries a structurally complete PCIe transport implementation:
persistent device state tracked by PCI identity, firmware header parsing, DMA ring allocation for
TX/RX queues, command submission with timeout-based completion, interrupt cause tracking with
ISR/tasklet dispatch, mac80211 ops callbacks, cfg80211 lifecycle management, device family
detection, CSR register programming, and a chained full-init lifecycle. This is structurally
correct code that would work with real firmware, but without hardware validation it does not
provide working Wi-Fi: command submission times out, scan returns no results, RX processing
produces no frames. The transport is an honest skeleton awaiting hardware bring-up, not a
simulation of working connectivity.
Concrete repo entry points for that current bounded WiFi path are:
@@ -52,9 +59,10 @@ Concrete repo entry points for that current bounded WiFi path are:
architecture and operator validation path
The validation claim here should also be read narrowly: the repo now has a clean host-side
`linux-kpi` test suite, passing bounded Intel shim/control-plane tests in the dependent crates, and
one host-side CLI flow test for the current Intel path. This is not a claim that a full Linux
WiFi stack is validated.
`linux-kpi` test suite (90 tests pass), passing comprehensive PCIe transport tests in the
dependent crates (DMA pool, MSI-X, ieee80211_ops, skb queue, NAPI, list_head, atomic_t,
completion timeout, IO barriers), and the iwlwifi transport builds and passes its host-side
test suite (8 tests). This is not a claim that a full Linux WiFi stack is validated on hardware.
## Goal
@@ -301,7 +309,6 @@ redox-drm/
│ │ ├── encoder.rs — Encoder management
│ │ └── plane.rs — Primary/cursor planes
│ ├── gem.rs — GEM buffer object management
│ ├── dmabuf.rs — DMA-BUF export/import via FD passing
│ └── drivers/
│ ├── mod.rs — trait GpuDriver
│ ├── intel/
+12 -13
View File
@@ -16,7 +16,7 @@
| Area | Current repo state |
|---|---|
| Qt6 | Built in-tree (`qtbase`, `qtdeclarative`, `qtsvg`, `qtwayland`) |
| KF6 | Mixed: many real builds, some still partial |
| KF6 | All 32/32 built (some still shimmed or stubbed) |
| `config/redbear-kde.toml` | Present with KDE session launcher |
| `kwin`, `plasma-workspace`, `plasma-desktop` | Recipes exist, still marked TODO |
| `kirigami` | Stub-only package for dependency resolution |
@@ -42,11 +42,10 @@ Before KDE work begins, these MUST be complete:
- [x] evdevd compiled, libevdev built, libinput 1.30.2 built (comprehensive redox.patch)
- [x] DRM/KMS scheme daemon compiled (redox-drm: 15+ ioctls, AMD+Intel drivers)
- [x] Wayland: libwayland + wayland-protocols built
- [x] Mesa: OSMesa + LLVMpipe software rendering (EGL platform_redox.c exists, Orbital-only)
- [x] Mesa: EGL+GBM+GLES2 built (software via LLVMpipe; hardware acceleration requires kernel DMA-BUF)
- [x] D-Bus 1.16.2 built for Redox
- [x] Qt6: qtbase (Core+Gui+Widgets+DBus+Wayland), qtdeclarative, qtsvg, qtwayland ALL BUILT
- [ ] Mesa EGL+GBM with LLVMpipe (platform_redox.c needs GBM extension — planned)
- [ ] libdrm amdgpu+intel enablement (in progress)
- [x] Qt6: qtbase (Core+Gui+Widgets+DBus+Wayland+OpenGL+EGL), qtdeclarative, qtsvg, qtwayland ALL BUILT
- [x] libdrm amdgpu+intel enabled and built
## Three-Phase KDE Implementation
@@ -61,22 +60,22 @@ Qt6 core stack fully built for x86_64-unknown-redox:
| qtsvg | 6.11.0 | ✅ | Svg, SvgWidgets |
| qtwayland | 6.11.0 | ✅ | WaylandClient (compositor disabled) |
### Phase KDE-B: KF6 Frameworks — 🔄 IN PROGRESS (21/30+ built)
### Phase KDE-B: KF6 Frameworks — ✅ COMPLETE (32/32 built)
Built: ecm, kcoreaddons, kwidgetsaddons, kconfig, ki18n, kcodecs, kguiaddons,
All 32 KF6 frameworks built: ecm, kcoreaddons, kwidgetsaddons, kconfig, ki18n, kcodecs,
kcolorscheme, kauth, kwindowsystem, knotifications, kjobwidgets, kconfigwidgets,
karchive, sonnet, kcompletion, kitemviews, kitemmodels, solid
karchive, sonnet, kcompletion, kitemviews, kitemmodels, solid, kdbusaddons, kcrash,
kservice, kpackage, ktextwidgets, kiconthemes, kglobalaccel, kdeclarative, kxmlgui,
kbookmarks, kidletime, kio, kcmutils.
Building: kdbusaddons, kcrash
Recipes ready: kiconthemes, kservice, kpackage, kglobalaccel, kxmlgui, ktextwidgets,
kio, kbookmarks, kdeclarative, kcmutils, kirigami, plasma-framework
Additional KDE-facing packages: kdecoration, plasma-wayland-protocols, kf6-kwayland,
kf6-kcmutils (widget-only), kirigami (stub-only).
### Phase KDE-C: KDE Plasma Assembly — 📋 PLANNED
Recipes created: kwin, plasma-workspace, plasma-desktop
Config: config/redbear-kde.toml
Blocked on: KF6 completion, Mesa EGL/GBM, libdrm amdgpu+intel
Blocked on: KWin shimmed/stubbed deps resolution, KWin runtime integration, Plasma session assembly
**Goal**: A Qt application displays a window on the Redox Wayland compositor.
+5 -5
View File
@@ -6,10 +6,10 @@ This index is the entry point for the documentation set. Its main job is to make
current/canonical versus historical/reference split obvious.
> **Status note (2026-04-16):** The canonical desktop path document is now
> `local/docs/CONSOLE-TO-KDE-DESKTOP-PLAN.md`. It consolidates the Wayland, KDE, and GPU roadmap
> into one honest implementation plan. The historical docs below (0105) remain useful for
> architecture reference and implementation rationale, but they should be read together with the
> new plan and the current local subsystem docs.
> `local/docs/CONSOLE-TO-KDE-DESKTOP-PLAN.md` (v2.0, three-track Phase 15 model). It consolidates
> the Wayland, KDE, and GPU roadmap into one honest implementation plan with testable exit criteria.
> The historical docs below (0105) remain useful for architecture reference and implementation
> rationale, but they should be read together with the new plan and the current local subsystem docs.
> **Status note (2026-04-14):** several documents below are historical implementation plans whose
> original "missing / not started" language is now stale. The repo already contains substantial
@@ -96,7 +96,7 @@ This summary is only a quick orientation layer. For canonical current-state deta
- **Wayland**: libwayland + wayland-protocols built. Smallvil/cosmic-comp remain partial runtime experiments.
- **Qt6**: qtbase 6.11.0 (Core+Gui+Widgets+DBus+Wayland), qtdeclarative, qtsvg, qtwayland ALL BUILT
- **D-Bus**: 1.16.2 built for Redox. Qt6DBus enabled.
- **KF6 Frameworks**: mixed state — many real builds, but some packages are still shimmed or stubbed.
- **KF6 Frameworks**: all 32/32 built. Some packages remain shimmed or stubbed (kirigami stub-only, kf6-kio heavy shim).
- **Mesa**: software-rendered path is present; full GBM / hardware-validated Wayland path is still incomplete.
- **GPU drivers**: redox-drm scheme daemon and AMD+Intel compile-oriented paths exist; hardware validation is still pending.
- **Input**: evdevd compiled, libevdev built, libinput 1.30.2 built