Summary
Windows Shell UI appears to convert neutral HID gamepad trigger axes into VK_GAMEPAD_* navigation events. This causes Start menu and context menu navigation even when the virtual controller is otherwise neutral and common gamepad APIs show no pressed buttons.
This was reproduced while testing a virtual HID controller created by HIDMaestro. The issue seems to be in the Windows gamepad-to-shell-navigation path, likely GameInput or the component that converts gamepad state into VK_GAMEPAD_* virtual keys.
Observed behavior
With a virtual DualShock 4-like HID device connected and sending a neutral report:
- Start menu/context menus continuously navigate up or down.
- Browser Gamepad API / gamepad tester may show no buttons pressed.
- Raw input and Win32 keyboard hooks do not show normal keyboard arrow keys.
GetAsyncKeyState/low-level observation shows Windows-generated gamepad virtual keys, especially trigger-related navigation.
Captured examples included:
VK_GAMEPAD_RIGHT_TRIGGER
VK_GAMEPAD_LEFT_TRIGGER
VK_GAMEPAD_RIGHT_THUMBSTICK_UP
Changing or removing the HID trigger usages stops the Shell navigation.
Reproduction notes
The virtual controller used a DS4-style report:
- Sticks centered
- Hat neutral
- Buttons released
- Triggers released as
0x00
When L2/R2 are exposed through normal HID trigger/axis usages, Windows Shell navigation occurs. When those same bytes are changed to vendor-specific usages, the Shell navigation stops, but browsers/games no longer recognize them as normal trigger inputs.
This strongly suggests that the Shell/GameInput navigation layer is treating trigger axis values as directional navigation without applying the correct neutral/released semantics for unidirectional trigger axes.
Expected behavior
Released trigger axes should not generate any Shell navigation virtual keys.
For unidirectional trigger axes with logical range 0..255:
0 should mean released/neutral.
- Only values above a meaningful threshold should generate trigger actions, if trigger actions are intended at all.
- A neutral controller should never continuously navigate Start menu/context menus.
Actual behavior
A neutral virtual HID gamepad can cause Start menu/context menu navigation through VK_GAMEPAD_* events. This happens even though:
- No keyboard arrow key is generated.
- No mouse wheel event is generated.
- The hat/d-pad is neutral.
- The controller remains connected and otherwise idle.
Why this matters
Virtual controllers, accessibility tools, remappers, and testing tools may need to expose HID gamepads with trigger axes. If Windows Shell treats released trigger axes as navigation input, these devices become unusable because system UI starts moving focus without user input.
Request
Please investigate the GameInput / Shell gamepad navigation path and ensure trigger axes use the correct neutral semantics and thresholding before producing VK_GAMEPAD_* navigation events.
Specifically:
- Do not treat
0 on a 0..255 trigger axis as an active negative direction.
- Apply deadzones/thresholds before generating Shell navigation.
- Avoid generating repeated
VK_GAMEPAD_* navigation from a neutral HID report.
Summary
Windows Shell UI appears to convert neutral HID gamepad trigger axes into
VK_GAMEPAD_*navigation events. This causes Start menu and context menu navigation even when the virtual controller is otherwise neutral and common gamepad APIs show no pressed buttons.This was reproduced while testing a virtual HID controller created by HIDMaestro. The issue seems to be in the Windows gamepad-to-shell-navigation path, likely GameInput or the component that converts gamepad state into
VK_GAMEPAD_*virtual keys.Observed behavior
With a virtual DualShock 4-like HID device connected and sending a neutral report:
GetAsyncKeyState/low-level observation shows Windows-generated gamepad virtual keys, especially trigger-related navigation.Captured examples included:
Changing or removing the HID trigger usages stops the Shell navigation.
Reproduction notes
The virtual controller used a DS4-style report:
0x00When L2/R2 are exposed through normal HID trigger/axis usages, Windows Shell navigation occurs. When those same bytes are changed to vendor-specific usages, the Shell navigation stops, but browsers/games no longer recognize them as normal trigger inputs.
This strongly suggests that the Shell/GameInput navigation layer is treating trigger axis values as directional navigation without applying the correct neutral/released semantics for unidirectional trigger axes.
Expected behavior
Released trigger axes should not generate any Shell navigation virtual keys.
For unidirectional trigger axes with logical range
0..255:0should mean released/neutral.Actual behavior
A neutral virtual HID gamepad can cause Start menu/context menu navigation through
VK_GAMEPAD_*events. This happens even though:Why this matters
Virtual controllers, accessibility tools, remappers, and testing tools may need to expose HID gamepads with trigger axes. If Windows Shell treats released trigger axes as navigation input, these devices become unusable because system UI starts moving focus without user input.
Request
Please investigate the GameInput / Shell gamepad navigation path and ensure trigger axes use the correct neutral semantics and thresholding before producing
VK_GAMEPAD_*navigation events.Specifically:
0on a0..255trigger axis as an active negative direction.VK_GAMEPAD_*navigation from a neutral HID report.