Controller Recovery

Controller input recovery

If controller input stops — usually after sleep — this page is the fix and the explanation.

Quick fix

Press Ctrl+Alt+Shift+I, or use Settings → Advanced → Re-arm Controller Input.

That releases the device lock, re-registers RawInput and forces XInput to rescan all four slots.

It is also a diagnostic. If re-arming restores input, the problem was the stale device handle or the registration — not the backend, not the controller. If it does not, the pad genuinely is not reaching Windows.

The honest limitation: you cannot navigate to a Settings button with a controller that has stopped answering. On a handheld with no keyboard, that leaves restarting SteamShell. The value of the manual path is telling you which failure you had while you still have input.

Why input dies after sleep

RawInput locks onto one device so a headset or a remote cannot feed nonsense into the decoder. Those device handles are not stable — Windows re-enumerates HID devices across a suspend and the same controller comes back with a different one.

Three layers handle that, and 2.0.0 added the last two to the standalone shell:

1. Device hand-over. If the locked device has been quiet for over a second and a different one is producing usable reports, the decoder adopts it. This depends on no notification from Windows, so it is the layer that does the work.
2. Power broadcast. On resume, the lock is released and RawInput re-registered — the one failure hand-over cannot fix, because a lost registration produces no report to adopt.
3. Wall-clock gap check. Modern standby does not reliably deliver the power broadcast, and modern standby is what a handheld sleeps into. So a periodic check notices that far more real time has passed than should have, and treats that as a resume.

Layer 3 compares the actual date, not a tick counter — the tick counter does not advance through suspend, so a gap measured that way sees nothing at all.

Reconnecting a controller

Just plug it back in. RawInput is registered by usage page, not by device, so a reconnected pad starts producing reports immediately and hand-over adopts it within about a second. Nothing needs re-arming.

Checking what happened

The log records each layer:

• Power: resumed from sleep — the broadcast arrived
• Power: wall-clock gap of Ns — it did not, and the fallback caught it
• RawInput: ... adopting 0x... — hand-over took a new device handle
• RawInput: NO reports since resume after 10s — recovery failed; re-arm or restart

Seeing neither power line, with input working, means hand-over alone recovered it.

If it never worked in the first place

That is a different problem — see Controller Mappings for backend selection, and Controller Learner if your pad is not an Xbox-class device.