Normalize KDE and AMD GPU status docs
This commit is contained in:
@@ -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`.
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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)
|
||||
|
||||
Reference in New Issue
Block a user