Root cause: Window::bbox() stayed at 0x0 because Window::on_commit()
was never called after surface commits. The Space then never associated
the window with the output (no overlap), so render_elements_for_output
returned empty.
Two fixes:
- Call window.on_commit() in CompositorHandler::commit() to update
the window's bounding box from the committed surface tree
- Call space.refresh() each frame to update output-element mappings
Also: send xdg_toplevel configure with suggested 800x600 size.
renderer_gl and backend_winit pulled in backend_egl, which changed the
ImportAll blanket impl to require ImportEgl — a trait PixmanRenderer
doesn't implement. This caused render_output to silently skip client
surface compositing (only the clear color rendered).
Fix: move renderer_gl and backend_winit behind a "winit" cargo feature.
Default build uses only renderer_pixman, which satisfies ImportAll via
the simpler ImportMemWl + ImportDmaWl blanket impl.
Winit backend: cargo build -p wrsrvd --features winit
Headless (default): cargo build -p wrsrvd
ExportMem::copy_framebuffer may not capture composited client surfaces.
Read pixels directly from the pixman Image's CPU memory after rendering,
since PixmanRenderer composites in-place. This should fix missing
client windows in the remote display.
Server (PixmanRenderer) outputs ARGB8888, client GPU texture expects
BGRA8. Added byte-order conversion in update_frame(). Also changed
texture format from Bgra8UnormSrgb to Bgra8Unorm for correct colors.
Start QUIC server in wrsrvd main.rs before dispatching to backend,
passing NetworkHandle to the headless backend. The headless render loop
now encodes each frame as XOR diff against the previous frame, compresses
damage regions with zstd, and sends FrameUpdate messages to connected
clients via the network channel.
Network input from remote clients is drained each iteration of the main
event loop and injected into the compositor via inject_network_input().
Connection state (client connected/disconnected) is tracked to avoid
encoding frames when no client is listening.
Implement client-side input capture (input.rs) that converts winit
WindowEvents to protocol InputMessages: keyboard via evdev keycode
mapping, pointer motion/buttons/axis. Wire into wrclient main.rs
event handler to send input over QUIC via the existing input channel.
Server-side: add inject_network_input() to WayRay state that accepts
protocol InputMessages and injects them into the Smithay seat, following
the same patterns as process_input_event for keyboard, pointer motion
with surface focus, click-to-focus, and axis scroll.
Also upgrade client frame handling to use persistent framebuffer with
XOR-diff decoding via wayray_protocol::encoding::apply_region.
Implement QUIC networking for wrsrvd (server) and wrclient (client) using
quinn over rustls with self-signed certificates. Three logical channels:
control (bidirectional), display (server->client unidirectional), and
input (client->server unidirectional).
Server runs tokio in a background thread, communicating with the compositor
via std::sync::mpsc channels. Client exposes an async connect() API that
returns a ServerConnection with methods for sending input and receiving
frames.
Key design note: quinn streams are lazily materialized -- accept_bi/
accept_uni on the peer won't resolve until data is written. The handshake
protocol accounts for this by having each side write immediately after
opening streams.
Restructure wrsrvd to support two backends: a headless PixmanRenderer
(default) for running without a display server, and the existing Winit
backend (via --backend winit). The render logic is split into per-backend
modules, and the old render.rs is removed.
Encoder: xor_diff + encode_region (per damage rectangle).
Decoder: apply_region (decompress + XOR apply to framebuffer).
Both live in wayray-protocol::encoding for shared access.
14 tests including 3 end-to-end round-trip integration tests.
Message types for control, display, and input channels with serde
derives. Length-prefixed postcard codec with encode/decode/framing.
Seven round-trip tests covering all message types and edge cases.
Arch ARM tooling has limited support on UTM/Apple Silicon.
Ubuntu 22.04 gallery image works out of the box.
- setup.sh: apt-get packages, Ubuntu paths (/sbin/agetty, .profile)
- README.md: UTM gallery workflow instead of manual ISO install
- Default repo URL: github.com/CloudNebulaProject/wayray
- Remove CapturedFrame struct and last_capture field (no consumer yet)
- Remove display_handle field (re-obtainable when needed)
- Prefix output_manager_state and xdg_decoration_state with _ (kept
alive for Wayland globals but not directly read)
- Keep framebuffer capture logging to verify ExportMem path works
- Change Transform::Flipped180 to Transform::Normal for virtual output
- Add TODO comment on resize handler for future output mode update
- Rename misleading JsonPointer* import aliases to *Trait
- Add PrimarySelectionState and delegate: terminals like foot expect
the primary selection protocol to be present
- Add XdgDecorationState and delegate: allows clients to negotiate
server-side vs client-side window decorations
- Send initial configure for popups so menus and tooltips render
- Flatten nested if-let chains in commit handler (clippy)
- Include framebuffer capture in render pipeline (from prior task):
copies rendered frame via ExportMem for future network transport
Initialize keyboard and pointer on the Wayland seat at startup, and
route Winit input events (keyboard, pointer motion, button, scroll)
through process_input_event to the Smithay seat so clients can receive
input. Click-to-focus raises the clicked window and sets keyboard focus.
- Create render module using Smithay's desktop::space::render_output
for damage-tracked frame rendering to the Winit backend window
- Store backend and damage_tracker in CalloopData so the Winit event
callback can trigger rendering on Redraw events
- Send initial xdg toplevel configure on first commit so clients can
begin drawing
- Send frame callbacks after each render so clients schedule redraws
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