Refresh status docs and add a visible changelog

Ultraworked with [Sisyphus](https://github.com/code-yeongyu/oh-my-openagent) Co-authored-by: Sisyphus <clio-agent@sisyphuslabs.ai>
2026-04-14 10:50:04 +01:00
parent ba09482def
commit fd60edc823
20 changed files with 3311 additions and 77 deletions
@@ -24,6 +24,8 @@ recipes/**/source.tar.tmp
 # Build artifacts — target/ dirs are everywhere
 target
 wget-log
 /sysroot/
 local/docs/*.log
 # Explicitly track our OWN source code (recipes with path="source" where we wrote the code)
 # Only recipes under these categories contain our hand-written source:
@@ -232,17 +232,16 @@ See `local/docs/AMD-FIRST-INTEGRATION.md` for the full plan.
 | ~~P0: Fix ACPI for AMD~~ | ~~4-6 weeks~~ | ✅ Complete — boots on modern AMD bare metal |
 | ~~P1: Driver infrastructure~~ | ~~8-12 weeks~~ | ✅ Complete — redox-driver-sys + linux-kpi + firmware-loader + pcid /config + MSI-X (compiles) |
 | ~~P2: AMD GPU display~~ | ~~12-16 weeks~~ | ✅ Complete — redox-drm + AMD DC port + Intel driver (compiles, no HW validation) |
-| P3: POSIX + input | 4-8 weeks | relibc gaps + evdevd (parallel with P1/P2) |
+| ~~P3: POSIX + input~~ | ~~4-8 weeks~~ | 🚧 Build-side work substantially complete — relibc gaps exported to downstream consumers, evdevd/udev-shim/libevdev/libinput/D-Bus build; runtime validation still open |
-| P4: Wayland compositor | 4-6 weeks | Smithay Redox backends |
+| P4: Wayland compositor | 4-6 weeks | 🚧 Partial — libwayland/Qt6 Wayland/Mesa EGL+GBM+GLES2/Qt6 OpenGL now build, but compositor/runtime validation is still incomplete |
-| P5: Full amdgpu | 16-24 weeks | Complete GPU driver via LinuxKPI (parallel) |
+| ~~P5: DML2 enablement~~ | ~~partial~~ | 🚧 DML2 config enabled, 63 DML source files in build, TTM compiled, libdrm amdgpu ✅, `iommu` daemon now builds; hardware validation still open |
-| P6: KDE Plasma | 12-16 weeks | Qt6 → KDE Frameworks → KWin → Plasma Shell |
+| P6: KDE Plasma | 12-16 weeks | 🚧 In progress — Qt6 ✅, KF6 32/32 ✅, Mesa EGL/GBM/GLES2 ✅, kf6-kcmutils ✅, kf6-kwayland ✅, kdecoration ✅, KWin 🔄 building |
-**Total to KDE Plasma on AMD**: ~48 weeks (~11 months) with 2 developers (P0 complete).
+**Total to KDE Plasma on AMD**: ~48 weeks (~11 months) with 2 developers (P0-P2 complete; P3/P4 build-side substantially advanced, runtime still open).
 ### Critical Path
 ```
-P0 (ACPI boot) ✅ DONE → P1 (driver infra) ✅ DONE → P2 (AMD display) ✅ DONE → P4 (Wayland) → P6 (KDE)
+P0 (ACPI boot) ✅ → P1 (driver infra) ✅ → P2 (AMD display) ✅ → P3 (POSIX+input, build-side) 🚧 → P4 (Wayland runtime) 🚧 → P6 (KDE)
                                                          P3 (POSIX+input) ──────────────┘
                                                                                    P5 (full amdgpu, parallel)
 ```
@@ -0,0 +1,15 @@
 # Changelog
 This file tracks user-visible changes in Red Bear OS.
 When a commit changes the visible system surface, supported hardware, build flow, shipped configs,
 or major documentation status, add a short note here and keep the README "What's New" section in
 sync with the newest highlights.
 ## 2026-04-14
 - Added a user-visible GitHub-facing "What's New" section to the root README and linked it to this running changelog.
 - Added a new `redbear-kde` configuration and documented current KDE bring-up status as in-progress rather than not started.
 - Refreshed top-level and docs status notes so historical roadmap documents no longer read as the current repo state.
 - Expanded shipped Red Bear system tooling and config coverage around runtime diagnostics, native hardware listing, and Redox-native networking flows.
 - Cleaned up repository noise by ignoring generated `sysroot/` output and local doc log files.
@@ -104,6 +104,13 @@ Since **Rust** is a relatively small and new language compared to others like C
 Please follow our [Git style](https://doc.redox-os.org/book/creating-proper-pull-requests.html) for pull requests.
 For user-visible work, keep the root [`CHANGELOG.md`](CHANGELOG.md) current and refresh the
 README "What's New" section with the latest highlights so GitHub visitors can immediately see what
 changed.
 When a commit changes the visible system surface, supported hardware, build flow, shipped configs,
 or key docs, add a short user-facing changelog note in the same change.
 ## GitLab
 ### Identity
@@ -4,6 +4,25 @@
 **Project**: Red Bear OS Build System (based on Redox OS)
 **Status**: Assessment Complete
 > **Status correction (2026-04-14):** This report is a historical assessment snapshot and is no
 > longer an accurate statement of current repository status. The repo now contains substantial work
 > that this report still describes as missing, including `redox-driver-sys`, `linux-kpi`,
 > `firmware-loader`, `redox-drm`, the AMD display path, the Qt6 stack, `config/redbear-kde.toml`,
 > and a large `local/recipes/kde/` tree.
 ## Current Snapshot
 | Area | Current repo state |
 |---|---|
 | ACPI / bare-metal | Complete in-tree |
 | Driver infrastructure | Present and compiling in `local/recipes/drivers/` |
 | DRM / display | Present and compiling in `local/recipes/gpu/`; hardware validation still pending |
 | POSIX/input | Implemented in-tree with remaining validation work |
 | Wayland | Partial runtime path |
 | KDE | In progress with a mix of true builds and scaffolding |
 Read this file as historical context, not as the canonical current-state document.
 ---
 ## Executive Summary
@@ -18,6 +18,28 @@
 Red Bear OS is a derivative of [Redox OS](https://www.redox-os.org) — a general-purpose, Unix-like, microkernel-based operating system written in Rust. It tracks upstream Redox, incorporating its improvements while adding custom drivers, filesystems, and hardware support.
 ## What's New
 - KDE bring-up moved forward: `config/redbear-kde.toml` exists, the Qt6 stack builds in-tree, and the KDE recipe tree is now populated.
 - Native Red Bear runtime tooling expanded with `redbear-info`, `redbear-hwutils` (`lspci`, `lsusb`), and a Redox-native `netctl` flow.
 - Build and status docs were refreshed to distinguish current in-tree progress from older historical roadmap text.
 See [CHANGELOG.md](./CHANGELOG.md) for the running user-visible change log.
 ## Current Phase Snapshot
 | Phase | Status | Notes |
 |---|---|---|
 | P0 ACPI boot | ✅ Complete | In-tree and documented in `local/docs/ACPI-FIXES.md` |
 | P1 driver infra | ✅ Complete | Compile-oriented infrastructure present |
 | P2 DRM / display | ✅ Code complete | Hardware validation still pending |
 | P3 POSIX + input | 🚧 In progress | relibc exports now cover the rebuilt `signalfd`/`timerfd`/`eventfd`/`open_memstream` consumer path; runtime validation remains |
 | P4 Wayland runtime | 🚧 Partial | `libwayland` and `seatd` now build, and KDE config starts seatd, but compositor/DRM/input runtime validation is still incomplete |
 | P5 AMD accel / IOMMU | 🚧 Partial | `iommu` daemon now builds, but hardware validation and full acceleration are still open |
 | P6 KDE Plasma | 🚧 In progress | Mix of real builds, shims, and stubs |
 There is no distinct first-class **P7** phase artifact in this repository today; later work appears as milestone-style follow-on work beyond the tracked P6 boundary.
 ## What's Different from Upstream Redox
 | Component | Status | Detail |
@@ -26,8 +48,9 @@ Red Bear OS is a derivative of [Redox OS](https://www.redox-os.org) — a genera
 | Intel GPU driver | ✅ Compiles | Display pipe modesetting + MSI-X (no HW validation) |
 | ext4 filesystem | ✅ Compiles | Read/write ext4 alongside RedoxFS |
 | ACPI for AMD bare metal | ✅ Complete | x2APIC, MADT, FADT shutdown/reboot, power methods |
 | Wired networking | 🚧 Improved | native net stack present, Redox-native `netctl` shipped, RTL8125 autoload wired through the existing Realtek path |
 | Custom branding | ✅ | Boot identity, hostname, os-release |
-| POSIX gaps (relibc) | 🚧 In progress | eventfd, signalfd, timerfd, open_memstream |
+| POSIX gaps (relibc) | 🚧 In progress | implementations exist in-tree; runtime validation against Wayland stack is still ongoing |
 ## Project Structure
@@ -58,6 +81,36 @@ make live CONFIG_NAME=redbear-full       # Live ISO (redbear-live.iso)
 make qemu                                # Boot in QEMU
 ```
 ## Native hardware listing tools
 Red Bear configs now include a small native `redbear-hwutils` package that ships `lspci` and
 `lsusb`. `lspci` reads the existing `/scheme/pci/.../config` surface, while `lsusb` walks the
 native `usb.*` schemes exposed by `xhcid`, so there is no dependency on the unfinished WIP
 `pciutils` or `usbutils` ports.
 ## Networking
 Red Bear ships the existing native Redox wired networking path (`pcid-spawner` → NIC daemon →
 `smolnetd`/`dhcpd`/`netcfg`) together with a small Redox-native `netctl` compatibility command.
 Profiles live under `/etc/netctl`, the shipped examples live under `/etc/netctl/examples`, and the
 boot service applies the enabled profile with `netctl --boot`.
 RTL8125 is wired into the existing native Realtek autoload path by matching `10ec:8125` in the
 `rtl8168d` driver config. This keeps the implementation in the Redox userspace driver model rather
 than introducing a separate Linux netdevice compatibility layer.
 ## Runtime diagnostics
 Red Bear ships `redbear-info` as the canonical runtime integration/debugging command. It is a
 passive report over live system surfaces and is intended to help answer questions like:
 - which Red Bear integrations are merely installed versus actually active,
 - whether the networking stack is up, with current IP, DNS, and default route,
 - whether hardware discovery surfaces such as PCI, USB, DRM, and RTL8125 are visible.
 Use `redbear-info --verbose` for evidence-backed human output, `redbear-info --json` for machine-
 readable diagnostics, and `redbear-info --test` for suggested follow-up commands.
 ## Sync with Upstream Redox
 ```bash
@@ -111,7 +111,13 @@ All drivers are **userspace daemons** that access hardware through:
 **Storage**: ided (IDE), ahcid (SATA), nvmed (NVMe), usbscsid (USB SCSI)
-**Network**: e1000d (Intel GigE), rtl8168d (Realtek), ixgbed (Intel 10G)
+**Network**: e1000d (Intel GigE), rtl8168d (Realtek 8168/8169/8125 path), ixgbed (Intel 10G), virtio-netd (VirtIO)
 The native wired stack in this tree is userspace end to end: `pcid-spawner` autoloads NIC daemons,
 drivers expose `network.*` schemes through `driver-network`, `smolnetd` provides the `ip`/`tcp`/
 `udp`/`icmp`/`netcfg` schemes, and `dhcpd` plus config files under `/etc/net/` supply runtime
 addressing. Red Bear additionally ships a small native `netctl` compatibility command for profile-
 driven wired setup.
 **Audio**: ac97d, ihdad (Intel HD Audio), sb16d (Sound Blaster)
@@ -179,17 +185,19 @@ Architectures: i586, x86_64, aarch64, riscv64gc.
 ### Known POSIX Gaps (blocking Wayland)
-These are the specific missing features found in libwayland's `redox.patch`:
+These were the specific missing features originally identified from libwayland's `redox.patch`.
 Today, most exist in-tree in relibc, but downstream Wayland consumers still carry compatibility
 patches, so this table is a current-state summary rather than an untouched historical claim.
 | Missing API | Used By | Status |
 |-------------|---------|--------|
-| `signalfd` / `SFD_CLOEXEC` | libwayland event loop | Not implemented |
+| `signalfd` / `SFD_CLOEXEC` | libwayland event loop | Implemented in-tree; downstream libwayland still patched around usage |
-| `timerfd` / `TFD_CLOEXEC` / `TFD_TIMER_ABSTIME` | libwayland timers | Not implemented |
+| `timerfd` / `TFD_CLOEXEC` / `TFD_TIMER_ABSTIME` | libwayland timers | Implemented in-tree; downstream libwayland still patched around usage |
-| `eventfd` / `EFD_CLOEXEC` | libwayland server | Not implemented |
+| `eventfd` / `EFD_CLOEXEC` | libwayland server | Implemented in-tree; downstream libwayland still patched around usage |
-| `F_DUPFD_CLOEXEC` | libwayland fd management | Not implemented |
+| `F_DUPFD_CLOEXEC` | libwayland fd management | Implemented in-tree |
-| `MSG_CMSG_CLOEXEC` | libwayland socket recv | Not implemented |
+| `MSG_CMSG_CLOEXEC` | libwayland socket recv | Implemented in-tree |
-| `MSG_NOSIGNAL` | libwayland connection | Not implemented |
+| `MSG_NOSIGNAL` | libwayland connection | Implemented in-tree; downstream libwayland still omits flag |
-| `open_memstream` | libdrm, libwayland | Not implemented |
+| `open_memstream` | libdrm, libwayland | Implemented in-tree; downstream libwayland still bypasses usage |
 ## 6. Build System (This Repository)
@@ -257,8 +265,8 @@ Config: `config/wayland.toml`
 ### Key Blockers for Wayland
-1. **relibc POSIX gaps** (signalfd, timerfd, eventfd, open_memstream)
+1. **Downstream Wayland compatibility patches remain** (`libwayland/redox.patch` still bypasses some interfaces even though relibc-side APIs now exist in-tree)
 2. **No GPU acceleration** (only software rendering)
-3. **No libinput** (requires evdev + udev)
+3. **Input/runtime integration remains incomplete** (`evdevd`, `udev-shim`, and libinput exist, but compositor input is not fully validated)
-4. **No DRM/KMS** (libdrm has all GPU drivers disabled)
+4. **DRM/KMS runtime validation remains incomplete** (`redox-drm` exists in-tree, but full Wayland/driver runtime integration is still open)
-5. **cosmic-comp**: missing keyboard input, performance issues
+5. **cosmic-comp**: keyboard/input integration and performance issues remain
@@ -7,6 +7,34 @@ This document maps the distance between current Redox OS 0.9.0 and three goals:
 2. **KDE Plasma desktop** → see [05-KDE-PLASMA-ON-REDOX.md](05-KDE-PLASMA-ON-REDOX.md)
 3. **Linux driver compatibility layer** → see [04-LINUX-DRIVER-COMPAT.md](04-LINUX-DRIVER-COMPAT.md)
 ## Status Correction (2026-04-14)
 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.
 | 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` |
 | P1 driver infrastructure | Complete in-tree, compile-oriented | `local/recipes/drivers/redox-driver-sys/`, `local/recipes/drivers/linux-kpi/`, `local/recipes/system/firmware-loader/` |
 | P2 DRM / AMD+Intel display | Complete in-tree, hardware validation pending | `local/docs/P2-AMD-GPU-DISPLAY.md`, `local/recipes/gpu/redox-drm/`, `local/recipes/gpu/amdgpu/` |
 | P3 POSIX + input | Implemented in-tree; consumer-visible `signalfd`/`timerfd`/`eventfd`/`open_memstream` header-export path fixed in this repo pass; runtime validation still pending | `recipes/core/relibc/source/src/header/`, `recipes/core/relibc/source/include/sys/signalfd.h`, `local/patches/relibc/`, `local/recipes/system/evdevd/`, `local/recipes/system/udev-shim/` |
 | P4 Wayland stack | Partially complete | `recipes/wip/wayland/`, `recipes/wip/libs/other/libinput/`, `recipes/wip/services/seatd/` |
 | P5 AMD acceleration / IOMMU | Partial | `local/recipes/gpu/amdgpu/`, `local/recipes/system/iommu/` (now buildable via surfaced recipe) |
 | P6 KDE Plasma | In progress with mixed real builds and stubs/shims | `config/redbear-kde.toml`, `local/recipes/kde/`, `local/docs/QT6-PORT-STATUS.md` |
 ### Ordered Remaining Gaps
 1. **Validate the completed P3→P4 bridge in practice**: `libwayland` now rebuilds with `signalfd`, `timerfd`, `eventfd`, `open_memstream`, `MSG_CMSG_CLOEXEC`, and `MSG_NOSIGNAL` restored, but compositor/runtime validation is still outstanding.
 2. **Complete P4 runtime path**: libinput/seatd/GBM/Wayland compositor integration is still incomplete even though the base libraries now build, `seatd` now builds for Redox, and the KDE runtime config now starts a seatd service.
 3. **Separate KDE real builds from scaffolding**: parts of the KDE stack are genuine builds, while others are shimmed or stubbed only to satisfy dependency resolution.
 4. **Hardware validation remains open** for AMD/Intel DRM and the IOMMU path, even though the IOMMU daemon now builds.
 ### P7 Note
 The repository's tracked phase model currently stops at **P6**. What a user might call "P7"
 only appears here as later milestone-style work (for example M7/M8 below), not as a first-class
 implemented phase with its own config/recipe/doc boundary.
 ## Dependency Chain: Hardware → KDE Desktop
 ```
@@ -34,28 +62,28 @@ This document maps the distance between current Redox OS 0.9.0 and three goals:
 | API | Status | Where to implement | Effort |
 |-----|--------|--------------------|--------|
-| `signalfd`/`signalfd4` | **Missing** | `relibc/src/header/signal/mod.rs` + `signal/types.rs` | Medium |
+| `signalfd`/`signalfd4` | **Implemented in-tree** | `relibc/src/header/signal/mod.rs` + `signal/signalfd.rs` | Runtime validation still needed |
-| `timerfd_create/settime/gettime` | **Missing** | `relibc/src/header/sys_timerfd/` (NEW directory) | Medium |
+| `timerfd_create/settime/gettime` | **Implemented in-tree** | `relibc/src/header/sys_timerfd/` | Runtime validation still needed |
-| `eventfd`/`eventfd_read`/`eventfd_write` | **Missing** | `relibc/src/header/sys_eventfd/` (NEW directory) | Low |
+| `eventfd`/`eventfd_read`/`eventfd_write` | **Implemented in-tree** | `relibc/src/header/sys_eventfd/` | Runtime validation still needed |
-| `F_DUPFD_CLOEXEC` | **Missing** | `relibc/src/header/fcntl/mod.rs` (add constant) | Low |
+| `F_DUPFD_CLOEXEC` | **Implemented in-tree** | `relibc/src/header/fcntl/mod.rs` | Verify against downstream consumers |
-| `MSG_CMSG_CLOEXEC` | **Missing** | `relibc/src/header/sys_socket/mod.rs` | Low |
+| `MSG_CMSG_CLOEXEC` | **Implemented in-tree** | `relibc/src/header/sys_socket/mod.rs` | Verify against downstream consumers |
-| `MSG_NOSIGNAL` | **Missing** | `relibc/src/header/sys_socket/mod.rs` | Low |
+| `MSG_NOSIGNAL` | **Implemented in-tree** | `relibc/src/header/sys_socket/mod.rs` | Verify against downstream consumers |
-| `open_memstream` | **Missing** | `relibc/src/header/stdio/src.rs` | Low |
+| `open_memstream` | **Implemented in-tree** | `relibc/src/header/stdio/open_memstream.rs` | Verify against downstream consumers |
 | UDS + FD passing | **Done** | Already implemented | — |
 | `epoll` (event scheme) | **Done** | Redox `scheme:event` | — |
 | `mmap`/`mprotect` | **Done** | Kernel syscalls | — |
 | `fork`/`exec` | **Done** | Userspace via `thisproc:` scheme | — |
-**Proof of gap**: See `recipes/wip/wayland/libwayland/redox.patch` — all 7 missing APIs are stubbed there.
+**Current blocker**: The build-side relibc/libwayland bridge is now in place, but downstream Wayland still needs runtime validation and the wider compositor stack (`evdevd`/`seatd`/DRM/GBM) is still incomplete.
 ### Layer 2: GPU / Display Infrastructure
 | Component | Status | Where to implement | Concrete doc |
 |-----------|--------|--------------------|-------------|
-| DRM/KMS scheme | **Missing** | New daemon: `redox-drm` crate | [04 §3](04-LINUX-DRIVER-COMPAT.md) |
+| 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 | **Missing** | `redox-drm/src/gem.rs` | [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 | **Missing** | `redox-drm/src/dmabuf.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) |
 | 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) |
@@ -63,17 +91,17 @@ This document maps the distance between current Redox OS 0.9.0 and three goals:
 | Component | Status | Where to implement | Concrete doc |
 |-----------|--------|--------------------|-------------|
-| evdev daemon | **Missing** | New: `recipes/core/evdevd/` | [03 §2](03-WAYLAND-ON-REDOX.md) |
+| evdev daemon | **Present in-tree** | `local/recipes/system/evdevd/` | [03 §2](03-WAYLAND-ON-REDOX.md) |
-| udev shim | **Missing** | New: `recipes/wip/wayland/udev-shim/` | [03 §2](03-WAYLAND-ON-REDOX.md) |
+| udev shim | **Present in-tree** | `local/recipes/system/udev-shim/` | [03 §2](03-WAYLAND-ON-REDOX.md) |
-| libinput | **Missing** | `recipes/wip/wayland/libinput/` (NEW) | [03 §2](03-WAYLAND-ON-REDOX.md) |
+| libinput | **Present as WIP port** | `recipes/wip/libs/other/libinput/` | [03 §2](03-WAYLAND-ON-REDOX.md) |
 | XKB layouts | **Done** | `xkeyboard-config` ported | — |
-| seatd | Recipe exists, untested | `recipes/wip/wayland/seatd/` | — |
+| seatd | Builds and is wired into KDE config, runtime unvalidated | `recipes/wip/services/seatd/`, `config/redbear-kde.toml` | — |
 ### Layer 4: Wayland Protocol
 | Component | Status | Recipe | Blocker |
 |-----------|--------|--------|---------|
-| libwayland | Patched, broken timers | `recipes/wip/wayland/libwayland/` | Layer 1 POSIX gaps |
+| libwayland | Patched, downstream compatibility workarounds remain | `recipes/wip/wayland/libwayland/` | Reduce/remove `redox.patch` and verify runtime behavior |
 | cosmic-comp | No keyboard input | `recipes/wip/wayland/cosmic-comp/` | Layer 3 libinput |
 | smallvil (Smithay) | Basic, slow | `recipes/wip/wayland/smallvil/` | Layer 2+3 for DRM+input |
 | wlroots/sway/hyprland | Not tested | `recipes/wip/wayland/wlroots/` | Layer 2+3 |
@@ -82,28 +110,28 @@ This document maps the distance between current Redox OS 0.9.0 and three goals:
 | Component | Status | Concrete doc |
 |-----------|--------|-------------|
-| Qt 6 | Not ported | [05 Phase KDE-A](05-KDE-PLASMA-ON-REDOX.md) |
+| Qt 6 | Ported in-tree | [05 Phase KDE-A](05-KDE-PLASMA-ON-REDOX.md) |
-| KDE Frameworks | Not ported | [05 Phase KDE-B](05-KDE-PLASMA-ON-REDOX.md) |
+| KDE Frameworks | Partially ported in-tree | [05 Phase KDE-B](05-KDE-PLASMA-ON-REDOX.md) |
-| KWin | Not ported | [05 Phase KDE-C](05-KDE-PLASMA-ON-REDOX.md) |
+| KWin | Recipe exists, still incomplete | [05 Phase KDE-C](05-KDE-PLASMA-ON-REDOX.md) |
-| Plasma Shell | Not ported | [05 Phase KDE-C](05-KDE-PLASMA-ON-REDOX.md) |
+| Plasma Shell | Recipe exists, still incomplete | [05 Phase KDE-C](05-KDE-PLASMA-ON-REDOX.md) |
 | D-Bus | **Ported** | `config/x11.toml` has it working |
 ### Layer 6: Linux Driver Compatibility
 | Component | Status | Concrete doc |
 |-----------|--------|-------------|
-| `redox-driver-sys` crate | Not started | [04 §3](04-LINUX-DRIVER-COMPAT.md) |
+| `redox-driver-sys` crate | Present in-tree | [04 §3](04-LINUX-DRIVER-COMPAT.md) |
-| `linux-kpi` C headers | Not started | [04 §3](04-LINUX-DRIVER-COMPAT.md) |
+| `linux-kpi` C headers | Present in-tree | [04 §3](04-LINUX-DRIVER-COMPAT.md) |
-| i915 C driver port | Not started | [04 §4](04-LINUX-DRIVER-COMPAT.md) |
+| i915 C driver port | Not started as Linux C port | [04 §4](04-LINUX-DRIVER-COMPAT.md) |
-| amdgpu C driver port | Not started | [04 §5](04-LINUX-DRIVER-COMPAT.md) |
+| amdgpu C driver port | Present in-tree, hardware validation pending | [04 §5](04-LINUX-DRIVER-COMPAT.md) |
 ---
 ## Concrete Roadmap with Milestones
 ### Milestone M1: "libwayland works natively" (2-4 weeks)
- Implement 7 POSIX APIs in relibc (see Layer 1 table)
+- Build-side part now substantially complete: relibc exports the needed consumer-visible POSIX headers/symbols and `libwayland` rebuilds with only residual Redox-specific build tweaks
- Remove `redox.patch` from libwayland recipe
+- Remaining work: runtime validation (`wayland-rs_simple_window`, compositor bring-up)
 - **Test**: `wayland-rs_simple_window` runs without crashes
 - **Delivers**: libwayland, wayland-protocols, libdrm all build natively
@@ -8,11 +8,31 @@ Get a working Wayland compositor on Redox OS that can run KDE Plasma application
 - `config/wayland.toml` exists — launches `cosmic-comp` or `smallvil` via `orbital-wayland`
 - 21 Wayland recipes in `recipes/wip/wayland/` — most untested
- `libwayland` 1.24.0 builds with `redox.patch` that stubs out 7 POSIX APIs
+- `libwayland` 1.24.0 now rebuilds with a much smaller `redox.patch`; the P3 POSIX path (`signalfd`, `timerfd`, `eventfd`, `open_memstream`, `MSG_CMSG_CLOEXEC`, `MSG_NOSIGNAL`) is back on the native path, and the remaining patch is down to Redox-specific build quirks
 - `smallvil` (Smithay) runs as basic compositor, performance poor
- `cosmic-comp` builds but has no keyboard input (missing libinput)
+- `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)
 - **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
 - **redox-drm** (`scheme:drm`) provides DRM/KMS with AMD + Intel GPU support
 ---
 ## Status Correction (2026-04-14)
 This document is partly historical. The repo already contains substantial P3/P4 work in-tree,
 but the downstream Wayland stack is still not free of compatibility patches.
 What is actually true today:
 - relibc now contains in-tree implementations for `signalfd`, `timerfd`, `eventfd`, `open_memstream`, `MSG_CMSG_CLOEXEC`, and `MSG_NOSIGNAL` support paths
 - the relibc module wiring plus the consumer-visible `signalfd` / `timerfd` / `eventfd` / `open_memstream` export path were fixed in this repo pass
 - `libwayland/redox.patch` has been reduced to residual Redox-specific build tweaks (`wayland-scanner` detection and `F_DUPFD_CLOEXEC` guard), so the old POSIX bypasses are no longer the main blocker
 - `evdevd`, `udev-shim`, and `redox-drm` exist in-tree, but full compositor/runtime validation remains open
 - `seatd` now also builds in-tree for Redox and is started by the KDE runtime config, but has not yet been validated end-to-end with the compositor/DRM path
 Read the step-by-step sections below as design history plus implementation notes, not as an exact current-state checklist.
 ---
@@ -20,8 +40,10 @@ Get a working Wayland compositor on Redox OS that can run KDE Plasma application
 ### What to implement
-These are the 7 APIs that libwayland's `redox.patch` removes. Each must be added
+Historically these were the 7 APIs that `libwayland/redox.patch` worked around. They now exist
-to `relibc` (repo: https://gitlab.redox-os.org/redox-os/relibc).
+in-tree in relibc, and this repo pass restored the full build-side path for `signalfd`, `timerfd`,
 `eventfd`, `open_memstream`, and the related message flags. The remaining work is no longer basic
 POSIX availability, but runtime validation of the full Wayland stack.
 #### 1.1 `signalfd` / `signalfd4`
@@ -1,5 +1,23 @@
 # 04 — Linux Driver Compatibility Layer: Concrete Implementation Path
 > **Status note (2026-04-14):** This file is now partly historical design material. The repository
 > already contains `local/recipes/drivers/redox-driver-sys/`, `local/recipes/drivers/linux-kpi/`,
 > `local/recipes/system/firmware-loader/`, `local/recipes/gpu/redox-drm/`, and
 > `local/recipes/gpu/amdgpu/`. Treat the sections below as architecture rationale and porting notes,
 > not as an accurate statement that those components are still "not started".
 ## Current State Snapshot
 | Component | Current repo state |
 |---|---|
 | `redox-driver-sys` | Present and compiling in `local/recipes/drivers/redox-driver-sys/` |
 | `linux-kpi` | Present and compiling in `local/recipes/drivers/linux-kpi/` |
 | `firmware-loader` | Present and compiling in `local/recipes/system/firmware-loader/` |
 | `redox-drm` | Present and compiling in `local/recipes/gpu/redox-drm/` |
 | Intel path | Compile-oriented, no hardware validation yet |
 | AMD path | Compile-oriented via `amdgpu` + AMD DC port, no hardware validation yet |
 | IOMMU | Partial — daemon now builds, hardware validation still TODO in `local/recipes/system/iommu/` |
 ## Goal
 Enable running Linux GPU drivers (amdgpu, i915, nouveau) on Redox OS with minimal
@@ -1,5 +1,30 @@
 # 05 — KDE Plasma on Redox: Concrete Implementation Path
 > **Status note (2026-04-14):** This file mixes current status with older forward-looking porting
 > instructions. `config/redbear-kde.toml` already exists, the Qt6 stack is built, many KF6 recipes
 > exist under `local/recipes/kde/`, and the current gap is no longer "start KDE from scratch".
 > The real frontier is distinguishing true builds from shimmed/stubbed packages and then closing
 > the KWin / Plasma runtime path.
 ## Current State Snapshot
 | Area | Current repo state |
 |---|---|
 | Qt6 | Built in-tree (`qtbase`, `qtdeclarative`, `qtsvg`, `qtwayland`) |
 | KF6 | Mixed: many real builds, some still partial |
 | `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 |
 | `kf6-kio` | Heavy shim-based build recipe |
 | `kf6-kcmutils` | Stripped widget-only build recipe |
 | `libxcvt` | Now builds as a real package; no longer needs to stay in the KWin stub bucket |
 ### What remains true from this document
 - KWin / Plasma assembly is still the main functional blocker.
 - Mesa/GBM/libinput/seatd integration still matters for a real session.
 - QML/QtQuick-heavy components remain riskier than the already-built widget/core stack.
 ## Goal
 Run KDE Plasma 6 desktop environment on Redox OS, starting with a minimal viable
@@ -8,15 +33,45 @@ desktop and expanding to full Plasma.
 ## Prerequisites (from docs 03 and 04)
 Before KDE work begins, these MUST be complete:
- [x] relibc POSIX gaps fixed (signalfd, timerfd, eventfd, etc.)
+- [~] relibc POSIX APIs now reach `libwayland` on the native build path, but runtime validation of the full Wayland base still blocks calling the prerequisite fully complete in practice
- [x] evdevd + libinput working
+- [x] evdevd compiled, libevdev built, libinput 1.30.2 built (comprehensive redox.patch)
- [x] DRM/KMS scheme working (at least Intel modesetting)
+- [x] DRM/KMS scheme daemon compiled (redox-drm: 15+ ioctls, AMD+Intel drivers)
- [x] Wayland compositor running (Smithay/smallvil)
+- [x] Wayland: libwayland + wayland-protocols built
- [x] Mesa EGL + software OpenGL (already ported)
+- [x] Mesa: OSMesa + LLVMpipe software rendering (EGL platform_redox.c exists, Orbital-only)
 - [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)
 ## Three-Phase KDE Implementation
-### Phase KDE-A: Qt Foundation (2-3 months)
+### Phase KDE-A: Qt Foundation — ✅ COMPLETE
 Qt6 core stack fully built for x86_64-unknown-redox:
 | Module | Version | Status | Libraries |
 |--------|---------|--------|-----------|
 | qtbase | 6.11.0 | ✅ | Core, Gui, Widgets, Concurrent, Xml, DBus, WaylandClient |
 | qtdeclarative | 6.11.0 | ✅ | QML, QtQuick (JIT disabled) |
 | qtsvg | 6.11.0 | ✅ | Svg, SvgWidgets |
 | qtwayland | 6.11.0 | ✅ | WaylandClient (compositor disabled) |
 ### Phase KDE-B: KF6 Frameworks — 🔄 IN PROGRESS (21/30+ built)
 Built: ecm, kcoreaddons, kwidgetsaddons, kconfig, ki18n, kcodecs, kguiaddons,
 kcolorscheme, kauth, kwindowsystem, knotifications, kjobwidgets, kconfigwidgets,
 karchive, sonnet, kcompletion, kitemviews, kitemmodels, solid
 Building: kdbusaddons, kcrash
 Recipes ready: kiconthemes, kservice, kpackage, kglobalaccel, kxmlgui, ktextwidgets,
 kio, kbookmarks, kdeclarative, kcmutils, kirigami, plasma-framework
 ### 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
 **Goal**: A Qt application displays a window on the Redox Wayland compositor.
@@ -1,7 +1,8 @@
 # DOCS — ARCHITECTURE & INTEGRATION DOCUMENTATION
-7 comprehensive technical documents covering Redox architecture, gap analysis, and integration paths.
+7 technical documents covering Redox architecture, gap analysis, and integration paths.
-For AMD-first integration, see `local/docs/AMD-FIRST-INTEGRATION.md`.
+Some are now historical roadmap documents; check each file's top-level status note before treating it as current state.
 For current Red Bear OS status, also read `local/docs/AMD-FIRST-INTEGRATION.md` and `local/docs/QT6-PORT-STATUS.md`.
 ## STRUCTURE
@@ -22,8 +23,8 @@ docs/
 |----------|----------|-------------|
 | How does the kernel work? | 01 | §1 Microkernel, §2 Scheme System |
 | How do drivers access hardware? | 01 | §3 Driver Model, §6 Build System |
-| What's missing for Wayland? | 02 | Layer 1-4 gap matrix |
+| What's missing for Wayland? | 02 | Status correction + ordered remaining gaps |
-| How to fix POSIX gaps? | 03 | §1 (signalfd, timerfd, eventfd implementations) |
+| How to fix POSIX gaps? | 03 | Status correction + historical §1 notes |
 | How to build evdevd? | 03 | §2 (evdev input daemon architecture) |
 | How to build DRM/KMS? | 03 | §3 (drmd daemon, Intel driver) |
 | How to port a Wayland compositor? | 03 | §4 (Smithay Redox backends) |
@@ -38,7 +39,7 @@ docs/
 ## KEY NUMBERS
- **POSIX gaps**: 7 APIs blocking libwayland (signalfd, timerfd, eventfd, F_DUPFD_CLOEXEC, MSG_CMSG_CLOEXEC, MSG_NOSIGNAL, open_memstream)
+- **POSIX gap story**: APIs now largely exist in-tree, but downstream Wayland consumers still carry compatibility patches
 - **Wayland recipes**: 21 in `recipes/wip/wayland/`
 - **KDE apps**: 9 WIP recipes in `recipes/wip/kde/`
 - **To Wayland compositor**: ~26 weeks (2 developers)
@@ -3,6 +3,11 @@
 Technical documentation for forking Redox OS to include Wayland protocol support,
 KDE Plasma desktop environment, and a Linux driver compatibility layer.
 > **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
 > Red Bear OS work under `local/`; use each document's top-level status notes together with
 > `local/docs/AMD-FIRST-INTEGRATION.md` and `local/docs/QT6-PORT-STATUS.md` for current state.
 ## Documents
 | # | Document | Description |
@@ -14,16 +19,19 @@ KDE Plasma desktop environment, and a Linux driver compatibility layer.
 | 05 | [KDE Plasma on Redox](05-KDE-PLASMA-ON-REDOX.md) | Feasibility study and implementation plan for KDE Plasma |
 | 06 | [Build System Setup](06-BUILD-SYSTEM-SETUP.md) | How to build Redox from this repository |
-## Current State Summary (as of Redox 0.9.0)
+## Current State Summary (as of 2026-04-14)
 - **Display server**: Orbital (custom, scheme-based) — works
- **Wayland**: Experimental, WIP. Smallvil (Smithay) and cosmic-comp partially working.
+- **Wayland**: libwayland + wayland-protocols built. Smallvil/cosmic-comp remain partial runtime experiments.
-  libwayland patched with shimmed-out `signalfd`, `timerfd`, `eventfd`.
+- **Qt6**: qtbase 6.11.0 (Core+Gui+Widgets+DBus+Wayland), qtdeclarative, qtsvg, qtwayland ALL BUILT
- **X11**: Working via X.org dummy driver inside Orbital.
+- **D-Bus**: 1.16.2 built for Redox. Qt6DBus enabled.
- **Mesa**: Software-rendered only (LLVMpipe/OSMesa). No GPU acceleration.
+- **KF6 Frameworks**: mixed state — many real builds, but some packages are still shimmed or stubbed.
- **GPU drivers**: VESA framebuffer + VirtIO GPU only. Experimental Intel modesetting.
+- **Mesa**: software-rendered path is present; full GBM / hardware-validated Wayland path is still incomplete.
- **KDE**: 19 app recipes in WIP, no KDE Plasma infrastructure.
+- **GPU drivers**: redox-drm scheme daemon and AMD+Intel compile-oriented paths exist; hardware validation is still pending.
- **Linux driver compat**: None. Redox explicitly chose source-level porting over binary compat.
+- **Input**: evdevd compiled, libevdev built, libinput 1.30.2 built
 - **Networking**: native wired stack present (`pcid-spawner` → NIC daemon → `smolnetd`/`dhcpd`/`netcfg`), Red Bear ships a native `netctl` command, and RTL8125 is wired into the existing Realtek autoload path
 - **KDE**: `redbear-kde.toml` exists and the recipe tree is populated, but the runtime stack is still incomplete.
 - **Linux driver compat**: linux-kpi (31 C headers + 13 Rust FFI), redox-driver-sys, firmware-loader all compile.
 ## Quick Start
@@ -72,7 +72,7 @@ redox-master/                  ← git pull updates mainline Redox
 │   │   ├── branding/          ← redbear-release (os-release, hostname, motd)
 │   │   ├── drivers/           ← redox-driver-sys, linux-kpi
 │   │   ├── gpu/               ← redox-drm (AMD + Intel display drivers), amdgpu (C port)
-│   │   ├── system/            ← evdevd, udev-shim, firmware-loader, redbear-meta
+│   │   ├── system/            ← cub, evdevd, udev-shim, firmware-loader, redbear-hwutils, redbear-info, redbear-netctl, redbear-meta
 │   │   ├── wayland/           ← Wayland compositor (Phase 4)
 │   │   └── kde/               ← KDE Plasma (Phase 6)
 │   ├── patches/
@@ -249,15 +249,22 @@ redbear-live.toml
        │           └── minimal.toml
        │                 └── base.toml
        └── [packages] redbear-release, redox-driver-sys, linux-kpi,
-                       firmware-loader, redox-drm, evdevd, udev-shim,
+                       firmware-loader, redox-drm, cub, redbear-hwutils,
-                       redbear-meta
+                       redbear-netctl, evdevd, udev-shim, redbear-meta
        NOTE: ext4d is inherited from desktop.toml (mainline package)
        NOTE: cub is included via redbear-desktop.toml and depends on the custom
              recipe symlink (recipes/system/cub → local/recipes/system/cub) being
              created by integrate-redbear.sh or apply-patches.sh before building.
        NOTE: redbear-netctl provides a Redox-native `netctl` command with profiles
              in /etc/netctl and a boot-time `netctl --boot` service.
        NOTE: redbear-info is the canonical runtime integration report. Keep it updated when
              Red Bear adds new tools, schemes, services, or hardware integration paths.
 redbear-minimal.toml
  └── minimal.toml (mainline)
        └── base.toml
-  └── [packages] redbear-release, redox-driver-sys, firmware-loader,
+  └── [packages] redbear-release, redbear-hwutils, redbear-netctl,
-                 evdevd, udev-shim
+                 redox-driver-sys, firmware-loader, evdevd, udev-shim
 ```
 Config comparison:
@@ -26,7 +26,7 @@ the LinuxKPI compatibility approach — a clean Rust rewrite would take 5+ years
 | ACPI | ✅ Complete | RSDP/SDT checksums, MADT types 0x4/0x5/0x9/0xA, LVT NMI, FADT shutdown/reboot |
 | x2APIC | ✅ Works | Auto-detected via CPUID, APIC/SMP functional |
 | HPET | ✅ Works | Timer initialized from ACPI |
-| IOMMU | ❌ Missing | No VT-d or AMD-Vi support |
+| IOMMU | 🚧 Buildable, unvalidated | `iommu` daemon now builds, but no VT-d/AMD-Vi hardware validation yet |
 | AMD GPU | 🚧 In progress | MMIO mapped, DC port compiles, MSI-X wired, no hardware validation yet |
 | Wi-Fi/BT | ❌ Missing | No wireless support |
 | USB | ⚠️ Variable | Some USB controllers work, others don't |
@@ -0,0 +1,543 @@
 # INPUTD SCHEME API ENHANCEMENT DESIGN
 **Target**: `recipes/core/base/source/drivers/inputd`
 **Scope**: Userspace-only `inputd` scheme enhancement
 **Date**: 2026-04-13
 ## 1. Goal
 Enhance `inputd` so it can do all of the following without breaking any existing callers:
 1. Let producers register under stable names such as `ps2-keyboard`, `ps2-mouse`, or `usb-hid0`.
 2. Expose per-device consumer streams so services such as `evdevd` can subscribe to one device only.
 3. Publish hotplug notifications for device add/remove.
 4. Expose currently registered devices through the scheme root directory.
 This is an **additive** design. Existing paths, existing event payloads, existing VT behavior, and existing display/control behavior must continue to work unchanged.
 ## 2. Current Implementation Summary
 The current `inputd` implementation in `recipes/core/base/source/drivers/inputd/src/main.rs` has these important properties:
 - `Handle` only supports `Producer`, `Consumer`, `Display`, `Control`, and `SchemeRoot`.
 - `openat()` only recognizes `producer`, `consumer`, `consumer_bootlog`, `handle`, `handle_early`, and `control`.
 - All producers write anonymous `orbclient::Event` bytes into the same `Handle::Producer` path.
 - Legacy consumers are per-VT handles. `write()` only delivers input bytes to the **active VT** consumer set.
 - `SchemeRoot` exists, but it is not a real directory yet: it does not enumerate entries.
 - `lib.rs` only exposes `ProducerHandle`, `ConsumerHandle`, `DisplayHandle`, and `ControlHandle`.
 Current callers confirm the limitation:
 - `ps2d` opens one `ProducerHandle` and sends both keyboard and mouse events into the same stream.
 - `usbhidd` also opens one `ProducerHandle` and sends keyboard/mouse/button/scroll data into the same stream.
 - local `evdevd` reads `/scheme/input/consumer`, receives anonymous mixed `orbclient::Event` values, and manually translates them.
 ## 3. Design Principles
 1. **Keep legacy behavior intact**: `/scheme/input/producer` and `/scheme/input/consumer` must keep working exactly as they do today.
 2. **Do not change event payloads**: device-specific streams still carry serialized `orbclient::Event` values.
 3. **Keep all logic in userspace**: no kernel changes, no new kernel scheme semantics.
 4. **Make enumeration path-driven**: device names are visible as entries below `/scheme/input/`.
 5. **Use explicit hotplug events**: device discovery and liveness must not depend on polling failed opens.
 ## 4. Scheme Path Layout
 The enhanced namespace is:
 ```text
 /scheme/input/                    — SchemeRoot (directory listing)
 /scheme/input/producer            — Legacy producer (unchanged)
 /scheme/input/producer/{name}     — Named producer: ps2-keyboard, ps2-mouse, usb-hid0
 /scheme/input/consumer            — Legacy consumer (unchanged)
 /scheme/input/{device_name}       — Per-device consumer: reads events from one named producer
 /scheme/input/events              — Hotplug event stream
 /scheme/input/handle/{display}    — Display handle (unchanged)
 /scheme/input/control             — Control commands (unchanged)
 ```
 Legacy-only paths that must remain valid even though they are not part of the new API surface:
 ```text
 /scheme/input/consumer_bootlog    — Existing bootlog VT consumer
 /scheme/input/handle_early/{display} — Existing early framebuffer handoff path
 ```
 ### 4.1 Root Directory Listing
 `SchemeRoot` should become a real directory endpoint backed by `getdents`, not by overloading `read()`.
 The root listing should expose:
 - static entries: `producer`, `consumer`, `consumer_bootlog`, `events`, `handle`, `handle_early`, `control`
 - one dynamic entry per registered device name from `devices`
 That keeps the namespace honest while still allowing device enumeration from `/scheme/input/`.
 `InputDeviceLister` in `lib.rs` should filter out the reserved static names and return only dynamic device entries.
 ## 5. Handle Model
 The `Handle` enum in `main.rs` should become:
 ```rust
 enum Handle {
    Producer,
    NamedProducer {
        name: String,
    },
    Consumer {
        events: EventFlags,
        pending: Vec<u8>,
        needs_handoff: bool,
        notified: bool,
        vt: usize,
    },
    DeviceConsumer {
        device_name: String,
        events: EventFlags,
        pending: Vec<u8>,
        notified: bool,
    },
    HotplugEvents {
        events: EventFlags,
        pending: Vec<u8>,
        notified: bool,
    },
    Display {
        events: EventFlags,
        pending: Vec<VtEvent>,
        notified: bool,
        device: String,
        is_earlyfb: bool,
    },
    Control,
    SchemeRoot,
 }
 ```
 Notes:
 - `Producer` remains the legacy anonymous producer path.
 - `NamedProducer` only needs the registered name. Device ID lookup stays in shared scheme state.
 - `DeviceConsumer` is byte-oriented like the legacy consumer, but without VT or handoff state.
 - `HotplugEvents` stores serialized variable-length hotplug records in `pending`.
 - `SchemeRoot` remains a dedicated handle variant, but now supports directory enumeration.
 ## 6. Scheme Open Semantics
 `openat()` should parse paths as follows:
 ### 6.1 Existing Paths
 - `producer` with no child component → `Handle::Producer`
 - `consumer` → current VT consumer allocation logic
 - `consumer_bootlog` → current VT 1 logic
 - `handle/{display}` → unchanged
 - `handle_early/{display}` → unchanged
 - `control` → unchanged
 ### 6.2 New Paths
 - `producer/{name}` → `Handle::NamedProducer { name }`
 - `events` → `Handle::HotplugEvents { ... }`
 - any other top-level non-reserved path component → `Handle::DeviceConsumer { device_name, ... }`
 ### 6.3 Name Validation
 Named producer registration must reject:
 - empty names
 - names containing `/`
 - reserved names: `producer`, `consumer`, `consumer_bootlog`, `events`, `handle`, `handle_early`, `control`
 - duplicate live names already present in `devices`
 Recommended error behavior:
 - invalid name → `EINVAL`
 - duplicate name → `EEXIST`
 - open of `/scheme/input/{device_name}` for a currently unknown device → `ENOENT`
 ## 7. State Management
 `InputScheme` should add:
 ```rust
 devices: BTreeMap<String, u32>,
 next_device_id: AtomicUsize,
 ```
 Purpose:
 - `devices` maps device name → current device ID
 - `next_device_id` allocates monotonically increasing IDs
 Behavior:
 1. When `NamedProducer` opens successfully:
   - allocate `device_id = next_device_id.fetch_add(1, Ordering::SeqCst) as u32`
   - insert `devices.insert(name.clone(), device_id)`
   - serialize a `DEVICE_ADD` hotplug message
   - append it to every `Handle::HotplugEvents.pending`
   - set `notified = false` on those hotplug handles
   - set `has_new_events = true`
 2. When `NamedProducer` closes:
   - remove the entry from `devices`
   - serialize a `DEVICE_REMOVE` hotplug message with the removed ID and name
   - append it to every `Handle::HotplugEvents.pending`
   - set `notified = false`
   - set `has_new_events = true`
 3. Device IDs are never reused. If `ps2-keyboard` disappears and later comes back, it gets a new `device_id`.
 No additional kernel state is required. This is ordinary daemon-side bookkeeping.
 ## 8. Event Routing Logic
 The existing preprocessing path in `write()` must remain in place:
 - special Super+Fn VT switching behavior stays in `inputd`
 - keymap translation still happens in `inputd`
 - the emitted payload remains serialized `orbclient::Event`
 After that preprocessing step, routing changes as follows.
 ### 8.1 Legacy Producer
 Input written to `/scheme/input/producer` follows the current legacy route:
 - deliver to the existing legacy consumer path
 - preserve current active-VT behavior
 - do **not** deliver to any `DeviceConsumer`
 - do **not** generate hotplug events
 ### 8.2 Named Producer
 Input written to `/scheme/input/producer/{name}` must be fanned out to:
 1. the matching `DeviceConsumer` handles where `device_name == name`
 2. the existing legacy consumer path used by Orbital and other old clients
 That means named producers are **supersets** of legacy routing, not replacements.
 ### 8.3 Device Consumer
 `/scheme/input/{device_name}` only receives events from the named producer with the exact same name.
 It must never receive:
 - anonymous legacy producer traffic
 - events from other named producers
 - display or control events
 ### 8.4 Routing Sketch
 ```text
 legacy producer write
  -> existing input normalization
  -> legacy VT consumer fan-out only
 named producer write(name)
  -> existing input normalization
  -> device consumers for name
  -> legacy VT consumer fan-out
 ```
 Implementation-wise, the simplest approach is:
 1. detect whether the writer is `Producer` or `NamedProducer { name }`
 2. run the existing event transformation code once
 3. serialize transformed `Event` values once
 4. if named, append to matching `DeviceConsumer.pending`
 5. append to the legacy consumer path using the current active-VT logic
 6. clear `notified` on affected readers and set `has_new_events = true`
 ## 9. Hotplug Event Stream
 `/scheme/input/events` is a read-only stream of variable-length hotplug records.
 ### 9.1 Binary Format
 ```rust
 #[repr(C)]
 struct InputHotplugEvent {
    kind: u32,       // 1 = DEVICE_ADD, 2 = DEVICE_REMOVE
    device_id: u32,  // Unique device identifier
    name_len: u32,   // Length of device name
    _reserved: u32,  // Future use
 }
 // Followed by name_len bytes of UTF-8 device name
 ```
 Constants:
 ```rust
 const DEVICE_ADD: u32 = 1;
 const DEVICE_REMOVE: u32 = 2;
 ```
 ### 9.2 Stream Semantics
 - The stream is append-only and ordered by daemon observation.
 - Each record is serialized as header bytes followed by UTF-8 name bytes.
 - `read()` drains raw bytes from `pending`.
 - Because records are variable-length, callers must handle partial reads.
 - `HotplugHandle` in `lib.rs` should hide this by buffering partial bytes until one full record is available.
 ### 9.3 Notification Model
 `Handle::HotplugEvents` participates in `fevent(EVENT_READ)` exactly like other readable handles:
 - when at least one serialized hotplug record is pending and the handle is subscribed to `EVENT_READ`, post a read event
 - after a successful read drains the buffer, notification becomes edge-triggered again
 ## 10. Scheme Root Enumeration
 Enumeration should be implemented with `getdents()` on `Handle::SchemeRoot`.
 Recommended behavior:
 - `scheme_root()` still creates a `Handle::SchemeRoot`
 - `getdents()` emits static entries plus one entry per `devices` key
 - `read()` on `SchemeRoot` stays invalid (`EBADF` or `EISDIR` are both acceptable if applied consistently)
 - `openat()` continues to require a valid `SchemeRoot` dirfd
 Example visible entries after `ps2d` registers keyboard and mouse:
 ```text
 producer
 consumer
 consumer_bootlog
 events
 handle
 handle_early
 control
 ps2-keyboard
 ps2-mouse
 ```
 This gives normal filesystem-style discovery while keeping old endpoints visible.
 ## 11. `lib.rs` Public API Changes
 The public API should be extended, not replaced.
 ### 11.1 Existing Types Stay
 - `ProducerHandle`
 - `ConsumerHandle`
 - `DisplayHandle`
 - `ControlHandle`
 Their existing constructors and behavior remain unchanged.
 ### 11.2 New Types
 ```rust
 pub struct NamedProducerHandle(File);
 pub struct DeviceConsumerHandle(File);
 pub struct HotplugHandle {
    file: File,
    partial: Vec<u8>,
 }
 #[derive(Debug, Clone)]
 #[repr(C)]
 pub struct HotplugEventHeader {
    pub kind: u32,
    pub device_id: u32,
    pub name_len: u32,
    pub reserved: u32,
 }
 #[derive(Debug, Clone)]
 pub struct HotplugEvent {
    pub kind: u32,
    pub device_id: u32,
    pub name: String,
 }
 pub struct InputDeviceLister;
 ```
 ### 11.3 Constructors
 ```rust
 impl NamedProducerHandle {
    pub fn new(name: &str) -> io::Result<Self>;
 }
 impl DeviceConsumerHandle {
    pub fn new(device_name: &str) -> io::Result<Self>;
 }
 impl HotplugHandle {
    pub fn new() -> io::Result<Self>;
 }
 ```
 Path mapping:
 - `NamedProducerHandle::new("ps2-keyboard")` → `/scheme/input/producer/ps2-keyboard`
 - `DeviceConsumerHandle::new("ps2-keyboard")` → `/scheme/input/ps2-keyboard`
 - `HotplugHandle::new()` → `/scheme/input/events`
 ### 11.4 Read/Write Shape
 Recommended API shape:
 ```rust
 impl NamedProducerHandle {
    pub fn write_event(&mut self, event: orbclient::Event) -> io::Result<()>;
 }
 pub enum DeviceConsumerHandleEvent<'a> {
    Events(&'a [Event]),
 }
 impl DeviceConsumerHandle {
    pub fn event_handle(&self) -> BorrowedFd<'_>;
    pub fn read_events<'a>(&self, events: &'a mut [Event])
        -> io::Result<DeviceConsumerHandleEvent<'a>>;
 }
 impl HotplugHandle {
    pub fn event_handle(&self) -> BorrowedFd<'_>;
    pub fn read_event(&mut self) -> io::Result<Option<HotplugEvent>>;
 }
 ```
 `DeviceConsumerHandle` deliberately mirrors `ConsumerHandle`, but it does not need `Handoff` support because VT display handoff is unrelated to per-device streams.
 ### 11.5 Device Enumeration Helper
 `InputDeviceLister` should provide a safe wrapper around scheme-root directory reads, for example:
 ```rust
 impl InputDeviceLister {
    pub fn list() -> io::Result<Vec<String>>;
 }
 ```
 Behavior:
 - read `/scheme/input/` as a directory
 - drop reserved static entries
 - return only currently registered device names
 This keeps callers out of scheme-internal filtering logic.
 ## 12. Producer Lifecycle and Consumer Behavior
 ### 12.1 Named Producer Registration
 Opening `/scheme/input/producer/{name}` is both:
 - creation of a producer handle
 - registration of `{name}` as a live device
 Closing the fd unregisters the device.
 This matches current scheme style well because `inputd` already uses `on_close()` to clean up VT consumers.
 ### 12.2 Device Consumer Lifetime
 Per-device consumer handles are name-based subscriptions.
 - open succeeds only while the device name is currently registered
 - once open, the handle remains attached to that name
 - if the producer disappears, no more events arrive for that handle
 - if the same name is registered again later, the handle resumes receiving events for that name
 - the hotplug stream is how clients notice that the underlying producer instance changed
 This keeps `DeviceConsumer` simple and avoids introducing a second handle teardown protocol.
 ## 13. Migration Path
 ### 13.1 `ps2d`
 `ps2d` is the first caller that should adopt the new API because it already has a clean split between keyboard and mouse sources.
 Recommended startup logic:
 1. Try `NamedProducerHandle::new("ps2-keyboard")`
 2. Try `NamedProducerHandle::new("ps2-mouse")`
 3. If both succeed, run in named mode
 4. If either fails, close any partially opened named handle and fall back to one legacy `ProducerHandle::new()`
 Routing:
 - keyboard scancodes → `ps2-keyboard`
 - mouse move / absolute move / button / scroll events → `ps2-mouse`
 This preserves compatibility with old `inputd` while immediately enabling per-device consumers on new `inputd`.
 ### 13.2 `evdevd`
 Once the scheme exists, local `evdevd` can move from `/scheme/input/consumer` to:
 - `InputDeviceLister::list()` to discover devices
 - `DeviceConsumerHandle::new(name)` for device-local streams
 - `HotplugHandle::new()` to watch add/remove
 It can keep the legacy consumer path as a fallback for older systems.
 ### 13.3 `usbhidd`
 `usbhidd` can remain legacy initially, then later migrate to named producers such as `usb-hid0`, `usb-hid1`, or more specific per-interface names.
 ## 14. Backward Compatibility Requirements
 All of the following must continue to work unchanged:
 - `/scheme/input/producer`
 - `/scheme/input/consumer`
 - `/scheme/input/consumer_bootlog`
 - `/scheme/input/handle/{display}`
 - `/scheme/input/handle_early/{display}`
 - `/scheme/input/control`
 - current `ProducerHandle`, `ConsumerHandle`, `DisplayHandle`, and `ControlHandle` APIs
 - current active-VT routing and graphics handoff behavior
 Compatibility rules:
 1. Old producers still emit anonymous events into the legacy stream.
 2. Old consumers still receive the same event format and VT behavior.
 3. New named producers additionally feed the legacy stream, so old consumers continue to see those events.
 4. No caller is forced to understand hotplug or enumeration.
 ## 15. Non-Goals
 This design does **not** include:
 - capability discovery (`keyboard` vs `mouse` metadata)
 - kernel support or syscall ABI changes
 - replacing `orbclient::Event` with a new event format
 - changing VT ownership, display handoff, or control command semantics
 - automatic migration of existing daemons
 ## 16. Implementation Checklist
 Another developer implementing this design should be able to proceed in this order:
 1. extend `Handle` and `InputScheme` state
 2. teach `openat()` to parse `producer/{name}`, `events`, and dynamic device names
 3. add root `getdents()` support for `SchemeRoot`
 4. refactor `write()` so producer type is detected before routing
 5. fan out named-producer events to matching `DeviceConsumer` handles and the existing legacy path
 6. add hotplug queue serialization helpers
 7. extend `fevent()` and daemon notification loop for `DeviceConsumer` and `HotplugEvents`
 8. add cleanup in `on_close()` for `NamedProducer`
 9. extend `lib.rs` with the new handle types and directory lister
 10. migrate `ps2d` with a named-producer-first, legacy-fallback strategy
 ## 17. Final Outcome
 After this enhancement:
 - Orbital and any other legacy consumer continue to work as-is.
 - `ps2d` and future drivers can publish stable device names.
 - `evdevd` and similar services can subscribe to exactly one device stream.
 - userspace can enumerate live input devices and react to hotplug events.
 That solves the current anonymity problem without changing the kernel or breaking the existing Redox input stack.
@@ -0,0 +1,83 @@
 # Red Bear OS Networking: RTL8125 + netctl
 ## Native stack
 Red Bear uses the native Redox wired networking path already present in the base tree:
 `pcid-spawner` → native NIC daemon (`rtl8168d`, `e1000d`, `ixgbed`, `virtio-netd`) → `network.*`
 scheme → `smolnetd` → `dhcpd` / `netcfg`.
 This change keeps RTL8125 in that native path instead of trying to introduce a Linux netdevice,
 `sk_buff`, or NAPI compatibility layer into `linux-kpi`.
 ## RTL8125 path
 - Autoload now matches `10ec:8125` in `recipes/core/base/source/drivers/net/rtl8168d/config.toml`.
 - The existing Realtek driver binary remains the autoload target (`rtl8168d`).
 - The daemon names RTL8125 devices distinctly in its `network.*` scheme name suffix.
 This is the narrowest viable implementation path in the current tree. It reuses the existing
 userspace driver, PCI spawn, and netstack plumbing already proven for the native Realtek path.
 ## relibc networking surface
 The Redox-facing libc networking surface was extended to stop reporting a fake `stub` interface:
 - `net/if.h` now exposes a real `eth0`-based view of the active interface model
 - `ifaddrs.h` now returns a populated `eth0` entry
 - Redox `ioctl()` now answers the common read-only `SIOCGIF*` queries used by interface-aware apps
 - `netinet/in.h` now includes `in6_pktinfo`
 - a minimal `resolv.h` is now generated in relibc
 This is intentionally aligned with the current single-active-interface design in `smolnetd` and
 `netcfg`.
 ## netctl
 Red Bear ships a Redox-native `netctl` compatibility command in `redbear-netctl`.
 ### Supported profile subset
 - `Interface=eth0`
 - `Connection=ethernet`
 - `IP=dhcp`
 - `IP=static`
 - `Address=('a.b.c.d/prefix')`
 - `Gateway='a.b.c.d'`
 - `DNS=('a.b.c.d')`
 ### Supported commands
 - `netctl list`
 - `netctl status [profile]`
 - `netctl start <profile>`
 - `netctl stop <profile>`
 - `netctl enable <profile>`
 - `netctl disable [profile]`
 - `netctl is-enabled [profile]`
 - `netctl --boot`
 Profiles live in `/etc/netctl`. Shipped examples live in `/etc/netctl/examples/`.
 ### Boot integration
 Red Bear configs install `/usr/lib/init.d/12_netctl.service`, which runs:
 ```text
 netctl --boot
 ```
 If `/etc/netctl/active` contains a profile name, that profile is applied during boot after the
 base networking services have started.
 ## Validation notes
 - `redbear-netctl` was type-checked and smoke-tested with a fake runtime root by exercising:
  `list`, `enable`, `status`, and `start`.
 - `rtl8168d` type-checks with the RTL8125 autoload configuration in place.
 - relibc type-checks with the interface and header updates in place.
 ## Remaining hardware validation
 This repo change set wires RTL8125 through the native path, but real hardware validation is still
 required for full confidence in packet I/O on specific RTL8125 revisions.
@@ -0,0 +1,348 @@
 # Qt6 Port — Red Bear OS
 **Last updated:** 2026-04-14
 **Qt version:** 6.11.0
 **Target:** x86_64-unknown-redox (cross-compiled from Linux x86_64 host)
 **Phase 1 status:** ✅ COMPLETE — Qt6 core stack + OpenGL/EGL + D-Bus + Wayland
 **Phase 2 status:** ✅ COMPLETE — All 32 KF6 frameworks built
 **Phase 3 status:** 🔄 IN PROGRESS — KWin + KDE Plasma build
 ## Current Status Summary
 | Component | Status | Details |
 |-----------|--------|---------|
 | **qtbase** | ✅ | 13 libs incl. OpenGL, EGL, DBus, WaylandClient |
 | **qtdeclarative** | ✅ | 11 libs, QML JIT disabled |
 | **qtsvg** | ✅ | 2 libs |
 | **qtwayland** | ✅ | Wayland client + compositor |
 | **Mesa EGL+GBM** | ✅ | libEGL, libgbm, libGLESv2, swrast DRI |
 | **libdrm** | ✅ | libdrm + libdrm_amdgpu |
 | **libinput** | ✅ | 1.30.2 with comprehensive redox.patch |
 | **D-Bus** | ✅ | 1.16.2, libdbus-1.so |
 | **KF6 Frameworks** | ✅ 32/32 | All frameworks built |
 | **KWin** | 🔄 | Recipe ready, now using real `libxcvt`, but still blocked by remaining shimmed/stubbed deps and incomplete runtime path |
 | **Hardware acceleration** | ❌ | Requires kernel DMA-BUF (future work) |
 ---
 ## Scope Definition
 **Phase 1 scope**: qtbase, qtdeclarative, qtsvg — the foundational Qt6 stack.
 Qt6 consists of many modules — each is a separate source package. Phase 2 (qtwayland + KF6 Tier 1)
 follows in the next step.
 **User-agreed scope constraints:**
 - OpenGL: software/shm only, no EGL — get Qt compiling first
 - Disabled features: process, sharedmemory, systemsemaphore, testlib, sql, printsupport
 - Iterative approach: enable modules incrementally, re-enable disabled features later
 ## Build Status
 ### qtbase — Enabled Modules (7 libraries built)
 | Module | Library | Size | Description |
 |--------|---------|------|-------------|
 | QtCore | libQt6Core.so.6.11.0 | 13 MB | Core non-GUI: event loop, IO, threads, plugins |
 | QtConcurrent | libQt6Concurrent.so.6.11.0 | 26 KB | High-level multi-threading without locks |
 | QtXml | libQt6Xml.so.6.11.0 | 212 KB | XML stream reader/writer (SAX/DOM) |
 | QtGui | libQt6Gui.so.6.11.0 | 12 MB | GUI infra: images, painting, text, input, windowing |
 | QtWidgets | libQt6Widgets.so.6.11.0 | 9.4 MB | Widget toolkit: buttons, layouts, dialogs |
 | QtWaylandClient | libQt6WaylandClient.so.6.11.0 | — | Wayland client integration |
 | QtWlShellIntegration | libQt6WlShellIntegration.so.6.11.0 | — | Wayland Shell integration |
 ### qtbase — Plugins (12 plugin libraries)
 | Plugin | File | Type |
 |--------|------|------|
 | redox | libqredox.so | QPA platform |
 | offscreen | libqoffscreen.so | QPA platform |
 | minimal | libqminimal.so | QPA platform |
 | wayland-bsoft-integration | libqwayland-bsoft-integration.so | Wayland integration |
 | gif | libqgif.so | Image format |
 | ico | libqico.so | Image format |
 | jpeg | libqjpeg.so | Image format |
 | png | libqpng.so | Image format |
 | svg | libqsvg.so | Image format |
 | iconengines | libqsvgicon.so | Icon engine |
 | text | libqtext.so | Text platform |
 | xkb | libqxkb.so | XKB support |
 ### qtdeclarative — Built Successfully (build 15)
 | Library | Description |
 |---------|-------------|
 | libQt6Qml.so.6.11.0 | QML core |
 | libQt6QmlModels.so.6.11.0 | Models (ListModel, etc.) |
 | libQt6Quick.so.6.11.0 | QtQuick UI framework |
 | libQt6QmlCore.so.6.11.0 | QML internals |
 | libQt6QmlCompiler.so.6.11.0 | QML JIT compiler |
 | libQt6QmlWorkerScript.so.6.11.0 | Worker script runtime |
 | libQt6QmlMeta.so.6.11.0 | QML meta-object |
 | libQt6QmlXmlListModel.so.6.11.0 | XML ListModel |
 | libQt6LabsFolderListModel.so.6.11.0 | Folder list model |
 | libQt6LabsQmlModels.so.6.11.0 | Lab models |
 | libQt6LabsSettings.so.6.11.0 | Settings |
 | libQt6LabsSynchronizer.so.6.11.0 | Synchronizer |
 Plus: QML debug plugins, QtQuick/QML modules staged.
 **Note**: QML JIT (`QT_FEATURE_qml_jit`) does not compile for Redox — disabled.
 ### qtsvg — Built Successfully
 | Component | File |
 |-----------|------|
 | libQt6Svg.so.6.11.0 | SVG rendering |
 | libQt6SvgWidgets.so.6.11.0 | SVG widget integration |
 | qsvg icon engine | libqsvgicon.so |
 | qsvg image format | libqsvg.so |
 ### Disabled Modules — Full Blocker Analysis
 | Module | Blocker | Root Cause | Re-enable Path |
 |--------|---------|------------|----------------|
 | QtNetwork | Runtime validation still pending | the relibc header/ioctl surface is now present in-tree, but downstream QtNetwork behavior still needs end-to-end validation on Redox | Validate QtNetwork against the updated relibc networking surface |
 | QtOpenGL | No EGL, no GPU driver runtime validation | amdgpu/intel DRM drivers compile but haven't been validated on hardware; no Mesa EGL build | Validate GPU drivers on HW → build Mesa with EGL → enable QtOpenGL |
 | QtOpenGLWidgets | Gated by `QT_FEATURE_opengl` | Same as QtOpenGL | Same as QtOpenGL |
 | QtDBus | D-Bus IPC system not ported to Redox | No D-Bus daemon or libdbus on Redox | Port libdbus → enable QtDBus |
 | QtSql | User-agreed scope exclusion | Not needed for initial GUI | Add sqlite/odbc recipe → enable QtSql |
 | QtPrintSupport | User-agreed scope exclusion | No printing subsystem on Redox | Port cups/filters → enable QtPrintSupport |
 ### Disabled Features — Full Blocker Analysis
 | Feature | CMake Flag | Blocker | Re-enable Path |
 |---------|-----------|---------|----------------|
 | OpenGL | `-DFEATURE_opengl=OFF` | No EGL, no GPU runtime validation | Validate GPU drivers → Mesa EGL → enable |
 | EGL | `-DFEATURE_egl=OFF` | No libEGL from Mesa | Mesa EGL build → enable |
 | XCB/Xlib | `-DFEATURE_xcb=OFF -DFEATURE_xlib=OFF` | No X11 on Redox | Not applicable — Redox uses Wayland |
 | Vulkan | `-DFEATURE_vulkan=OFF` | No Vulkan runtime | Port Mesa Vulkan ICD → enable |
 | OpenSSL | `-DFEATURE_openssl=OFF` | OpenSSL3 port in WIP but not validated | Validate openssl3 recipe → enable |
 | D-Bus | `-DFEATURE_dbus=OFF` | No D-Bus on Redox | Port libdbus → enable |
 | Process | `-DFEATURE_process=OFF` | relibc POSIX completeness for QProcess | Test QProcess on Redox → enable |
 | Shared Memory | `-DFEATURE_sharedmemory=OFF` | `QSharedMemory` uses `shm_open()`/`shmget()` | Add `shm_open`/`shmget` to relibc |
 | System Semaphore | `-DFEATURE_systemsemaphore=OFF` | `QSystemSemaphore` uses `sem_open()`/`semget()` | Add POSIX semaphores to relibc |
 | qmake | `-DFEATURE_qmake=OFF` | Build tool, not needed with CMake | Enable if downstream needs qmake |
 | SQL | `-DFEATURE_sql=OFF` | User-agreed scope exclusion | Add sqlite/odbc → enable |
 | Print Support | `-DFEATURE_printsupport=OFF` | User-agreed scope exclusion | Port cups → enable |
 | QML JIT | `-DFEATURE_qml_jit=OFF` | Does not compile for Redox | Fix in upstream or disable permanently |
 ---
 ## New Discoveries (Builds 8–17)
 | # | Discovery | Fix |
 |---|-----------|-----|
 | 8 | qtwaylandscanner is a host tool, needs `FEATURE_qtwaylandscanner=ON` in both host and target builds | Enable feature in both cmake configs |
 | 9 | wayland-scanner must be host binary — use `-DWaylandScanner_EXECUTABLE=/usr/bin/wayland-scanner` | Pass explicit path to host wayland-scanner |
 | 10 | OpenGL guards needed in Wayland code (`#if QT_CONFIG(opengl)`) | Add guard in qtbase patch |
 | 11 | `cmake --install` produces relocatable cmake files — replaced manual cmake copy | Use cmake install instead of manual sed |
 | 12 | `QT_MKSPECS_DIR` must point to staged mkspecs — conditional in toolchain file | Add conditional logic in redox-toolchain.cmake |
 | 13 | QtNetwork features leak into downstream — pass `QT_FEATURE_ssl=OFF` etc. | Explicitly disable in downstream cmake |
 | 14 | SBOM generation fails — use `-DQT_GENERATE_SBOM=OFF` | Disable SBOM generation |
 | 15 | Sysroot path mismatch — cookbook only symlinks bin/include/lib/share, need manual symlinks for plugins/mkspecs/metatypes/modules | Add manual symlinks in recipe |
 | 16 | masm `CheckedArithmetic.h` missing `ArithmeticOperations<unsigned,long>` for LP64 | Add missing arithmetic operation to masm |
 | 17 | QML JIT (`QT_FEATURE_qml_jit`) doesn't compile for Redox — disabled | Disable feature, works without JIT |
 | 56 | **plasma-wayland-protocols** is a required separate package — kf6-kwayland needs PLASMA_WAYLAND_PROTOCOLS_DIR pointing to protocol XMLs | Created recipe that installs XML files + symlink for naming mismatch (org-kde-plasma-virtual-desktop.xml → plasma-virtual-desktop.xml) |
 | 57 | **kf6-kcmutils** requires Qt6Quick unconditionally upstream | Strip Quick/QML/kcmshell from CMakeLists via Python-based source patching — produces libKF6KCMUtils.so + libKF6KCMUtilsCore.so (widget-only build) |
 | 58 | **kf6-kwayland** fails with `get_filename_component called with incorrect number of arguments` when PLASMA_WAYLAND_PROTOCOLS_DIR is unset | Fix: create plasma-wayland-protocols package + point the cmake variable to the installed XMLs |
 | 59 | **seatd** now builds as a standalone runtime package for Redox and is wired into the KDE runtime config; keep it out of KWin compile deps until DRM-lease/runtime validation exists | Runtime dependency only |
 ---
 ## Build Iteration History
 | # | Issue | Fix |
 |---|-------|-----|
 | 1-7 | Patch format, byteswap.h, forwarding headers | Patch structure |
 | 8 | qtwaylandscanner is host tool | `FEATURE_qtwaylandscanner=ON` in host+target |
 | 9 | wayland-scanner must be host binary | `-DWaylandScanner_EXECUTABLE=/usr/bin/wayland-scanner` |
 | 10 | OpenGL guards in Wayland code | `#if QT_CONFIG(opengl)` guard |
 | 11 | cmake --install relocatable | Use cmake install over manual copy |
 | 12 | QT_MKSPECS_DIR mismatch | Conditional in toolchain file |
 | 13 | QtNetwork feature leak | Pass explicit QT_FEATURE_* flags |
 | 14 | SBOM generation fails | `-DQT_GENERATE_SBOM=OFF` |
 | 15 | Sysroot path mismatch (plugins/mkspecs/metatypes/modules) | Manual symlinks |
 | 16 | masm CheckedArithmetic.h missing LP64 operation | Add ArithmeticOperations |
 | 17 | QML JIT doesn't compile for Redox | Disable `QT_FEATURE_qml_jit` |
 | **Phase 1** | **qtbase + qtdeclarative + qtsvg complete** | **✅ Core stack built** |
 ---
 ## relibc Gaps — Complete Inventory
 ### Resolved (workarounds in recipe/patch)
 | Gap | Workaround | Location |
 |-----|-----------|----------|
 | `sys/statfs.h` missing | Wrapper → `sys/statvfs.h` (typedef, #define) | recipe.toml heredoc |
 | `ELFMAG` string missing from `elf.h` | `#define ELFMAG "\177ELF"` prepended to source | recipe.toml printf |
 | `resolv.h` availability | Minimal relibc header now exists in-tree | verify downstream consumers against the generated header |
 | `unlinkat()`/`linkat()` missing | Inline stubs with `AT_FDCWD` | redox.patch |
 | `byteswap.h` missing | Skip include on Redox | redox.patch (brg_endian.h) |
 | Float16 soft-fp (`__truncsfhf2` etc.) | Custom IEEE 754 C implementation | redox.patch (qt_float16_shims.c) |
 | Half-float comparison (`__eqhf2` etc.) | Custom IEEE 754 C implementation | redox.patch (same file) |
 | `openat()` not available | `#ifdef Q_OS_REDOX` guard | redox.patch (qcore_unix_p.h) |
 ### Networking Surface — Now Present, Still Needs Runtime Validation
 | Gap | Impact | relibc File to Modify |
 |-----|--------|----------------------|
 | `resolv.h` | Present in relibc | `recipes/core/relibc/source/src/header/resolv/` |
 | `in6_pktinfo` / `ipv6_mreq` | Present in relibc | `recipes/core/relibc/source/src/header/netinet_in/mod.rs` |
 | `SIOCGIF*` ioctls | Present for the current Redox `eth0` model | `recipes/core/relibc/source/src/header/sys_ioctl/redox/mod.rs` |
 | `::ioctl` path | Present in relibc Redox ioctl implementation | `recipes/core/relibc/source/src/header/sys_ioctl/` |
 | `ifreq` / `ifconf` / `ifaddrs` | Present for the current Redox `eth0` model | `recipes/core/relibc/source/src/header/net_if/mod.rs`, `recipes/core/relibc/source/src/header/ifaddrs/mod.rs` |
 ### Unresolved — Blocks Other Qt Modules/Features
 | Gap | Impact | Module Blocked |
 |-----|--------|---------------|
 | D-Bus IPC | QtDBus, KDE components | QtDBus |
 | GPU display validation | Hardware-accelerated rendering | QtOpenGL |
 | `shm_open()` / `shmget()` | Shared memory | QSharedMemory |
 | `sem_open()` / `semget()` | POSIX semaphores | QSystemSemaphore |
 | `fork()`/`exec()` POSIX completeness | QProcess internals | QProcess |
 | Fontconfig | Advanced font selection | QtGui (bundled FreeType works for basic) |
 ---
 ## Next Steps
 ### Phase 2a — qtbase D-Bus Enablement (✅ COMPLETE)
 - qtbase rebuilt with `-DFEATURE_dbus=ON` in both host and target builds
 - libQt6DBus.so + Qt6DBusConfig.cmake + Qt6DBus.pc staged to sysroot
 - D-Bus 1.16.2 already built (24-line redox.patch for epoll + socketpair)
 - Unblocks: kf6-kdbusaddons, kf6-kservice, kf6-kpackage, kf6-kglobalaccel
 ### Phase 2b — qtwayland Module (🔄 Building)
 - Recipe at `recipes/wip/qt/qtwayland/recipe.toml`
 - Uses redox-toolchain.cmake + host Qt build pattern
 - Wayland compositor disabled, client-only build
 - OpenGL guards applied for software rendering
 ### Phase 2c — Input Stack (✅ COMPLETE)
 - linux-input-headers: ✅ Built — provides linux/input.h + linux/types.h + _CNT macros
 - libevdev 1.13.2: ✅ Built — uinput stubs + input.h __redox__ guard
 - libinput 1.30.2: ✅ Built — comprehensive redox.patch:
  - SYS_pidfd_open meson guard (cc.has_header check)
  - Non-udev shim (libudev stub for HAVE_UDEV=0)
  - Vendored Linux input.h selection for __redox__
  - strtod_l() fallback
  - timerfd fallback (tracks expiry without timerfd fd)
  - Linux-only tool binaries skipped on Redox
 ### Phase 3 — KF6 Frameworks (✅ ALL 32 BUILT)
 All KF6 frameworks built and staged:
 ecm, kcoreaddons, kwidgetsaddons, kconfig, ki18n, kcodecs, kguiaddons, kcolorscheme,
 kauth, kwindowsystem, knotifications, kjobwidgets, kconfigwidgets, karchive, sonnet,
 kcompletion, kitemviews, kitemmodels, solid, kdbusaddons, kservice, kpackage,
 kcrash, ktextwidgets, kiconthemes, kglobalaccel, kdeclarative, kxmlgui, kbookmarks,
 kidletime, kio, kcmutils
 Additional KDE packages:
 - kdecoration ✅ BUILT (KDecoration3 window decoration library)
 - kirigami ✅ STUB ONLY (dependency-resolution package, not a real runtime-ready Kirigami build)
 - kf6-kwayland ✅ BUILT
 - kf6-kcmutils ✅ BUILT (widget-only, Quick/QML/kcmshell stripped)
 - plasma-wayland-protocols ✅ BUILT (protocol XMLs for kf6-kwayland)
 Graphics stack (PRIMARY DELIVERABLE):
 - Mesa EGL+GBM ✅ BUILT (libEGL.so, libgbm.so, libGLESv2.so, swrast_dri.so)
 - libdrm amdgpu ✅ BUILT (libdrm_amdgpu.so, /scheme/drm/ paths)
 - Qt6 OpenGL ✅ BUILT (libQt6OpenGL.so, libQt6EglFSDeviceIntegration.so, GLES 2.0)
 - D-Bus ✅ BUILT (libdbus-1.so.3.38.3, dbus-daemon)
 - libinput ✅ BUILT (libinput.so.10.13.0, comprehensive redox.patch)
 - libevdev ✅ BUILT (libevdev.so.2.3.0, uinput stubs)
 KWin recipe updated with 40 dependencies (all KF6 + Mesa + libdrm + libinput + qtwayland).
 plasma-workspace, plasma-desktop recipes created.
 ### Phase 4 — Graphics Stack (✅ COMPLETE)
 Mesa EGL+GBM+GLES2 built:
 - libEGL.so (225KB) — platforms: redox, surfaceless, drm
 - libgbm.so (68KB) — Generic Buffer Manager for compositor buffer allocation
 - libGLESv2.so — OpenGL ES 2.0 (software via LLVMpipe)
 - libGLESv1_CM.so — OpenGL ES 1.1
 - swrast_dri.so + kms_swrast_dri.so — LLVMpipe software DRI drivers
 - pkgconfig: egl.pc, gbm.pc, osmesa.pc, glesv2.pc, dri.pc
 libdrm amdgpu enabled:
 - libdrm_amdgpu.so (48KB) — AMD GPU DRM API
 - Device paths: /scheme/drm/cardN, /scheme/drm/renderD
 Qt6 OpenGL enabled:
 - libQt6OpenGL.so (716KB) — Qt OpenGL module (GLES 2.0 path)
 - libQt6OpenGLWidgets.so — Qt OpenGL widgets
 - libQt6EglFSDeviceIntegration.so — EGLFS platform integration
 - EGLFS KMS plugin for direct DRM/KMS rendering
 ### Phase 4b — Qt6 OpenGL Enablement (✅ COMPLETE)
 qtbase rebuilt with `-DFEATURE_opengl=ON -DINPUT_opengl=es2 -DFEATURE_egl=ON`
 Qt cmake summary: EGL=yes, OpenGL=yes, "OpenGL ES 2.0=yes, EGLFS GBM=yes"
 ### Phase 5 — KDE Plasma (🔄 IN PROGRESS)
 KDE Plasma packages built:
 - kf6-kwayland ✅ BUILT
 - kf6-kcmutils ✅ BUILT (widget-only, Quick/QML/kcmshell stripped)
 - kirigami ✅ STUB ONLY (dependency-resolution package, not a real runtime-ready Kirigami build)
 - plasma-wayland-protocols ✅ BUILT (protocol XMLs for kf6-kwayland)
 - kdecoration ✅ BUILT (KDecoration3 window decoration library)
 KWin recipe updated with dependencies (all KF6 + Mesa + libdrm + libinput + qtwayland):
 - All KF6 deps built (kconfigwidgets, kxmlgui, kglobalaccel, kidletime, kio, etc.)
 - Mesa EGL+GBM ✅
 - libinput ✅
 - libdrm ✅
 - kf6-kwayland ✅
 - seatd builds separately (runtime dependency, not needed for compilation)
 ### Phase 6 — KWin (🔄 BUILDING)
 ## Dependency Graph
 ```
 Phase 1 ✅ (qtbase + qtdeclarative + qtsvg)
    └── Phase 2a ✅ (D-Bus daemon + qtbase D-Bus enablement)
    └── Phase 2b ✅ (qtwayland built)
    └── Phase 2c ✅ (libevdev + libinput built)
    └── Phase 3 ✅ (KF6 — ALL 32 frameworks built)
    └── Phase 4 ✅ (Mesa EGL+GBM+GLES2, Qt6 OpenGL+EGL, libdrm amdgpu)
    └── Phase 5 🔄 (kdecoration ✅, kf6-kwayland ✅, kirigami stub-only, KWin still blocked on shimmed/scaffolded deps)
 ```
 ---
 ## Known Issues
 1. **QML JIT disabled** — `QT_FEATURE_qml_jit` does not compile for Redox. QML still works
   via the interpreter path, just without JIT acceleration. Non-blocking for basic QML apps.
 2. **QtNetwork disabled** — DNS resolver and IPv6 multicast gaps in relibc. HTTP/WebSocket
   unavailable until relibc networking is completed. QML network access also affected.
 3. **No GPU hardware acceleration** — Qt6 OpenGL/EGL and Mesa EGL+GBM now build, but they are still validated only on the software/LLVMpipe path.
   True hardware acceleration (radeonsi or equivalent) still requires kernel DMA-BUF fd passing and real hardware validation.
 4. **relibc / graphics surface still incomplete for runtime** — the build-side `open_memstream` and Wayland-facing header export path now work,
   but DMA-BUF ioctls, sync objects, and broader graphics runtime validation are still unavailable.
 5. **KDE Plasma does NOT compile or run end-to-end** — KWin, plasma-workspace, plasma-desktop recipes exist,
   but are still blocked on shimmed/stubbed dependencies, runtime integration, and compositor validation.
 ## Honest Status Assessment
 The Qt6/KF6 build stack is substantially further along than the earlier "~50%" estimate implied:
 - Qt6, QtWayland, Mesa EGL+GBM, Qt6 OpenGL, libdrm amdgpu, and all 32 KF6 frameworks now build
 - the remaining blockers are concentrated in KWin/Plasma runtime integration and in the still-shimmed or stub-only packages such as Kirigami, libepoxy, libudev, lcms2, and libdisplay-info
 - hardware acceleration still requires kernel DMA-BUF work and real hardware validation
 - a successful build stack is not yet the same thing as a working KDE Plasma session
 (Updated 2026-04-14 — status reconciled after relibc/libwayland bridge fixes; build-side progress is real, runtime remains incomplete)
@@ -0,0 +1,64 @@
 # redbear-info Runtime Report
 `redbear-info` is the canonical Red Bear OS runtime integration and debugging command.
 ## Purpose
 The tool is intentionally passive. It reports what the running system can actually prove through
 read-only runtime surfaces instead of flattening everything into a single “available” bit.
 It is meant to answer:
 - what Red Bear integrations are installed,
 - what services or schemes are actually active,
 - what integrations passed a safe read-only runtime probe,
 - whether networking is configured, including IP, DNS, and default route,
 - whether key hardware discovery surfaces (PCI, USB, DRM, RTL8125) are visible.
 ## Output model
 Each integration is reported with one of these layered states:
 - `absent` — no artifact or runtime surface was observed
 - `present` — an artifact or config exists, but there is no live runtime proof yet
 - `active` — a live runtime surface exists, but the probe cannot honestly claim full working order
 - `functional` — a safe read-only runtime probe succeeded
 - `unobservable` — no honest runtime proof exists for a deeper claim
 This distinction matters because some Red Bear integrations compile or package cleanly before they
 are hardware-validated at runtime.
 ## Current sections
 `redbear-info` reports:
 - **Identity** — OS name, version, hostname
 - **Networking** — stack state, connected flag, interface, MAC, IP/CIDR, DNS, default route,
  active `netctl` profile, visible `network.*` schemes
 - **Hardware** — PCI device count, USB controller count, DRM card count, RTL8125 PCI visibility
 - **Integrations** — tools, daemons, and integration paths such as `lspci`, `lsusb`, `netctl`,
  `pcid-spawner`, `smolnetd`, `firmware-loader`, `udev-shim`, `evdevd`, `redox-drm`, and the
  native RTL8125 path
 ## Commands
 - `redbear-info` — human-readable report
 - `redbear-info --verbose` — includes evidence and claim limits
 - `redbear-info --json` — structured machine-readable output
 - `redbear-info --test` — suggested follow-up diagnostic commands
 ## Maintenance rule
 Whenever Red Bear adds or materially changes an integration, update `redbear-info` in the same
 change set.
 That includes new:
 - user-facing tools
 - scheme daemons
 - services
 - hardware integration paths
 - configuration layers that users rely on to debug a running image
 The goal is for `redbear-info` to remain the first command users run when they need to understand
 the state of a Red Bear system.