diff --git a/docs/05-KDE-PLASMA-ON-REDOX.md b/docs/05-KDE-PLASMA-ON-REDOX.md index 438d1f60..a505590d 100644 --- a/docs/05-KDE-PLASMA-ON-REDOX.md +++ b/docs/05-KDE-PLASMA-ON-REDOX.md @@ -10,6 +10,9 @@ > `local/docs/DESKTOP-STACK-CURRENT-STATUS.md` together with > `local/docs/QT6-PORT-STATUS.md`. This file should now be read primarily as implementation history > plus deeper KDE-specific rationale and porting notes. +> +> The phase and step labels below are retained for historical structure. They are not the current +> planning authority for KDE/desktop sequencing. ## Current State Snapshot @@ -49,7 +52,7 @@ Before KDE work begins, these MUST be complete: ## Three-Phase KDE Implementation -### Phase KDE-A: Qt Foundation — ✅ COMPLETE +### Historical Phase KDE-A: Qt Foundation build milestone Qt6 core stack fully built for x86_64-unknown-redox: @@ -60,7 +63,7 @@ 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 — ✅ COMPLETE (32/32 built) +### Historical Phase KDE-B: KF6 Frameworks build milestone (32/32 built, some shimmed/stubbed) All 32 KF6 frameworks built: ecm, kcoreaddons, kwidgetsaddons, kconfig, ki18n, kcodecs, kcolorscheme, kauth, kwindowsystem, knotifications, kjobwidgets, kconfigwidgets, @@ -71,7 +74,7 @@ kbookmarks, kidletime, kio, kcmutils. Additional KDE-facing packages: kdecoration, plasma-wayland-protocols, kf6-kwayland, kf6-kcmutils (widget-only), kirigami (stub-only). -### Phase KDE-C: KDE Plasma Assembly — 📋 PLANNED +### Historical Phase KDE-C: KDE Plasma Assembly path Recipes created: kwin, plasma-workspace, plasma-desktop Config: config/redbear-kde.toml @@ -79,7 +82,7 @@ Blocked on: KWin shimmed/stubbed deps resolution, KWin runtime integration, Plas **Goal**: A Qt application displays a window on the Redox Wayland compositor. -#### Step 1: Port `qtbase` (6-8 weeks) +#### Historical Step 1: Port `qtbase` (6-8 weeks) > **Historical recipe note:** the `recipes/wip/qt/...` path below is retained as design history. > For current Red Bear ownership and shipping decisions, use the WIP ownership policy and current @@ -162,7 +165,7 @@ cmake --install . --prefix ${COOKBOOK_STAGE}/usr **Estimated patch size**: ~500-800 lines for qtbase. -#### Step 2: Port `qtwayland` (1-2 weeks) +#### Historical Step 2: Port `qtwayland` (1-2 weeks) ```toml # recipes/wip/qt/qtwayland/recipe.toml @@ -185,7 +188,7 @@ cmake --install . --prefix ${COOKBOOK_STAGE}/usr """ ``` -#### Step 3: Port `qtdeclarative` (QML) (2-3 weeks) +#### Historical Step 3: Port `qtdeclarative` (QML) (2-3 weeks) ```toml # recipes/wip/qt/qtdeclarative/recipe.toml @@ -201,7 +204,7 @@ script = """ """ ``` -#### Step 4: Verify +#### Historical Step 4: Verify ```bash # Build and run a simple Qt Wayland app: @@ -224,7 +227,7 @@ x86_64-unknown-redox-g++ test.cpp -o test-qt -I/usr/include/qt6 -lQt6Widgets -lQ --- -### Phase KDE-B: KDE Frameworks (2-3 months) +### Historical KDE Frameworks porting plan (2-3 months) **Goal**: KDE applications can be built and run. @@ -307,7 +310,7 @@ cmake --install . --prefix ${COOKBOOK_STAGE}/usr **Goal**: Full KDE Plasma desktop session. -#### Step 1: Port KWin (4-6 weeks) +#### Historical Step 1: Port KWin (4-6 weeks) KWin is the hardest component. It needs: - DRM/KMS (for display control) → via our DRM scheme @@ -377,7 +380,7 @@ cmake --install . --prefix ${COOKBOOK_STAGE}/usr **Estimated KWin patches**: ~1000-1500 lines. -#### Step 2: Port `plasma-workspace` (2-3 weeks) +#### Historical Step 2: Port `plasma-workspace` (2-3 weeks) ```toml # recipes/wip/kde/plasma-workspace/recipe.toml @@ -399,11 +402,11 @@ dependencies = [ **Key component**: `plasmashell` — the desktop shell. Creates panels, desktop containment, applet loader. Depends heavily on QML (qtdeclarative). -#### Step 3: Port `plasma-desktop` (1-2 weeks) +#### Historical Step 3: Port `plasma-desktop` (1-2 weeks) System settings, desktop containment configuration. Mostly Qt/QML. -#### Step 4: Create session config +#### Historical Step 4: Create session config ```toml # config/kde.toml (new file) @@ -513,9 +516,9 @@ Once Qt + KDE Frameworks are ported, these apps should compile with minimal patc ## System Integration Points -### D-Bus (Already Working) -D-Bus is ported and working in the X11 config. KDE uses D-Bus extensively. -Already configured in `config/x11.toml`. +### D-Bus (Already Ported) +D-Bus is ported, and current KDE-facing runtime wiring belongs to the Red Bear desktop/KDE profiles. +It should not be framed as an X11-only or X11-primary integration surface. ### Audio: PulseAudio PipeWire Shim Needed KDE expects PulseAudio or PipeWire for audio. Redox has its own `scheme:audio`. diff --git a/local/docs/AMD-FIRST-INTEGRATION.md b/local/docs/AMD-FIRST-INTEGRATION.md index c29459cf..9c7bcb0d 100644 --- a/local/docs/AMD-FIRST-INTEGRATION.md +++ b/local/docs/AMD-FIRST-INTEGRATION.md @@ -1,4 +1,4 @@ -# AMD-FIRST REDOX OS — AMD-SPECIFIC INTEGRATION PLAN +# AMD-SPECIFIC REDOX OS — GPU/DRIVER INTEGRATION REFERENCE > **Status note (2026-04-16):** This document remains the detailed AMD-focused hardware roadmap. > It is no longer the canonical desktop path plan — see @@ -11,6 +11,10 @@ > > Red Bear OS now treats AMD and Intel machines as equal-priority targets. Read this file as the > deeper AMD-specific technical plan, not as a platform-priority statement. +> +> **Planning authority note (2026-04-18):** for current GPU/DRM execution order and acceptance +> criteria, use `local/docs/DRM-MODERNIZATION-EXECUTION-PLAN.md`. This file remains a detailed AMD +> technical/reference document, not the canonical GPU plan. **Target**: AMD64 bare metal machine with AMD GPU (RDNA2/RDNA3), within an overall Red Bear OS hardware policy that treats AMD and Intel machines as equal-priority targets. @@ -36,7 +40,7 @@ take 5+ years. |-----------|--------|--------| | UEFI boot | ✅ Works | x86_64 UEFI bootloader functional | | AMD CPUs | ✅ Works | AMD 32/64-bit supported, Ryzen Threadripper verified | -| ACPI | ✅ Complete | RSDP/SDT checksums, MADT types 0x4/0x5/0x9/0xA, LVT NMI, FADT shutdown/reboot | +| ACPI | ✅ Boot-baseline complete | RSDP/SDT checksums, MADT types 0x4/0x5/0x9/0xA, LVT NMI, FADT shutdown/reboot; see `local/docs/ACPI-IMPROVEMENT-PLAN.md` for remaining ownership, robustness, and validation work | | x2APIC | ✅ Works | Auto-detected via CPUID, APIC/SMP functional | | HPET | ✅ Works | Timer initialized from ACPI | | IOMMU | 🚧 In progress | `iommu` daemon now builds, auto-discovers common IVRS table paths, reaches unit detection plus `scheme:iommu` registration in the QEMU/AMD-IOMMU validation path, and now has a guest-driven first-use self-test that initializes both discovered units and drains events successfully in QEMU; real hardware validation is still missing | @@ -46,10 +50,9 @@ take 5+ years. ### Known AMD-Specific Issues -1. **Framework Laptop 16 (AMD Ryzen 7040)**: CRASHES — unimplemented ACPI function (jackpot51/acpi#3) -2. **ASUS PRIME B350M-E**: Partial PS/2 keyboard, mouse broken -3. **Zen3+ page alignment**: Potential memory corruption with 16k-aligned pages -4. **I2C on AMD platforms**: Touchpad may fail +1. **ASUS PRIME B350M-E**: Partial PS/2 keyboard, mouse broken +2. **Zen3+ page alignment**: Potential memory corruption with 16k-aligned pages +3. **I2C on AMD platforms**: Touchpad may fail --- @@ -57,14 +60,19 @@ take 5+ years. Before any GPU or desktop work, Redox must boot reliably on modern AMD hardware. -### P0-1: Fix ACPI for AMD +### P0-1: Fix ACPI for AMD (historical milestone) -**Problem**: Framework AMD Ryzen 7040 crashes. ACPI is incomplete. +**Historical problem**: Framework AMD Ryzen 7040 crashed because the early ACPI boot baseline was +incomplete. -**What to do**: -- Identify which ACPI function is unimplemented (see jackpot51/acpi#3) -- Implement missing ACPI table parsers (FACP, DSDT, SSDT) -- Test on: Framework 16, ASUS B350M-E, any modern AMD board +**Current status**: This historical P0 boot-baseline gap is materially complete. The remaining ACPI +work is no longer "make AMD machines boot at all"; it is now ownership cleanup, robustness, +consumer integration, and validation depth as tracked in `local/docs/ACPI-IMPROVEMENT-PLAN.md`. + +**What was done**: +- Implement the missing ACPI boot-baseline support needed for modern AMD bring-up +- Validate the repaired path on the bounded AMD bare-metal targets available during the P0 pass +- Preserve the resulting work in the kernel and `acpid` patch carriers **Where**: - Kernel: `recipes/core/kernel/source/src/acpi/` @@ -247,7 +255,7 @@ ONLY the display/modesetting portion first, using linux-kpi headers. | linux-kpi | ✅ | `local/recipes/drivers/linux-kpi/source/` — C compat headers + Rust shims | | firmware-loader | ✅ | `local/recipes/system/firmware-loader/source/` — scheme:firmware daemon | | pcid /config endpoint | ✅ | `local/patches/base/P0-pcid-config-endpoint.patch` — raw PCI config space via scheme:pci | -| MSI-X interrupt support | ✅ | `local/recipes/gpu/redox-drm/source/src/drivers/interrupt.rs` — shared MSI-X/legacy abstraction | +| MSI-X interrupt support | ✅ | `local/recipes/gpu/redox-drm/source/src/drivers/interrupt.rs` — shared MSI-X/MSI/legacy abstraction with quirk-aware fallback | | Intel pcid-spawner config | ✅ | `local/config/pcid.d/intel_gpu.toml` — auto-detect Intel GPUs | ### P2: AMD GPU Display — COMPLETE (compiles, no HW validation) @@ -266,6 +274,13 @@ ONLY the display/modesetting portion first, using linux-kpi headers. | DMA-BUF | ✅ | `local/recipes/gpu/redox-drm/source/src/scheme.rs` (PRIME export/import via opaque tokens) | | Intel driver | ✅ | `local/recipes/gpu/redox-drm/source/src/drivers/intel/mod.rs` + `display.rs` | +For bounded runtime display validation, Red Bear now uses the shared +`local/scripts/test-drm-display-runtime.sh` harness, with `local/scripts/test-amd-gpu.sh` as the +AMD wrapper. + +Human-readable PCI naming for AMD/Intel devices now comes from the shipped `pciids` database rather +than from hand-maintained GPU name tables in local runtime tools. + ### Build Verification All crates compile with `cargo check` (0 errors): @@ -333,17 +348,16 @@ smithay/src/backend/ ### P4-2: libdrm AMD Backend -libdrm now builds with `-Damdgpu=enabled` and `-Dintel=enabled`. The amdgpu and Intel -backends are present in the built sysroot. Runtime hardware validation through real GPU -hardware is still pending. - -**Patches**: `local/patches/libdrm/` +libdrm currently builds with `-Damdgpu=enabled` and `-Dintel=disabled` in the shipped recipe. +That is enough for the current AMD-oriented build-side path, but it is not yet a full Intel libdrm +feature claim. Runtime hardware validation through real GPU hardware is still pending. --- ## PHASE 5: AMD GPU ACCELERATION (16-24 weeks, parallel with P4) -> Note: this AMD-first Phase 5 is a hardware-driver track. In the v2.0 desktop plan +> Note: this historical P5 hardware-driver track remains useful as AMD-specific implementation +> detail. In the v2.0 desktop plan > (`local/docs/CONSOLE-TO-KDE-DESKTOP-PLAN.md`), hardware GPU enablement is also Phase 5, so the > numbering happens to align. The P0–P6 labels in this document refer to the historical > hardware-enablement sequence, not the current desktop-plan phases. @@ -380,7 +394,7 @@ Same as previous plan (docs/05). GPU vendor doesn't affect Qt/KDE path. --- -## REVISED TIMELINE (AMD-FIRST) +## HISTORICAL P0-P6 TIMELINE ``` Week 1-6: P0 — Fix ACPI, boot on AMD bare metal @@ -417,6 +431,7 @@ P0 (ACPI boot) |----------|----------|--------| | This file | `local/docs/AMD-FIRST-INTEGRATION.md` | ✅ Created | | ACPI fix guide | `local/docs/ACPI-FIXES.md` | ✅ Created | +| ACPI improvement plan | `local/docs/ACPI-IMPROVEMENT-PLAN.md` | ✅ Created | | Bare metal testing log | `local/docs/BAREMETAL-LOG.md` | ✅ Created | | Overlay usage guide | `local/AGENTS.md` | ✅ Created | | Desktop path plan | `local/docs/CONSOLE-TO-KDE-DESKTOP-PLAN.md` | ✅ Created | @@ -432,10 +447,10 @@ P0 (ACPI boot) --- -## ANTI-PATTERNS FOR AMD-FIRST +## ANTI-PATTERNS FOR AMD GPU ENABLEMENT - **DO NOT** attempt a clean Rust rewrite of amdgpu — 6M lines, 5+ years -- **DO NOT** skip ACPI fixes — AMD machines WILL NOT BOOT without complete ACPI +- **DO NOT** skip the ACPI boot baseline — AMD machines WILL NOT BOOT without the RSDP/SDT/MADT/FADT bring-up path; see `local/docs/ACPI-IMPROVEMENT-PLAN.md` for the separate post-bring-up ownership and robustness work - **DO NOT** forget firmware blobs — amdgpu CANNOT FUNCTION without PSP/GC/SDMA firmware - **DO NOT** test only in QEMU — AMD GPU behavior differs significantly from VirtIO - **DO NOT** assume Intel patterns work for AMD — AMD uses different register maps, different firmware flow diff --git a/local/docs/P2-AMD-GPU-DISPLAY.md b/local/docs/P2-AMD-GPU-DISPLAY.md index f70f13bf..fe786abc 100644 --- a/local/docs/P2-AMD-GPU-DISPLAY.md +++ b/local/docs/P2-AMD-GPU-DISPLAY.md @@ -1,11 +1,15 @@ -# Phase P2: AMD GPU Display Output +# Historical Phase P2: AMD GPU Display Output -## Status: P2 CODE COMPLETE — Implementation verified, hardware validation pending +## Status: Historical implementation milestone complete — hardware validation pending -All P2 code is implemented, compiles cleanly, and has been correctness-reviewed -through 28 Oracle verification rounds (resource lifecycle, ownership, GTT, page flip). -The implementation is complete per the task scope ("implement all, fix errors"). -Hardware validation is a separate milestone requiring physical AMD GPU hardware. +> **Planning authority note (2026-04-18):** this file is an AMD display implementation/status +> reference. For current GPU/DRM execution order, Intel/AMD parity criteria, and future task +> sequencing, use `local/docs/DRM-MODERNIZATION-EXECUTION-PLAN.md`. + +The original P2 implementation task was completed and compile-validated for its scoped deliverables. +This file is now a historical AMD display implementation/status reference rather than the canonical +GPU planning document. Hardware validation remains a separate milestone requiring physical AMD GPU +hardware. ## Goal Enable AMD GPU display output (modesetting) on Redox OS via a DRM scheme daemon @@ -60,7 +64,7 @@ pcid: local/config/pcid.d/amd_gpu.toml 7. redox-drm initializes AMD DC (Display Core) 8. AMD DC detects connectors, reads EDID 9. scheme:drm/card0 registered -10. Userspace can now use modetest or Orbital for display +10. Userspace can begin bounded display-side probing (for example `modetest`) once runtime validation is available; this is not yet a hardware-backed support claim by itself ## Verification @@ -72,7 +76,7 @@ pcid: local/config/pcid.d/amd_gpu.toml - [x] Page flip: one outstanding per CRTC, vblank-gated retirement - [x] Firmware: Rust cache validates blob availability at startup; C code loads via request_firmware() from scheme:firmware at runtime - [x] GTT page tables: free-list reuse, TLB-safe error rollback -- [x] Oracle-verified: 28 rounds, zero use-after-free, zero double-free, zero resource leaks +- [x] Original implementation pass received repeated review of resource lifecycle, ownership, GTT, and page-flip behavior - [x] All 4 Rust crates build with zero errors, zero warnings - [x] C glue files pass gcc -fsyntax-only - [x] Build symlinks and config files in place @@ -82,6 +86,12 @@ pcid: local/config/pcid.d/amd_gpu.toml - [ ] modetest -M amd -s 0:1920x1080 sets mode and shows test pattern - [ ] Works on real AMD hardware (RDNA2/RDNA3) +Current bounded runtime harness: +- `redbear-drm-display-check` is now the in-guest bounded display checker. +- `local/scripts/test-amd-gpu.sh` now wraps the shared `local/scripts/test-drm-display-runtime.sh` harness. +- The checker now proves connector/mode enumeration directly and can perform a bounded direct modeset proof. +- A successful harness run is still display-only evidence, not render proof. + ## Key Files | File | Purpose | @@ -94,7 +104,7 @@ pcid: local/config/pcid.d/amd_gpu.toml | local/recipes/gpu/redox-drm/source/src/drivers/interrupt.rs | MSI-X/legacy interrupt abstraction | | local/config/pcid.d/intel_gpu.toml | Intel GPU PCI auto-detection | | local/patches/base/P0-pcid-config-endpoint.patch | pcid /config file endpoint | -| local/scripts/build-amd.sh | Build wrapper | +| local/scripts/build-redbear.sh | Canonical build wrapper | | local/scripts/test-amd-gpu.sh | Test script | ## Dependencies (P1) @@ -115,7 +125,7 @@ pcid: local/config/pcid.d/amd_gpu.toml ### MSI-X interrupt support (T2-T4) - Created shared `InterruptHandle` enum in `redox-drm/src/drivers/interrupt.rs` - Tries MSI-X first (find capability → parse → map table → mask_all → enable → request_vector) -- Falls back to legacy IRQ if MSI-X unavailable +- Falls back through MSI and then legacy IRQ, with `NO_MSIX`, `NO_MSI`, and `FORCE_LEGACY_IRQ` quirk gates applied before transport selection - Both AMD and Intel drivers use `InterruptHandle::setup()` ### Dynamic PCI device info (T6) @@ -126,8 +136,8 @@ pcid: local/config/pcid.d/amd_gpu.toml ### linux-kpi quirk consumption (current) - `redox-drm` now also passes the real PCI BDF into the amdgpu C glue so linux-kpi quirk lookups resolve against the actual GPU, not a guessed location - `amdgpu_redox_main.c` now calls `pci_get_quirk_flags()` / `pci_has_quirk()` in the live Redox init path -- `PCI_QUIRK_NEED_FIRMWARE` now gates DMCUB firmware loading as a hard requirement when present, while logs also spell out quirk-driven IRQ expectations (`NO_MSI`, `NO_MSIX`, `FORCE_LEGACY`) +- firmware gating now stays at the Rust-side GPU driver boundary, while the AMD C backend logs quirk-driven IRQ expectations (`NO_MSI`, `NO_MSIX`, `FORCE_LEGACY`) via linux-kpi lookups on the real GPU BDF ### Intel GPU support (T4-T5) -- Intel driver switched to shared `InterruptHandle` (MSI-X + legacy) +- Intel driver switched to shared `InterruptHandle` (MSI-X / MSI / legacy with quirk-aware fallback) - Added `local/config/pcid.d/intel_gpu.toml` for auto-detection (vendor 0x8086, class 0x03)