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>
This commit is contained in:
@@ -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) |
|
||||
| P4: Wayland compositor | 4-6 weeks | Smithay Redox backends |
|
||||
| P5: Full amdgpu | 16-24 weeks | Complete GPU driver via LinuxKPI (parallel) |
|
||||
| P6: KDE Plasma | 12-16 weeks | Qt6 → KDE Frameworks → KWin → Plasma Shell |
|
||||
| ~~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 | 🚧 Partial — libwayland/Qt6 Wayland/Mesa EGL+GBM+GLES2/Qt6 OpenGL now build, but compositor/runtime validation is still incomplete |
|
||||
| ~~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 | 🚧 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)
|
||||
P3 (POSIX+input) ──────────────┘
|
||||
P0 (ACPI boot) ✅ → P1 (driver infra) ✅ → P2 (AMD display) ✅ → P3 (POSIX+input, build-side) 🚧 → P4 (Wayland runtime) 🚧 → P6 (KDE)
|
||||
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 |
|
||||
| `timerfd` / `TFD_CLOEXEC` / `TFD_TIMER_ABSTIME` | libwayland timers | Not implemented |
|
||||
| `eventfd` / `EFD_CLOEXEC` | libwayland server | Not implemented |
|
||||
| `F_DUPFD_CLOEXEC` | libwayland fd management | Not implemented |
|
||||
| `MSG_CMSG_CLOEXEC` | libwayland socket recv | Not implemented |
|
||||
| `MSG_NOSIGNAL` | libwayland connection | Not implemented |
|
||||
| `open_memstream` | libdrm, libwayland | 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 | Implemented in-tree; downstream libwayland still patched around usage |
|
||||
| `eventfd` / `EFD_CLOEXEC` | libwayland server | Implemented in-tree; downstream libwayland still patched around usage |
|
||||
| `F_DUPFD_CLOEXEC` | libwayland fd management | Implemented in-tree |
|
||||
| `MSG_CMSG_CLOEXEC` | libwayland socket recv | Implemented in-tree |
|
||||
| `MSG_NOSIGNAL` | libwayland connection | Implemented in-tree; downstream libwayland still omits flag |
|
||||
| `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)
|
||||
4. **No DRM/KMS** (libdrm has all GPU drivers disabled)
|
||||
5. **cosmic-comp**: missing keyboard input, performance issues
|
||||
3. **Input/runtime integration remains incomplete** (`evdevd`, `udev-shim`, and libinput exist, but compositor input is not fully validated)
|
||||
4. **DRM/KMS runtime validation remains incomplete** (`redox-drm` exists in-tree, but full Wayland/driver runtime integration is still open)
|
||||
5. **cosmic-comp**: keyboard/input integration and performance issues remain
|
||||
|
||||
+54
-26
@@ -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 |
|
||||
| `timerfd_create/settime/gettime` | **Missing** | `relibc/src/header/sys_timerfd/` (NEW directory) | Medium |
|
||||
| `eventfd`/`eventfd_read`/`eventfd_write` | **Missing** | `relibc/src/header/sys_eventfd/` (NEW directory) | Low |
|
||||
| `F_DUPFD_CLOEXEC` | **Missing** | `relibc/src/header/fcntl/mod.rs` (add constant) | Low |
|
||||
| `MSG_CMSG_CLOEXEC` | **Missing** | `relibc/src/header/sys_socket/mod.rs` | Low |
|
||||
| `MSG_NOSIGNAL` | **Missing** | `relibc/src/header/sys_socket/mod.rs` | Low |
|
||||
| `open_memstream` | **Missing** | `relibc/src/header/stdio/src.rs` | Low |
|
||||
| `signalfd`/`signalfd4` | **Implemented in-tree** | `relibc/src/header/signal/mod.rs` + `signal/signalfd.rs` | Runtime validation still needed |
|
||||
| `timerfd_create/settime/gettime` | **Implemented in-tree** | `relibc/src/header/sys_timerfd/` | Runtime validation still needed |
|
||||
| `eventfd`/`eventfd_read`/`eventfd_write` | **Implemented in-tree** | `relibc/src/header/sys_eventfd/` | Runtime validation still needed |
|
||||
| `F_DUPFD_CLOEXEC` | **Implemented in-tree** | `relibc/src/header/fcntl/mod.rs` | Verify against downstream consumers |
|
||||
| `MSG_CMSG_CLOEXEC` | **Implemented in-tree** | `relibc/src/header/sys_socket/mod.rs` | Verify against downstream consumers |
|
||||
| `MSG_NOSIGNAL` | **Implemented in-tree** | `relibc/src/header/sys_socket/mod.rs` | Verify against downstream consumers |
|
||||
| `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) |
|
||||
| DMA-BUF sharing | **Missing** | `redox-drm/src/dmabuf.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 | **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) |
|
||||
| udev shim | **Missing** | New: `recipes/wip/wayland/udev-shim/` | [03 §2](03-WAYLAND-ON-REDOX.md) |
|
||||
| libinput | **Missing** | `recipes/wip/wayland/libinput/` (NEW) | [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 | **Present in-tree** | `local/recipes/system/udev-shim/` | [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) |
|
||||
| KDE Frameworks | Not ported | [05 Phase KDE-B](05-KDE-PLASMA-ON-REDOX.md) |
|
||||
| KWin | Not ported | [05 Phase KDE-C](05-KDE-PLASMA-ON-REDOX.md) |
|
||||
| Plasma Shell | Not ported | [05 Phase KDE-C](05-KDE-PLASMA-ON-REDOX.md) |
|
||||
| Qt 6 | Ported in-tree | [05 Phase KDE-A](05-KDE-PLASMA-ON-REDOX.md) |
|
||||
| KDE Frameworks | Partially ported in-tree | [05 Phase KDE-B](05-KDE-PLASMA-ON-REDOX.md) |
|
||||
| KWin | Recipe exists, still incomplete | [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) |
|
||||
| `linux-kpi` C headers | Not started | [04 §3](04-LINUX-DRIVER-COMPAT.md) |
|
||||
| i915 C driver port | Not started | [04 §4](04-LINUX-DRIVER-COMPAT.md) |
|
||||
| amdgpu C driver port | Not started | [04 §5](04-LINUX-DRIVER-COMPAT.md) |
|
||||
| `redox-driver-sys` crate | Present in-tree | [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 as Linux C port | [04 §4](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)
|
||||
- Remove `redox.patch` from libwayland recipe
|
||||
- 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
|
||||
- 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
|
||||
to `relibc` (repo: https://gitlab.redox-os.org/redox-os/relibc).
|
||||
Historically these were the 7 APIs that `libwayland/redox.patch` worked around. They now exist
|
||||
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.)
|
||||
- [x] evdevd + libinput working
|
||||
- [x] DRM/KMS scheme working (at least Intel modesetting)
|
||||
- [x] Wayland compositor running (Smithay/smallvil)
|
||||
- [x] Mesa EGL + software OpenGL (already ported)
|
||||
- [~] 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 compiled, libevdev built, libinput 1.30.2 built (comprehensive redox.patch)
|
||||
- [x] DRM/KMS scheme daemon compiled (redox-drm: 15+ ioctls, AMD+Intel drivers)
|
||||
- [x] Wayland: libwayland + wayland-protocols built
|
||||
- [x] Mesa: OSMesa + LLVMpipe software rendering (EGL platform_redox.c exists, Orbital-only)
|
||||
- [x] 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.
|
||||
|
||||
|
||||
+6
-5
@@ -1,7 +1,8 @@
|
||||
# DOCS — ARCHITECTURE & INTEGRATION DOCUMENTATION
|
||||
|
||||
7 comprehensive technical documents covering Redox architecture, gap analysis, and integration paths.
|
||||
For AMD-first integration, see `local/docs/AMD-FIRST-INTEGRATION.md`.
|
||||
7 technical documents covering Redox architecture, gap analysis, and integration paths.
|
||||
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 |
|
||||
| How to fix POSIX gaps? | 03 | §1 (signalfd, timerfd, eventfd implementations) |
|
||||
| What's missing for Wayland? | 02 | Status correction + ordered remaining gaps |
|
||||
| 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)
|
||||
|
||||
+16
-8
@@ -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.
|
||||
libwayland patched with shimmed-out `signalfd`, `timerfd`, `eventfd`.
|
||||
- **X11**: Working via X.org dummy driver inside Orbital.
|
||||
- **Mesa**: Software-rendered only (LLVMpipe/OSMesa). No GPU acceleration.
|
||||
- **GPU drivers**: VESA framebuffer + VirtIO GPU only. Experimental Intel modesetting.
|
||||
- **KDE**: 19 app recipes in WIP, no KDE Plasma infrastructure.
|
||||
- **Linux driver compat**: None. Redox explicitly chose source-level porting over binary compat.
|
||||
- **Wayland**: libwayland + wayland-protocols built. Smallvil/cosmic-comp remain partial runtime experiments.
|
||||
- **Qt6**: qtbase 6.11.0 (Core+Gui+Widgets+DBus+Wayland), qtdeclarative, qtsvg, qtwayland ALL BUILT
|
||||
- **D-Bus**: 1.16.2 built for Redox. Qt6DBus enabled.
|
||||
- **KF6 Frameworks**: mixed state — many real builds, but some packages are still shimmed or stubbed.
|
||||
- **Mesa**: software-rendered path is present; full GBM / hardware-validated Wayland path is still incomplete.
|
||||
- **GPU drivers**: redox-drm scheme daemon and AMD+Intel compile-oriented paths exist; hardware validation is still pending.
|
||||
- **Input**: evdevd compiled, libevdev built, libinput 1.30.2 built
|
||||
- **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
|
||||
|
||||
|
||||
+12
-5
@@ -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,
|
||||
redbear-meta
|
||||
firmware-loader, redox-drm, cub, redbear-hwutils,
|
||||
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,
|
||||
evdevd, udev-shim
|
||||
└── [packages] redbear-release, redbear-hwutils, redbear-netctl,
|
||||
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.
|
||||
File diff suppressed because it is too large
Load Diff
@@ -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.
|
||||
Reference in New Issue
Block a user