Replace ControlFlow::Poll (CPU-hungry busy loop) with an
EventLoopProxy that the network thread uses to wake the winit
event loop only when a new frame arrives. Zero CPU when idle,
instant wake on new frames.
The winit event loop defaulted to Wait mode, only processing frames
when user input arrived. Switch to Poll so the loop continuously
checks for new frames from the network thread.
- Keycodes: add +8 offset for XKB (evdev scancode + 8 = XKB keycode)
- Client: force exit on Cmd+Q/close (network thread may block)
- Server: force exit on Ctrl+C (network thread may block on accept)
Proper graceful shutdown with tokio CancellationToken deferred.
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.
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.
