Private project · sanitized public case study
GameQ: a governed multi-seat gaming runtime, built from one shared machine.
GameQ is a self-hosted, multi-seat interactive gaming runtime. It turns supported clients — a tablet, a TV, a laptop — into independent gaming endpoints backed by one centrally managed machine, with each seat's input, audio, and workload lifecycle governed and isolated from the others.
Problem
Running more than one independent gaming session from one machine is harder than it looks.
A single machine with one GPU can technically run several game-streaming sessions at once, but naively sharing it creates real hazards: one session's keyboard can leak into another's, one player's controller can end up driving someone else's game, audio can silently route to the wrong session after a reconnect, and a routine restart of the streaming service can leave a session's input permanently broken until someone notices and intervenes by hand. GameQ was built to make each session — called a Seat — a genuinely independent, self-recovering unit on top of one shared host, rather than a fragile improvisation.
Architecture · what a Seat is
A Seat is a durable, isolated resource boundary — not just a container.
A Seat is the object GameQ actually governs: a container running its own display, audio server, and input view, paired with explicit admission rules for which devices are allowed into it and when. Node names, container IDs, and device numbers are all treated as transient — ownership is tracked by durable identity, never inferred from a path or a number that the kernel can reuse. Two Seats are proven running concurrently today, on one shared NVIDIA GPU, with independent lifecycles end to end.
Workload / runtime model
Two governed launch families, one normalized lifecycle.
Every workload — an emulator system or a Steam/Proton title — launches through one of two governed chains, reaches real gameplay, and exits back to the library view cleanly, through the same lifecycle regardless of family. Steam identity (which player's save/profile data is mounted) is kept separate from Steam's own entitlement and runtime capability, so switching whose library a Seat uses is a mount change, not a code or credential change. Normalized emulator families and Steam/Proton titles are both proven launching, running, saving, and exiting cleanly through this same path.
Input isolation
Nothing is exposed to a Seat until GameQ explicitly admits it.
Each Seat gets a private input device view, default-deny: a device only becomes visible inside a Seat after GameQ has attributed it to that Seat and explicitly admitted it into an active session window. The host's own physical admin keyboard/mouse is proven to never leak into any Seat — isolation confirmed by construction and by direct live testing. A remote player's keyboard and mouse are treated as durable Seat infrastructure (created once by the streaming process and meant to persist), while touch, pen, and controller input are treated as per-connection — each class has its own observed, proven lifecycle, and the two are never conflated.
- Private, per-Seat input view — proven, zero cross-seat leakage.
- Host admin keyboard/mouse isolation — proven, zero leakage into any Seat.
- Canonical remote keyboard/mouse treated as Seat infrastructure — proven.
- Controller reconnect/re-arm across repeated disconnect cycles — proven.
Audio isolation
Each Seat gets its own audio path — classified by what created the sound, not its name.
Each Seat has its own canonical audio sink. A seat-local invariant enforcer watches for the specific way the streaming layer can silently reroute a workload's audio onto the wrong internal device after a reconnect, and corrects it automatically. It identifies "this is a GameQ workload's audio" by which governed process tree produced it, not by application name — so it generalizes to new emulator workloads without new code for each one. Two-seat simultaneous audio, heterogeneous clients, and independent per-seat reconnects are all proven.
Disclosed limitation: this same reconnect-safety protection does not yet cover Steam/Proton titles — a different launch path within the same engine makes the audio-ownership signal this mechanism relies on unavailable for that family today. Investigated directly and documented rather than worked around with a forced, unproven fix.
Client / stream lifecycle
Real streaming clients, proven driving real input.
GameQ's remote-access layer is built on an open-source game-streaming server and client protocol. Real clients — a tablet and a desktop streaming client — are proven connecting, disconnecting, and reconnecting across repeated cycles, with the remote session's keyboard and mouse surviving a client disconnect and continuing to work for whichever client reconnects next.
Automatic recovery
The streaming service can restart without a human reprovisioning anything by hand.
The hardest-won result in this project: the streaming service occasionally needs to restart (a crash, an update, an operator action), and a restart recreates that Seat's virtual keyboard and mouse from scratch. Early in the project, recovering from this required a manual, multi-step provisioning sequence — a real product-blocking gap. GameQ now detects the restart, reconciles the stale device state, and re-admits the fresh devices automatically, with no manual command of any kind.
The remaining defect behind that gap was root-caused directly against the exact installed display-server input library's own source: a removed virtual input device's file handle could still be held open by the display server or the host's own session manager well after the device itself was gone — regardless of the normal removal notification already firing correctly. Several narrower fixes were tried and rejected first — disabling the device through the display server's own control tool, re-sending the removal notification, triggering a lower-level device rescan, restarting the smaller of the two processes holding it open — each either failed outright or only partly worked. The fix that actually closed the gap touches neither the display server nor the session manager at all: GameQ releases its own internal mount ownership of the stale device, which frees the path for a fresh device without ever reaching into another process's state.
- 15 of 15 consecutive hands-off streaming-service restarts recovered automatically, no manual step of any kind.
- A real streaming client, carried through a live restart, confirmed its keyboard and mouse worked again after reconnecting.
- The fix never stops, restarts, or signals the display server or the session manager — it only releases GameQ's own resource.
Multi-seat proof
Two independent seats, one shared GPU, zero cross-contamination.
Both seats are proven running concurrently on the same physical host and GPU — one running a Steam/Proton title, the other an independently running emulator session — with separate process namespaces, separate audio servers, and low, headroom-rich GPU utilization for both workloads together. Isolation is proven in both directions: restarting one seat's streaming service never touches the other seat's input, audio, or running game. This is a functional-concurrency proof, deliberately not presented as a maximum-capacity benchmark.
Appliance 0.1 direction
The product direction: turn this engineering baseline into a reproducible appliance.
The working name for that direction is Appliance 0.1: take what is already proven here and package it as something a non-developer could use without ever seeing a terminal. That framing exists today as a product contract with an honest, dated blocker list — not as a shipped product.
Current limitations
What GameQ does not claim.
- GameQ's source repository is private; this page is a sanitized public case study of a real, running system.
- No public, reproducible build/provisioning path exists yet — today's two seats were hand-built and hand-evolved, not provisioned from a blank machine.
- There is no polished, consumer-presented library/menu interface yet — today's library browsing surface is an existing open-source emulator frontend, running in an operator-grade presentation.
- An actively running game is currently restarted, not preserved, when the streaming service restarts — a separate, newly-identified lifecycle question, tracked but not yet solved. The streaming-connection lifecycle and the running-game lifecycle are coupled by a straightforward service dependency today and are expected to be evaluated as two separate concerns in a future pass.
- Steam/Proton audio does not yet have the same reconnect-safety protection emulator workloads already have (see Audio isolation above).
- First-time client pairing uses the streaming server's own pairing flow directly; no GameQ-specific onboarding wraps it yet.
- Multi-seat proof is functional concurrency on one shared GPU, not a maximum-capacity benchmark.
What this demonstrates
Systems engineering under real constraints, with the proof to back it.
Source-level root-causing
Diagnosed a hard, intermittent production defect by reading the exact installed system library's own source rather than guessing from symptoms.
Disciplined fix selection
Tested and rejected narrower fixes in order of increasing disruption before committing to the one that never touches another process's state.
Isolation and identity modeling
Built durable ownership tracking (Seats, device identity, admission windows) specifically so the kernel reusing a number or a name could never be mistaken for continuity.
Evidence discipline
Every claim above is backed by a live, repeatable, numbered proof — including the limitations, stated as plainly as the successes.
Product framing
Carries a real engineering baseline through to a named, dated product contract with an honest blocker list, not just a demo.
Linux/platform depth
Containers, mount namespaces, device/udev lifecycle, systemd service dependencies, and GPU sharing, all reasoned about directly rather than through a framework.