GAMEPAD TESTER — THE MACHINE READS YOUR CONTROLLER

No driver, no install, no magic: this page calls navigator.getGamepads(), a standard browser API, and then calls it again every single frame. The Gamepad API has no “button pressed” event — the spec only fires events when a pad connects or disconnects. Everything else is polling: the page asks the browser for a fresh snapshot of every button and axis, draws it, and asks again on the next requestAnimationFrame. That is why the readout above updates at your display’s refresh rate, and why the values are raw — each button reports a float from 0.0 to 1.0 (so analog triggers show pressure, not just on/off), and each stick axis reports −1 to +1.

The press-a-button ritual is deliberate, not a bug. Browsers refuse to reveal connected controllers until one of them produces input on the page, because a list of your attached hardware is a fingerprinting goldmine — sites could quietly identify you by your peripherals. So the API stays dark until you, the human, opt in with a press. Most modern pads also advertise the spec’s “standard” mapping — button 0 is the bottom face button, axes 0 and 1 are the left stick — which is how one page reads an Xbox pad and a DualSense identically.

Let the controller sit untouched and watch the axis readout. A healthy stick rests near 0.00 on both axes — a flicker of ±0.05 is electrical noise, normal, and exactly what game deadzones exist to swallow. A stick that rests at 0.15 and stays there has drift. A stick that snaps back to 0.08 after release instead of 0.00 has the early form of the same disease.

The cause is mechanical. Most analog sticks are potentiometers — a wiper dragging across a resistive track, thousands of sweeps per session. The track wears, debris accumulates, the spring fatigues, and the resting voltage shifts. No software truly fixes that. Games hide mild cases behind a deadzone — a radius around center where input is ignored — but a deadzone wide enough to hide bad drift also eats your fine aim. I show raw values precisely because games won’t.

Rules of thumb: a resting offset under roughly 0.10 gets absorbed by any sane deadzone; persistently above 0.20, the hardware is going. Compressed air around the stick base sometimes buys time, stick modules can be replaced by anyone comfortable with a soldering iron, or you retire the pad. Hall-effect sticks — a magnet and a sensor, no contact, nothing to grind down — from the likes of GuliKit and 8BitDo’s newer pads exist specifically because of this failure mode.

Those two acronyms on your pad’s mode switch are two generations of Windows input. DirectInput is the older, looser API from the DirectX era; XInput arrived with the Xbox 360 controller in 2005 and fixed the layout — two sticks, two analog triggers, ABXY — that PC games have assumed ever since. Many third-party pads can impersonate either, and in the wrong mode a pad may enumerate with scrambled buttons or not at all. In a browser it matters less than you’d think, since the Gamepad API normalizes both into its standard mapping — but if I show your triggers as plain buttons, or show nothing, flip the switch and reconnect.

Pairing, by brand, with no folklore. Xbox One and Series pads have a small pair button up top near the USB port — hold it until the logo flashes fast; the older 360 wireless pads never spoke Bluetooth at all and need their proprietary USB receiver. DualSense / DualShock 4: hold Create (or Share) together with the PS button until the light pulses. Switch Pro: a tiny sync button beside the USB-C port. 8BitDo: these boot into different modes depending on which face button you hold at power-on, and the combos differ per model — check the quick-start card, then hold the pair button. On every brand, a pad still bonded to a console in the same room will happily reconnect to it instead of your computer.

Every press travels a chain: controller → radio or cable → OS driver → browser → page. Each link costs milliseconds. Bluetooth costs more than a cable and varies with interference, which is why the boring advice — plug it in — is also the correct advice. Then the browser samples the Gamepad API once per displayed frame: at 60Hz that is a fresh reading every 16.7ms, so a press can wait most of a frame just to be noticed. A higher-refresh display genuinely shrinks that wait.

For emulation in THE CABINET, add the emulator’s own frame: it reads your input, simulates the console for one frame, then the browser composites the result for your display. Before calling that decadent, remember the originals worked the same way — an NES game typically read its controller’s shift register once per frame. The realistic overhead of browser play is a couple of frames over original hardware: real, measurable, and irrelevant for almost everything short of the meanest reflex tests. So use this page as your control group. If a press lights up the readout above instantly but the game feels mushy, the pad is innocent — close the forty background tabs starving the browser of frame time. I see them. Metaphorically.