Skip to content

fix: ignore HID controllers with impossible readings - #115

Merged
lippdev merged 3 commits into
mainfrom
fix/ignore-defective-hid-pads
Sep 30, 2026
Merged

lippdev merged 3 commits into
mainfrom
fix/ignore-defective-hid-pads

Conversation

@lippdev

@lippdev lippdev commented Sep 30, 2026

Copy link
Copy Markdown
Owner

What

A Switch Pro Controller read through Windows' generic HID driver reports 6 to 10 buttons down and a stuck D-pad with nobody touching it. The console interface trusted that, kept moving the focus and pressed "Play now" by itself, starting a session.

ControllerMapping.UpdateHidTrust tracks each HID pad: a reading with more than 5 buttons down is skipped, and after 3 in a row the pad is ignored until the app is reopened, with a log line. XInput pads do not use this path.

Verification

Built locally (0 errors); dotnet test passes (155, 4 new). The decision rule is unit tested; the real Switch Pro was not re-tested after the change. Manual check in docs/TESTING.md §3b.

Stacked on #114.

🤖 Generated with Claude Code

A Switch Pro Controller read through Windows' generic HID driver reports 6 to
10 buttons down at once and a D-pad stuck on Up with nobody touching it. The
console interface trusted those readings, so it kept moving the focus and
pressed "Play now" by itself, starting a session and switching the screens.

ControllerMapping.UpdateHidTrust tracks each HID pad: a reading with more than
5 buttons down is skipped, and after 3 such readings in a row the pad is
ignored until the app is reopened, with a line in the log. XInput pads do not
go through this path and are not affected.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>

@pullfrog pullfrog Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Important

The filter can be bypassed by the same controller when Windows also exposes it through Gamepad.Gamepads.

Reviewed changes This review covers the HID invalid-reading threshold, per-pad distrust tracking, tests, and accompanying documentation.

  • HID trust rule: Readings with more than five pressed buttons are skipped, and three consecutive such samples permanently distrust the device for the process.
  • Coverage and documentation: Unit tests exercise the streak rule, and the changelogs and manual test checklist describe the new behavior.

Pullfrog  | Fix all ➔ | Fix 👍s ➔ | View workflow run | Using GPT Luna | 𝕏

Comment thread src/ConsoleMode/Services/ControllerInput.cs Outdated
@lippdev
lippdev changed the base branch from fix/session-hint-toast-sticks to main September 30, 2026 21:13

@pullfrog pullfrog Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Important

The WGI projection can still emit input during the two-sample grace period, so a defective controller may continue navigating or activating controls before it is distrusted.

Reviewed changes This review covers the changes since the prior Pullfrog review, which added filtering of invalid HID controllers from Windows.Gaming.Input.

  • WGI projection filtering: Read raw HID controllers before WGI gamepads, then excluded projections corresponding to controllers already marked invalid.

Pullfrog  | Fix all ➔ | Fix 👍s ➔ | View workflow run | Using GPT Luna | 𝕏

Comment thread src/ConsoleMode/Services/ControllerInput.cs
@lippdev
lippdev merged commit 2ac5c8d into main Sep 30, 2026
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant