Remote support
Request one display and only the input capabilities needed for the task. The host reviews the request before the session starts.
Product workflows
One connection model, with the platform boundaries left intact.
RealLexi Connect is being built as a coherent remote-display system—not a collection of buttons that imply unsupported operating-system access.
Work that starts with an exact request
Second-screen workflows
Assign a supported virtual display to a phone, tablet, desktop viewer, or browser without claiming a browser can create the monitor.
Multi-monitor viewing
Select, switch, fit, scale, or arrange authorized displays. Capabilities remain feature-detected per host platform.
Quality that explains itself
Choose data saver, balanced, office/text, smooth, or low-latency intent while live stats report the measured result.
Separate data grants
Audio, clipboard directions, files, touch, pen, keyboard, pointer, monitor switching, and local recording remain distinct permissions.
Redacted diagnostics
Inspect connection path, resolution, frame rate, bitrate, latency, jitter, and loss without placing screen or input content in service logs.
Architecture at a glance
Authorization travels through the service. Session content does not.
The host remains a visible participant—not a passive resource. Permission changes and termination stay part of the live connection.
All 19 requested product categories
A label for every promise.
These are engineering states, not purchase availability. “Development” may mean a tested foundation while the complete customer workflow remains unavailable. No broad category currently meets a production-ready “Implemented” gate.
Implemented complete and verified for the stated scopeDevelopment code or evidence exists, end-to-end gate openPlanned designed or scheduled, implementation evidence absentBlocked depends on an unresolved platform, signing, hardware, or external gate
| # | Product category | Engineering state | Evidence and open gate | Proposed plan placement |
|---|---|---|---|---|
| 1 | Remote desktop viewing | Development | Windows captured one real frame in memory and the browser lab carries a real local MediaStream; a cross-device native session is not yet proven. | Core plan proposal |
| 2 | Mouse, keyboard, touch, pen, and supported game-controller input | Development | Bounded control messages and a Windows input allowlist have tests. Live device injection, touch, pen, and controller matrices remain open. | Pointer/keyboard core; touch on Gold; pen/game controller in Media and Input Pack |
| 3 | Network screen mirroring | Development | Capture, WebRTC, and session foundations exist separately; real two-device network mirroring has not passed. | Core plan proposal |
| 4 | Additional or virtual displays | Blocked | The Windows Indirect Display Driver, certificate, Secure Boot, installer, and hardware test gates are not complete. | Display Studio Pack proposal |
| 5 | Multi-monitor selection and switching | Development | Two displays were enumerated on a Windows development host; independent capture, switching, and topology-change tests remain. | Core plan proposal |
| 6 | Phone or tablet as an additional Windows display | Blocked | Depends on the unsigned virtual-display path plus mobile viewer builds and physical-device tests. | Display Studio Pack proposal |
| 7 | Desktop controlled from a phone or tablet | Planned | Mobile viewer/controller applications and platform input behavior are not implemented or device-tested. | Core view/pointer/keyboard proposal; advanced input remains separately entitled |
| 8 | Desktop-to-desktop remote support | Development | Account, device, session-ticket, signaling, capture, and input foundations exist; the complete native end-to-end slice is not proven. | Core plan proposal |
| 9 | Browser-based viewer | Development | A user-click display capture crosses a real same-browser RTCPeerConnection pair. Remote signaling, relay, and native-companion integration remain. | Core plan proposal |
| 10 | LAN, Wi-Fi, hotspot, Wi-Fi Direct, Ethernet, Internet, USB tethering, and USB-to-Ethernet paths | Planned | The design reuses authenticated WebRTC over OS-exposed IP links. The required device, adapter, and network matrix has not run. | Core direct connectivity proposal; relay usage is metered separately |
| 11 | NAT traversal and secure relay | Development | Signaling and hardened TURN deployment configuration exist, but production TURN credentials, restrictive-NAT tests, abuse controls, and regional operations are unverified. | Fair-use relay in every plan; Relay Boost add-on |
| 12 | Clipboard synchronization with explicit permissions | Development | Direction, permission, size, type, digest, and replay validation exist in protocol code; an endpoint-to-endpoint customer flow does not. | Collaboration Pack proposal |
| 13 | End-to-end file transfer with explicit acceptance | Development | A bounded file-transfer contract exists; endpoint transfer, acceptance UI, resume, path-safety, and cross-platform tests remain. | Collaboration Pack proposal |
| 14 | Optional system audio, microphone, chat, and local session recording | Planned | Consent and data-boundary requirements are documented, but complete endpoint media/chat/recording implementations are not present. | Audio/microphone in Media and Input Pack; chat/recording in Collaboration Pack |
| 15 | Video-wall layouts | Planned | Layout, synchronization, decode-capacity, multi-viewer, and hardware evidence are absent; separate streams will not be called synchronized. | Display Studio Pack proposal, up to 9 proposed tiles |
| 16 | Owner-enabled trusted or unattended access | Development | Device-bound trust and ticket rules have control-plane coverage; host persistence, start notice, revocation, step-up, and recovery need end-to-end proof. | Organization proposal or Trusted Access Pack |
| 17 | Account, device, subscription, plan, checkout, and administration systems | Development | Development auth, device, entitlement, billing-webhook, and backup paths exist. Live checkout, reconciliation, quota enforcement, and production administration remain unavailable. | Account foundation for all plans; organization controls in Organization |
| 18 | Chrome/Edge and VS Code extensions with a safe native local agent | Development | Least-privilege extension packages and authenticated local-channel designs exist; the signed native companion and store publication are absent. | Core plan proposal |
| 19 | Signed installers, secure updates, uninstallers, documentation, deployment, backups, monitoring, and incident response | Development | Documentation, deployment-only Pages automation, backup/monitoring/incident procedures, package gates, and update verification foundations exist. Signed multi-platform release evidence does not. | Release and operations baseline; Priority Support is separately proposed |
Browser or native?
The browser is a capable viewer, not a hidden system agent.
Browser sharing uses getDisplayMedia only after local action. System-wide input, virtual monitors, host enrollment, and trusted access require a disclosed native companion using documented platform APIs.
Designed for interruption
Keep the display visible while temporarily rejecting remote pointer and keyboard events.
Remove keyboard without ending view, or disable clipboard without changing pointer access.
The host keeps a persistent indicator, stop control, and emergency disconnect path.