vasilito/RedBear-OS
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
0b9745a43499a8260c42e0f8d760c0a3e2b3e730
RedBear-OS/local/docs/PROFILE-MATRIX.md
T
vasilito 10caab7085 boot: real Wayland compositor, Intel DRM Gen8-Gen12, kernel 4GB fix, virtio-gpu driver 
Comprehensive boot process improvement across the entire stack:

Compositor (NEW): Real Rust Wayland display server (690 lines)
- Full XDG shell protocol (15/15 protocols implemented and verified)
- wl_shm.format, xdg_wm_base, xdg_surface.get_toplevel support
- wl_buffer.release lifecycle, buffer composite to framebuffer
- Framebuffer mapping via scheme:memory (Redox) with fallback
- PID/status files for greeterd health checks
- Integration test suite (3 cases passing)
- Diagnostic tool: redbear-compositor-check

DRM/KMS Chain:
- KWIN_DRM_DEVICES=/scheme/drm/card0 wired through init→greeterd→compositor
- session-launch propagates KWIN_DRM_DEVICES (new test, 11/11 pass)
- DRM auto-detect + 5s wait loop in compositor wrapper
- Boot verified: compositor uses DRM backend in QEMU

Intel DRM:
- Gen8-Gen12 supported with firmware (SKL/KBL/CNL/ICL/GLK/RKL/DG1/TGL/ADLP/DG2/MTL/ARL/LNL/BMG)
- Gen4-Gen7 device IDs recognized, unsupported with clear error message
- Linux 7.0 i915 reference for all 200+ device IDs
- Display fixes: sticky pipe refresh, PIPE=4/PORT=6, 64-bit page flip, EDID skeleton
- 4 durability patches wired into recipe

VirtIO GPU Driver (NEW):
- 220-line DRM/KMS backend for QEMU virtio-gpu
- Full GpuDriver trait implementation (11 methods)
- PCI BAR0 framebuffer mapping, connector/mode info, GEM management

Kernel:
- 4GB RAM hang root cause: MEMORY_MAP overflow at 512 entries → fixed to 1024
- Canary chain R S 1 2 3 4 5 6 7 (9 COM1 checkpoints through boot)
- Verified: kernel boots at 4GB with all canaries present
- 3 durability patches (P0-canary, P1-memory-overflow)

Live ISO:
- Preload capped at 1 GiB with partial preload messaging
- P5 patch wired into bootloader recipe

Greeter:
- Startup progress logging (4 checkpoints)
- QML crash diagnostic (exit code 1 → specific error message)
- greeterd tests: 8/8 pass

Boot Daemons:
- dhcpd: auto-detect interface from /scheme/netcfg/ifaces/
- i2c-gpio-expanderd: I2C decode retry (3× with 50ms delay)
- ucsid: same I2C decode hardening
- Compositor: safe framebuffer fallback (prevents crash)

Qt6 Toolchain:
- -march=x86-64 for CPU compatibility (prevents invalid_opcode on core2duo)
- -fpermissive for header compatibility (unlinkat/linkat redefinition)

Documentation:
- BOOT-PROCESS-IMPROVEMENT-PLAN.md (comprehensive, 320 lines)
- PROFILE-MATRIX.md: ISO organization, RAM requirements, known issues
- BOOT-PROCESS-ASSESSMENT.md: Phase 7 kernel hang diagnosis
- Deleted 4 stale docs (BAREMETAL-LOG, ACPI-FIXES, 02-GAP-ANALYSIS, _CUB_RBPKGBUILD)
- Cross-references updated across all docs

KWin stubs replaced with real compositor delegation.
redbear-kde-session script created for post-login session launch.
30+ files, 10 patches, 3 binaries, 22 tests, 0 errors.
2026-04-28 06:18:37 +01:00

8.3 KiB
Raw Blame History

Red Bear OS Profile Matrix

Purpose

This matrix makes the tracked Red Bear profiles explicit so support claims map to a concrete build target instead of a vague feature list.

Validation Labels

  • builds — configuration and packages are expected to compile
  • boots — image is expected to reach a usable boot state
  • validated — behavior has been tested on the claimed profile
  • experimental — available for bring-up, but not support-promised

Subsystem plans may add narrower intermediate labels when boots is too coarse. In particular, the USB plan uses:

  • enumerates — runtime surfaces can discover controllers, ports, or descriptors
  • usable — a specific controller/class path works in a limited real scenario

Compile Targets

Phase numbering note: phase labels below use the v2.0 desktop plan phases from local/docs/CONSOLE-TO-KDE-DESKTOP-PLAN.md. Scripts and older docs may reference the historical P0–P6 hardware-enablement sequence — those are not the same numbering.

Profile Intent Key Fragments Current support language
redbear-mini Console + storage + wired-network baseline minimal.toml, redbear-legacy-base.toml, redbear-device-services.toml, redbear-netctl.toml builds / primary validation baseline / DHCP boot profile enabled / input-runtime substrate wired / USB: daemons built via base and targeted for bounded mini-profile validation
redbear-grub Text-only with GRUB boot manager redbear-mini.toml, redbear-grub-policy.toml builds / live media variant with GRUB chainload for real bare metal / desktop graphics intentionally absent
redbear-full Desktop/network/session plumbing target desktop.toml, redbear-legacy-base.toml, redbear-legacy-desktop.toml, redbear-device-services.toml, redbear-netctl.toml, redbear-greeter-services.toml builds / boots in QEMU / active desktop-capable compile target / support claims remain evidence-qualified

Build Artifacts (ISO Organization)

All profiles produce outputs under build/x86_64/. Each profile gets its own directory:

