illumos has /dev/fb0 via the gfxp_bitmap driver on UEFI GOP systems,
exposing the classic SunOS fbio(4I) interface. Userspace can mmap the
framebuffer and write pixels directly -- proven by xf86-video-illumosfb.
New four-tier architecture:
- Tier 0: Bare-metal /dev/fb0 (illumos fbio + Linux fbdev). No X11.
- Tier 1: X11 SHM (portable fallback, also dev mode)
- Tier 2: Loopback shared memory (co-located optimization)
- Tier 3: DRM/KMS (Linux, rare illumos)
Includes implementation sketch with SIMD non-temporal stores for
write-combining memory (SSE2/AVX2/AVX-512 runtime selection).
WayRay must work as a local desktop compositor, not just remote.
Three-tier approach:
- Tier 1: Custom X11 SHM backend (PixmanRenderer + XShmPutImage).
Works on any illumos system with X11, even VESA-only GPUs.
- Tier 2: Loopback optimization for co-located server+client,
shared memory buffer ring skipping encode/decode entirely.
- Tier 3: DRM/KMS backend for Linux or accelerated illumos GPUs.
Same compositor core, different output backend. Validated by
cocoa-way (Smithay on macOS) using the same headless+present pattern.
WayRay is a compositor, not a DE or login system. GNOME/KDE cannot
run on WayRay (they ARE compositors). The desktop is composed from
independent Wayland clients (pluggable WM + panel + launcher + apps).
- ADR-010: Greeter as Wayland client, external session launcher
handles PAM/user env (like greetd for Sway)
- Clarify scope: WayRay owns compositor session + token binding,
not user auth, home dirs, or environment setup
- Update roadmap with greeter phase and session.toml config
- Update architecture overview with scope boundary section
