Your controller is not working even though it is connected because "connected" only means the device negotiated a link, not that input is reaching the game. A controller passes through six stages, pairing, transport, driver recognition, input mapping, game focus, and power state, and failure at any one stage produces the same symptom: a light comes on, nothing moves. The most common culprits are a stale input profile, a game that ignores the device, or a power or firmware fault, not a dead radio.
This guide walks the full chain stage by stage. It gives you measured numbers where they are stable, plus a diagnostic order that finds the broken link in minutes instead of swapping hardware.
What "Connected" Actually Confirms
A connection confirmation is weaker evidence than it looks. When a wireless controller pairs, the host and device exchange identities and agree on a radio channel. That handshake verifies the radio link and the basic protocol, nothing else. It does not verify that the operating system exposes the device as an input endpoint, that the game polls that endpoint, or that the mapping layer turns raw reports into movement.
The Six-Stage Signal Chain, and Why Each Stage Fails
Every input travels the same path, and each stage has its own failure mode. The physical stage covers sticks, triggers, buttons, and the USB or radio link. The transport stage moves raw reports over USB or Bluetooth. The driver stage makes the operating system see a human interface device. The mapping stage assigns axes and buttons to actions. The focus stage routes input to the game window that has foreground priority. The power stage decides whether the device and its host stay awake.
Start at the physical end because it is cheapest to test. A controller connected over a cable that only carries power will pair but never deliver input. A USB hub that enumerates slowly can complete the handshake while dropping the interrupt transfers that actually carry reports. A worn stick drifts past its deadzone at rest, so the game reads constant input and suppresses or misreads everything else.
The transport stage fails quietly. Bluetooth controllers often pair to a phone or tablet you forgot about, and the last device to claim the link wins. USB 3.0 ports and hubs emit radio noise near 2.4 GHz, and moving a receiver from a rear port to a front port or a short extension cable fixes a meaningful share of dropout cases without any software change.
The mapping stage is where most "connected but dead" reports are born. Steam Input, Xbox Accessories profiles, and console-level button remaps all sit between the raw device and the game. A profile that maps every face button to an unused action, or a remap-left-on experiment, produces exactly the symptom you are chasing: the device is present, the game polls it, and nothing happens.
The focus stage explains the rest. Games that capture input only when their window is active ignore a controller in the background, and overlay software can steal focus at launch. Anticheat layers add a further gate: a controller the anticheat does not recognize may work in menus and fail in a match. The power stage cuts in last. Idle timers suspend USB root hubs, and a controller left on a charger for days can hold a full charge yet refuse to report.
A professional caveat worth internalizing: never trust a "connected" light as proof of input delivery. Verify input at the operating-system level before touching the game. If the OS input tester shows clean data, the fault is above the transport layer and no amount of re-pairing will fix it.
What the Numbers Say About Latency and Dropouts
Stable, measurable ranges matter more than slogans. A wired USB connection adds roughly 5 to 15 milliseconds of input latency on a well-behaved host, and Bluetooth adds roughly 10 to 30 milliseconds over the same path. The gap is small in absolute terms. It grows under load, when a busy radio or a saturated bus retries transmissions and the tail of the distribution stretches.
Two thresholds govern wireless play more than any spec sheet. The first is range: most 2.4 GHz controllers hold a clean link to roughly 10 meters (about 33 feet) with line of sight, and walls, water, and human bodies cut that figure sharply. The second is battery: a controller below roughly 10 to 15 percent charge often keeps its radio alive, reports a connection, and then fails to sustain the polling rate the game expects. A charging cable that supplies under about 0.5 A may power the radio without topping the cell, which explains controllers that "work when plugged in" but die instantly when unplugged.
Timing matters too. Host idle timers commonly suspend a USB root hub after a few minutes to an hour of inactivity, depending on the power plan. After wake, some controllers take several seconds to re-enumerate, and a game already running will not necessarily re-detect them. That is why "it worked yesterday" is a real diagnostic clue: the suspect is sleep, not pairing.
The Hidden Causes Nobody Checks First
The counterintuitive one: a controller can be connected, powered, recognized, correctly mapped, and still deliver nothing because another device owns the input session. Steam Input can virtualize a controller into a keyboard-and-mouse profile, and the physical device is then ignored while the virtual one feeds the game. A second paired controller can hold the player slot. A macro tool or accessibility layer can intercept reports before the game sees them.
Firmware is the second blind spot. Controllers receive firmware updates through their vendor's accessory app, and a failed or partial update can leave the device enumerating while its report descriptor is corrupted. The symptom is identical to a hardware failure, and the fix is a clean reflash, not a new controller.
Warnings worth treating as stop signals:
Stop and inspect the port or connector if the controller disconnects when the cable moves; repeated flexing can damage the socket. Do not force a firmware update over a flaky wireless link; use a wired connection and a stable power source. Treat third-party receiver dongles that clone a vendor's protocol as unreliable; they can pass pairing and fail report delivery. Do not run overlapping remap, macro, and overlay tools at once; each adds a layer that can swallow input. Suspect a failing battery if runtime has fallen below roughly half its original figure; radio dropouts follow.
Connection Methods Compared
The right transport depends on what you are doing, not on marketing claims.
| Method | Typical latency | Reliability | Main failure mode |
|---|---|---|---|
| USB cable, direct port | 5–15 ms | High | Charge-only cable, damaged port |
| 2.4 GHz vendor dongle | 10–20 ms | High | USB 3.0 interference, range |
| Bluetooth | 10–30 ms | Moderate | Pairing stolen by another device |
| Wired through unpowered hub | 5–20 ms | Moderate | Hub drops interrupt transfers |
| Wireless with weak battery | Variable | Low | Sustained polling failure |
| Virtualized input layer | Adds a stage | Depends on config | Profile swallows input |
If a direct wired connection with a known data cable fails the OS-level input test, the problem is the controller or its driver, not the game.
A Timeline of a Single Connection
Most failures happen in a narrow window right after pairing, which is why "reconnect and retry" sometimes appears to work.
| Time after connect | What the system does | Common failure here |
|---|---|---|
| 0–1 s | Radio link and identity handshake | Pairing to the wrong host |
| 1–3 s | Driver loads and exposes an HID endpoint | Driver error, stale descriptor |
| 3–5 s | Mapping layer applies the active profile | Remap or Steam Input override |
| 5–10 s | Game polls the device on launch | Game ignores non-standard devices |
| Minutes to hours | Power management idles the port | Sleep suspends the hub |
| After wake | Device re-enumerates | Game does not re-detect it |
| Firmware update | Descriptor rewritten | Corrupted report descriptor |
Fixing It in the Right Order
Work from the OS outward, and stop at the first stage that fails. That discipline prevents the classic mistake of reinstalling games for a cable problem.
Test raw input with the operating system's own game-controller panel or a browser gamepad tester. Confirm every axis and button registers before opening any game. Swap to a known data cable and a rear motherboard port, bypassing hubs and front-panel extensions. Retest. Close every remap, macro, overlay, and virtualization tool, then retest. If input returns, the conflict is in that layer, and you can re-enable tools one at a time. Reset the controller's mapping to default in the vendor app, then re-pair from scratch by removing the old pairing entry on the host first. Update firmware over a wired connection, with the controller at more than half charge or plugged into a powered port. Disable USB selective suspend for the relevant hub in the power plan, and set the controller's idle timeout to never during diagnosis. If the OS test still shows nothing, try the controller on a second host. Failure on both points to the device; success on both points to the original host's drivers or ports.
Explicit thresholds keep this honest. A cable must carry data, not just power; charge-only cables are common and pass pairing. Battery should sit above roughly 20 percent for diagnosis. A wireless link should be within about 10 meters with line of sight. If none of the seven steps restores input on either host, treat the controller as faulty hardware and pursue warranty service.
Limits of This Diagnosis
No remote checklist can distinguish a failed Hall-effect sensor from a corrupted report descriptor without device-level tooling. Vendor diagnostic apps vary widely in what they expose, and some report connection status without testing each input. Anticheat behavior is deliberately opaque, so "works in menus, fails in match" can only be narrowed by testing a different game, not by inspection. Sleep and power-management behavior also differs by operating system version and power plan, so exact idle timers are not universal.
What remains reliable is the order of testing. Raw input first, transport second, mapping third, game last. That sequence separates radio, driver, configuration, and software faults with a handful of checks, and it turns a vague "connected but dead" report into a specific broken link you can actually fix.