Summary
Windows 11 now includes a gamepad-friendly layout for the touch keyboard / on-screen keyboard. This is very useful for controller-first scenarios, handheld PCs, couch gaming, accessibility setups, and gamepad-only workflows.
However, it is unclear whether opening this keyboard provides any system-level GameInput focus or input-routing behavior that prevents the game in the background from also receiving the same gamepad input.
Problem
When a user opens the Windows touch keyboard in gamepad layout, the user intent is usually to type or navigate the keyboard UI, not to continue controlling the game behind it.
If the foreground keyboard consumes gamepad input while a background game also receives the same input, several problems can happen:
- D-pad / left stick navigation moves both the keyboard focus and the game UI.
- Face buttons used as keyboard accelerators, such as X for Backspace or Y for Space, can also trigger in-game actions.
- Triggers/shoulders used by the keyboard can still affect gameplay.
- Games using APIs or wrappers that allow background input can continue responding while the user is typing.
- Virtual controller/remapper/accessibility scenarios become difficult to make reliable because there is no clear system-level ownership of gamepad input while the touch keyboard is active.
Current public documentation
The GameInput focus policy documentation describes process-level focus behavior and options such as:
GameInputDefaultFocusPolicyGameInputEnableBackgroundInputGameInputExclusiveForegroundInput
But I could not find public documentation that says the Windows touch keyboard/gamepad keyboard layout participates in this focus model, acquires exclusive foreground input, or causes background games to receive neutral/rest states while the keyboard is open.
The Windows Insider announcement only states that the gamepad keyboard layout supports controller navigation and button accelerators, for example X for Backspace and Y for Space.
Requested behavior
Please consider adding an official GameInput / Windows input-routing behavior for the gamepad touch keyboard, such as one of the following:
- When the touch keyboard with gamepad layout is open and foreground, it should have exclusive gamepad input routing, so background GameInput clients do not receive those inputs.
- Background games should receive neutral/rest state reports while the keyboard is actively accepting gamepad input.
- GameInput should expose an explicit state/event indicating that system UI, such as the touch keyboard, currently owns gamepad navigation input.
- There should be a documented way for games/remappers to distinguish normal background input from input currently being consumed by system text entry UI.
Why this matters
The gamepad keyboard is most useful in exactly the environments where a controller may be the primary input device: handheld gaming PCs, TV/couch setups, accessibility configurations, and virtual-controller/remapping tools.
In these scenarios, input duplication between the keyboard and the game behind it creates a poor user experience and can make text entry unreliable.
Request
Please document and/or implement a focus/ownership mechanism for the Windows gamepad touch keyboard so gamepad input used for text entry does not accidentally continue controlling the background game.
Summary
Windows 11 now includes a gamepad-friendly layout for the touch keyboard / on-screen keyboard. This is very useful for controller-first scenarios, handheld PCs, couch gaming, accessibility setups, and gamepad-only workflows.
However, it is unclear whether opening this keyboard provides any system-level GameInput focus or input-routing behavior that prevents the game in the background from also receiving the same gamepad input.
Problem
When a user opens the Windows touch keyboard in gamepad layout, the user intent is usually to type or navigate the keyboard UI, not to continue controlling the game behind it.
If the foreground keyboard consumes gamepad input while a background game also receives the same input, several problems can happen:
Current public documentation
The GameInput focus policy documentation describes process-level focus behavior and options such as:
GameInputDefaultFocusPolicyGameInputEnableBackgroundInputGameInputExclusiveForegroundInputBut I could not find public documentation that says the Windows touch keyboard/gamepad keyboard layout participates in this focus model, acquires exclusive foreground input, or causes background games to receive neutral/rest states while the keyboard is open.
The Windows Insider announcement only states that the gamepad keyboard layout supports controller navigation and button accelerators, for example X for Backspace and Y for Space.
Requested behavior
Please consider adding an official GameInput / Windows input-routing behavior for the gamepad touch keyboard, such as one of the following:
Why this matters
The gamepad keyboard is most useful in exactly the environments where a controller may be the primary input device: handheld gaming PCs, TV/couch setups, accessibility configurations, and virtual-controller/remapping tools.
In these scenarios, input duplication between the keyboard and the game behind it creates a poor user experience and can make text entry unreliable.
Request
Please document and/or implement a focus/ownership mechanism for the Windows gamepad touch keyboard so gamepad input used for text entry does not accidentally continue controlling the background game.