Architecture

Overview

Virtual Gamepad is split into two independently maintained pieces:

• Desktop companion — a native app for Windows and Linux that listens for connections on the local network and injects input at the OS level.
• Android client — the app that renders the on-screen controller and streams touch input to the desktop companion.

Discovery

The desktop companion advertises itself on the local network so the phone app can find it without the user typing an IP address. If discovery fails (common on networks with client isolation enabled), the phone app also supports connecting directly by IP.

Input pipeline

1. The phone app captures a touch event (button press, stick movement).
2. It's serialized into a compact binary message and sent over the local network to the desktop companion.
3. The desktop companion translates that message into a native input event: Windows.Gaming.Input on Windows, uinput/libevdev on Linux.
4. The OS — and therefore any game or application — sees a standard virtual controller, indistinguishable from physical hardware.

Why no cloud relay

Routing input through a cloud server would add latency, introduce a dependency on a third party's uptime, and require collecting network traffic that's arguably the definition of sensitive (everything you do in a game). Keeping the connection local-only avoids all three problems at once.

Contributing to the architecture

Both the desktop companion and the Android client are open source. See the repository's CONTRIBUTING.md for build instructions and how the codebase is organized before submitting a pull request.