| uid | input-system-supported-devices |
|---|
A Project usually supports a known set of input methods. For example, a mobile app might support only touch, and a console application might support only gamepads. A cross-platform application might support gamepads, mouse, and keyboard, but might not require XR Device support.
To narrow the options that the Editor UI presents to you, and to avoid creating input Devices and consuming input that your application won't use, you can restrict the set of supported Devices on a per-project basis.
If Supported Devices is empty, no restrictions apply, which means that the Input System adds any Device that Unity recognizes and processes input for it. However, if Support Devices contains one or more entries, the Input System only adds Devices that are of one of the listed types.
Note
When the Support Devices list changes, the system removes or re-adds Devices as needed. The system always keeps information about what Devices are available for potential, which means that no Device is permanently lost as long as it stays connected.
To add Devices to the list, click the Add (+) icon and choose a Device from the menu that appears.
In the Editor, you might want to use input Devices that the application doesn't support. For example, you might want to use a tablet in the Editor even if your application only supports gamepads.
To force the Editor to add all locally available Devices, even if they're not in the list of Supported Devices, open the Input Debugger (menu: Window > Analysis > Input Debugger), and select Options > Add Devices Not Listed in 'Supported Devices'.
Note
This setting is stored as a user setting, not a project setting. This means other users who open the project in their own Editor do not share the setting.
Under Improved Shortcut Support, two independent options control how the Input System resolves overlapping bindings on the same control (for example, a plain B key action as opposed to Shift+B):
| UI / API | Description |
|---|---|
Complexity-Based Shortcut Resolution (shortcutKeysConsumeInput) |
When enabled and Action Priority Shortcut Resolution is off, composite bindings are ordered by automatic complexity (depth of the composite). The first action that performs can consume the input so simpler bindings on the same control are skipped. Modifier composites use ordered modifier evaluation while this mode is active. |
Action Priority Shortcut Resolution (shortcutKeysUseActionPriority) |
When enabled, resolution uses each action's InputAction.Priority. Higher priority is handled first and can consume input for lower-priority actions. A performed action with priority 0 does not mark the input event as handled for suppressing lower-priority overlaps; any priority above zero can. The Priority field appears in the Input Actions editor when this is on. Serialized priority values are always kept on the asset even when this option is off. |
Both options default to off. If Action Priority Shortcut Resolution is on, it takes precedence over complexity-based resolution even if Complexity-Based Shortcut Resolution is also enabled.
For more detail on complexity ordering, see Multiple input sequences (such as keyboard shortcuts).