Advanced Browser Gamepad Diagnostics: Signals and Limits
The tester can preserve useful browser evidence only when its data path, confidence, and limitations stay visible. This guide explains the implemented pipeline without presenting browser snapshots as raw electrical measurements.
Measurement boundary
Gamepad Test App is a browser diagnostic aid. It does not read analog voltage, prove sensor bit depth, authenticate a physical controller, inspect internal contacts, or measure end-to-end latency.
1. The browser input path
The tester reads normalized snapshots from the Web Gamepad API. The operating system, controller driver, browser, connection, firmware, and any remapping layer can all affect the descriptor, axis order, button count, timestamps, and values that reach the page.
A standard mapping is used only when the browser reports one. Other layouts require a user-confirmed semantic input profile. Missing controls remain unavailable; they are not silently guessed or scored as failures.
2. Sessions, samples, and confidence
Each connection generation owns one session. A disconnect, slot replacement, selected-controller change, or incompatible profile change interrupts dependent work so evidence cannot move between physical controllers.
Visualization and diagnostics share one timestamped sample stream. Only timestamp-advanced reports count as evidence. Hidden-page time, long stalls, movement during a hands-off check, too few unique reports, or missing required actions reduce confidence or return an incomplete result.
3. Browser cadence is not latency
Observed update cadence is estimated from unique Gamepad timestamps. Browser delivery cadence describes how often the page sampled. Interval variation describes spread between observed updates. These values are useful for repeated comparisons in the same environment.
None of these values directly measures USB polling rate, controller-to-screen latency, game-engine delay, or electrical packet timing. Exact latency work requires a purpose-built native tool or hardware capture.
4. Results, health, and reports
Evaluators return structured evidence with pass, fail, warning, incomplete, interrupted, or unavailable semantics. Health remains pending until enough eligible evidence exists and the available core checks are complete. Unsupported and incomplete checks cannot improve the score.
Finishing a diagnostic freezes one immutable snapshot. JSON, text, CSV, final PNG, and saved history render that snapshot rather than mixing later live input into an older report.
Experimental Sony WebHID
The optional WebHID subsystem supports known DualSense and DualShock 4 report layouts for output commands and coarse battery status. A device must be explicitly permitted and associated with the active Gamepad session. Commands are serialized through one output state and stopped on reset, disconnect, or unmount. WebHID input does not feed diagnostic evaluators, health, authenticity, cadence, or stick analysis.
Common questions
Does WebHID provide more accurate input to this tester?
No. Diagnostic input comes from Gamepad API snapshots. Experimental WebHID support is limited to known Sony output and model-specific battery-status layouts after explicit permission and association.
Does the displayed Hz equal controller polling rate?
No. It is a browser-observed estimate from Gamepad timestamps and can be affected by the operating system, browser, focus, scheduling, firmware, and connection.
Can the health score prove a hardware fault?
No. It summarizes eligible browser-observed evidence for one session. Findings begin with repeat tests and reversible checks, and low-confidence evidence cannot create a repair verdict.
What happens when a controller disconnects?
The active run is interrupted and output is stopped. A reconnect creates a new connection-generation session. Previously finalized or saved history remains separate.