Initialize WinitGraphicsBackend with GlesRenderer, create a virtual
Output matching the window size, set up a Wayland listening socket via
ListeningSocketSource, and run the main event loop through calloop with
WinitEventLoop as an event source. The compositor now opens a window
and accepts Wayland client connections.
Move handler trait impls and delegate macros from state.rs into
handlers/{compositor,xdg_shell,input,output}.rs. Flesh out
CompositorHandler::commit with on_commit_buffer_handler and
XdgShellHandler::new_toplevel with window mapping. Add DataDeviceHandler,
SelectionHandler, ClientDndGrabHandler, and ServerDndGrabHandler impls
with DataDeviceState in the WayRay struct. State.rs now contains only
the struct definition and constructor.
Define the central WayRay state struct holding all Smithay subsystem
states (compositor, xdg_shell, shm, seat, output, space, clock) and
wire Display creation into main.rs. Includes minimal handler trait
impls and delegate macros needed to compile; these will be expanded
and moved to a handlers module in Task 4.
Long-form article for the project website covering SunRay history,
why it mattered, what went wrong, and how WayRay modernizes every
aspect: QUIC transport, content-adaptive encoding, smartphone
proximity tokens, pluggable window management, federation, protocol
gateways, and illumos as primary platform.
When at a friend's or customer's site, the client connects directly
to the user's own server over the internet -- no local server involved,
no federation needed. The thin client is just a screen + network.
- ADR-014: Add scenarios 4b/4c (friend's house, BYOD on-site),
server selection UI, three-category taxonomy (direct remote,
federation, sandboxing)
- ADR-013: BLE beacon payload now includes server address so the
phone tells any terminal where to find the user's desktop
Unified mechanism for two related problems:
- Federation: windows from remote WayRay servers appear in local
desktop (B2B invites, cross-org app sharing, visiting consultants)
- Sandboxing: windows from isolated local environments (illumos zones,
containers) appear alongside trusted local windows
Three display modes:
- Desktop-in-desktop (full remote session in a window)
- Merged windows (seamless per-window integration with local WM)
- App embedding (future: subsurface portal)
Trust-level visual indicators (Local/Trusted/Sandboxed/Untrusted),
input isolation per trust level, B2B invite flow, server-to-server
mutual TLS federation, and OIDC-based dynamic trust chains.
Same ForeignWindow protocol for both remote (QUIC) and local (Unix
socket) sources. illumos zones as natural sandboxing primitive.
Add wireless charging pad mode -- phone on Qi pad acts as smart card
in a reader slot. NFC provides crisp insert/remove semantics without
RSSI ambiguity. Combined NFC+BLE mode for heartbeat during brief
NFC interrupts. Configurable per-deployment: centimeter range (pad)
vs meter range (pocket) vs combined.
Phone acts as wireless smart card -- walk up to terminal, session
appears; walk away, session suspends. No insertion, works from pocket.
- BLE beacon with encrypted rotating session token
- RSSI-based proximity detection with configurable thresholds
- Anti-flapping timers: T_attach (2s) and T_detach (10s)
- Security: HMAC timestamps, token rotation, optional NFC tap
- Companion app (Android/iOS): one-time OIDC setup, background BLE
- Implements same TokenProvider trait as smart cards (ADR-004)
- NFC as explicit complement, WiFi/mDNS as software fallback
The greeter bridges cloud identity to local user context:
- Device Authorization Grant (RFC 8628) as recommended flow
for thin clients (QR code, no browser needed on server)
- Authorization Code with PKCE as alternative
- Claims-to-user mapping (IdP sub/email/groups -> local uid/gids)
- Auto-provisioning on first login (useradd, ZFS home dataset)
- Pluggable auth architecture (local, OIDC, smart card, Kerberos)
- Ephemeral pre-auth session for greeter display
- Session launcher interface unchanged regardless of auth method
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