Profile ISO harddrive.img Image size QEMU RAM Boots via make qemu?
redbear-mini redbear-mini.iso redbear-mini/harddrive.img 1.5 GiB 2 GiB ✅ Text login
redbear-grub redbear-grub.iso redbear-grub/harddrive.img 1.5 GiB 2 GiB ✅ Text login
redbear-full redbear-full.iso redbear-full/harddrive.img 4.0 GiB 2 GiB ⚠️ Text login only

⚠️ CRITICAL: redbear-full requires exactly 2 GiB of guest RAM in QEMU. With 4 GiB or more, the kernel hangs silently during early SMP/memory initialization (x86_64 only). This is a confirmed kernel bug — see BOOT-PROCESS-ASSESSMENT.md Phase 7. The make qemu default of QEMU_MEM=2048 is correct for all profiles.

Known QEMU Issues

Issue Profiles affected Workaround
Kernel hang with ≥4 GiB RAM (nographic mode) redbear-full Use -m 2048 or less. make qemu default is 2048, safe.
Graphical login fallback — greeter uses text login, not Wayland redbear-full Set KWIN_DRM_DEVICES=/dev/dri/card0 in greeter env; verify redox-drm daemon is running
Live ISO preload — unable to allocate 4078 MiB upfront redbear-full Disable live mode (press l at bootloader); preload needs chunked allocation
EFI EDID unavailable — Failed to get EFI EDID warning All Expected in QEMU; not a project issue
AHCI DVD I/O error — empty DVD-ROM port probe All Benign; non-blocking

ISO naming convention

  • Profile ISOs: redbear-{profile}.iso (e.g. redbear-full.iso, redbear-mini.iso)
  • Legacy names (redbear-live-mini.iso, redbear-live-full.iso) are deprecated and should not be used in new scripts or documentation.
  • scripts/build-iso.sh accepts profile names: redbear-full, redbear-mini, redbear-grub.

Profile Notes

redbear-mini

  • First place to validate repository discipline and profile reproducibility.
  • Should stay smaller and less assumption-heavy than the graphics profiles.
  • Enables the shared wired-dhcp netctl profile by default for the VM/wired baseline.
  • Ships the shared firmware/input runtime service prerequisites so the early substrate can be tested on the smallest profile as well.

Historical and experimental overlays

  • Experimental overlays such as redbear-bluetooth-experimental and redbear-wifi-experimental are bounded validation slices layered on top of the tracked compile targets, not additional compile targets.

redbear-grub

  • Text-only console/recovery target with GRUB boot manager for multi-boot bare-metal workflows.
  • Inherits the same non-graphics intent as redbear-mini, but with GRUB chainload ESP layout.
  • Should not grow desktop/session assumptions.

redbear-full

  • Desktop-capable tracked target for the current Red Bear session/network/runtime plumbing surface.
  • Carries the broader D-Bus, greeter, seat, and desktop-oriented service surface.

Historical notes

  • Older names such as redbear-minimal, redbear-desktop, redbear-wayland, redbear-kde, redbear-live, redbear-live-mini, and redbear-live-full remain in older docs and some implementation details, but they are not the current supported compile-target surface.

redbear-bluetooth-experimental

  • Standalone tracked profile for the first in-tree Bluetooth slice instead of a blanket claim about all Red Bear images.
  • Extends redbear-mini so the baseline runtime tooling is already present, then adds only the bounded Bluetooth pieces on top.
  • Current path under active validation: QEMU/UEFI boot to login prompt plus guest-side redbear-bluetooth-battery-check, targeting repeated in-boot reruns, daemon-restart coverage, and one experimental battery-sensor Battery Level read-only workload.
  • Current support language is intentionally narrow: explicit-startup only, USB-attached transport, BLE-first CLI/scheme surface, one experimental battery-sensor Battery Level read-only workload, and no USB-class autospawn claim yet.

redbear-wifi-experimental

  • Standalone tracked profile for the current bounded Intel Wi-Fi slice instead of implying that the wider desktop profiles already carry the full driver stack.
  • Extends redbear-mini so the baseline firmware/input/reporting/profile-manager surface stays inherited while the Intel Wi-Fi driver package and bounded validation role remain isolated here.
  • Includes the Intel driver package (redbear-iwlwifi) in addition to the shared firmware, control-plane, reporting, and profile-manager pieces.
  • Current support language is intentionally narrow: bounded probe/prepare/init/activate/scan/ connect/disconnect lifecycle, packaged in-target validation and capture commands, and no claim yet of validated real AP association or end-to-end Wi-Fi connectivity.

Bluetooth Note

  • redbear-bluetooth-experimental is now the tracked first Bluetooth-specific profile.
  • Its support language remains experimental and bounded; it should not be used to imply Bluetooth support across the wider Red Bear profile set.
  • The current bounded BLE workload is one read-only battery-sensor Battery Level interaction; this profile still does not claim generic GATT, write, or notify support.
  • The current validation claim is QEMU-scoped and packaged-checker-scoped, not a blanket claim about real hardware Bluetooth maturity.

USB Note

  • redbear-mini is the preferred non-graphics target for bounded USB validation because these proofs do not require the full desktop graphics/session surface.
  • USB validation is QEMU-only (test-usb-qemu.sh --check). No profile makes a real hardware USB support claim.
  • USB error handling and correctness carry significant Red Bear patches over upstream; see local/patches/base/redox.patch and local/docs/USB-IMPLEMENTATION-PLAN.md for details.
  • The in-tree mini image is still assembled through legacy redbear-minimal* config files in some places, but the supported compile-target names are redbear-mini and redbear-grub.
  • redbear-bluetooth-experimental uses USB only as a transport for BLE dongles; it does not make a general USB-class-autospawn claim.
Reference in New Issue View Git Blame Copy Permalink