diff --git a/Packages/com.unity.inputsystem/Documentation~/ActionAssets.md b/Packages/com.unity.inputsystem/Documentation~/ActionAssets.md
deleted file mode 100644
index def2c2e5e5..0000000000
--- a/Packages/com.unity.inputsystem/Documentation~/ActionAssets.md
+++ /dev/null
@@ -1,120 +0,0 @@
----
-uid: input-system-action-assets
----
-# Input Action Assets
-
-- [Creating Input Action Assets](#creating-input-action-assets)
-- [Editing Input Action Assets](#editing-input-action-assets)
-- [Using Input Action Assets](#using-input-action-assets)
-- [Type-safe C# API Generation](#type-safe-c-api-generation)
-
-An Input Action Asset is an Asset which contains a set of [Input Actions](Actions.md) definitions and their associated [Bindings](ActionBindings.md) and [Control Schemes](ActionBindings.md#control-schemes). These Assets have the `.inputactions` file extension and are stored in a plain JSON format.
-
-The input system creates an Action Asset when you set up the [default project-wide actions](ProjectWideActions.md), but you can also create new Action Assets directly in the Project window.
-
-For most common scenarios, you do not need to use more than one Input Action Asset. It is usually simpler to configure your project-wide action definition in the Project Settings window.
-
-
-## Creating Input Action Assets
-
-To create an Asset that contains [Input Actions](Actions.md) in Unity, right-click in the __Project__ window or go to __Assets > Create > Input Actions__ from Unity's main menu.
-
-## Editing Input Action Assets
-
-To bring up the Action editor, double-click an `.inputactions` Asset in the Project Browser, or select the __Edit Asset__ button in the Inspector for that Asset. You can have more than one editor window open at the same time, but not for the same Asset.
-
-The Actions Editor which opens is identical to the [Actions Editor in the Project Settings window](ActionsEditor.md).
-
-
-## Using Input Action Assets
-
-
-## Type-safe C# API Generation
-
-Input Action Assets allow you to **generate a C# class** from your action definitions, which allow you to refer to your actions in a type-safe manner from code. This means you can avoid looking up your actions by string.
-
-### Auto-generating script code for Actions
-
-One of the most convenient ways to work with `.inputactions` Assets in scripts is to automatically generate a C# wrapper class for them. This removes the need to manually look up Actions and Action Maps using their names, and also provides an easier way to set up callbacks.
-
-To enable this option, tick the __Generate C# Class__ checkbox in the importer properties in the Inspector of the `.inputactions` Asset, then select __Apply__.
-
-
-
-You can optionally choose a path name, class name, and namespace for the generated script, or keep the default values.
-
-This generates a C# script that simplifies working with the Asset.
-
-```CSharp
-using UnityEngine;
-using UnityEngine.InputSystem;
-
-// IGameplayActions is an interface generated from the "gameplay" action map
-// we added (note that if you called the action map differently, the name of
-// the interface will be different). This was triggered by the "Generate Interfaces"
-// checkbox.
-public class MyPlayerScript : MonoBehaviour, IGameplayActions
-{
- // MyPlayerControls is the C# class that Unity generated.
- // It encapsulates the data from the .inputactions asset we created
- // and automatically looks up all the maps and actions for us.
- MyPlayerControls controls;
-
- public void OnEnable()
- {
- if (controls == null)
- {
- controls = new MyPlayerControls();
- // Tell the "gameplay" action map that we want to get told about
- // when actions get triggered.
- controls.gameplay.SetCallbacks(this);
- }
- controls.gameplay.Enable();
- }
-
- public void OnDisable()
- {
- controls.gameplay.Disable();
- }
-
- public void OnUse(InputAction.CallbackContext context)
- {
- // 'Use' code here.
- }
-
- public void OnMove(InputAction.CallbackContext context)
- {
- // 'Move' code here.
- }
-
-}
-```
-
->__Note__: To regenerate the .cs file, right-click the .inputactions asset in the Project Browser and choose "Reimport".
-
-### Using Action Assets with `PlayerInput`
-
-The [Player Input](PlayerInput.md) component provides a convenient way to handle input for one or multiple players. You can assign your Action Asset to the Player Input component so that it can then automatically handle activating Action Maps and selecting Control Schemes for you.
-
-
-
-### Modifying Input Action Assets at runtime
-There are several ways to modify an Input Action Asset at runtime. Any modifications that you make during Play mode to an Input Action Asset do not persist in the Input Action Asset after you exit Play mode. This means you can test your application in a realistic manner in the Editor without having to worry about inadvertently modifying the asset. For examples on how to modify an Input Action Asset, see the documentation on [Creating Actions in code](Actions.md#creating-actions-in-code) and [Changing Bindings](ActionBindings.md#changing-bindings).
-
-
-### The Default Actions Asset
-
-An asset called `DefaultInputActions.inputactions` containing a default setup of Actions comes with the Input System Package. You can reference this asset directly in your projects like any other Unity asset. However, the asset is also available in code form through the [`DefaultInputActions`](../api/UnityEngine.InputSystem.DefaultInputActions.html) class.
-
-```CSharp
-void Start()
-{
- // Create an instance of the default actions.
- var actions = new DefaultInputActions();
- actions.Player.Look.performed += OnLook;
- actions.Player.Move.performed += OnMove;
- actions.Enable();
-}
-```
-
-> __Note:__ This default actions asset is older than, and entirely separate from the [default project-wide actions](ProjectWideActions.md). It is a legacy asset that remains included in the package for backward compatibility.
diff --git a/Packages/com.unity.inputsystem/Documentation~/ActionBindings.md b/Packages/com.unity.inputsystem/Documentation~/ActionBindings.md
deleted file mode 100644
index 9c164e2439..0000000000
--- a/Packages/com.unity.inputsystem/Documentation~/ActionBindings.md
+++ /dev/null
@@ -1,953 +0,0 @@
----
-uid: input-system-action-bindings
----
-# Input Bindings
-
-* [Composite Bindings](#composite-bindings)
- * [1D Axis](#1d-axis)
- * [2D Vector](#2d-vector)
- * [3D Vector](#3d-vector)
- * [One Modifier](#one-modifier)
- * [Two Modifiers](#two-modifiers)
- * [Writing custom Composites](#writing-custom-composites)
-* [Working with Bindings](#working-with-bindings)
- * [Looking up Bindings](#looking-up-bindings)
- * [Changing Bindings](#changing-bindings)
- * [Applying overrides](#applying-overrides)
- * [Erasing Bindings](#erasing-bindings)
- * [Adding Bindings](#adding-bindings)
- * [Setting parameters](#setting-parameters)
- * [Interactive rebinding](#interactive-rebinding)
- * [Saving and loading rebinds](#saving-and-loading-rebinds)
- * [Restoring original Bindings](#restoring-original-bindings)
- * [Displaying Bindings](#displaying-bindings)
-* [Control schemes](#control-schemes)
-* [Details](#details)
- * [Binding resolution](#binding-resolution)
- * [Binding resolution while Actions are enabled](#binding-resolution-while-actions-are-enabled)
- * [Choosing which Devices to use](#choosing-which-devices-to-use)
- * [Conflicting inputs](#conflicting-inputs)
- * [Initial state check](#initial-state-check)
-
-An [`InputBinding`](../api/UnityEngine.InputSystem.InputBinding.html) represents a connection between an [Action](Actions.md) and one or more [Controls](Controls.md) identified by a [Control path](Controls.md#control-paths). For example, the **right trigger** of a gamepad (a control) might be bound to an an action named "accelerate", so that pulling the right trigger causes a car to accelerate in your game.
-
-You can add multiple bindings to an action, which is generally useful for supporting multiple types of input device. For example, in the default set of actions, the "Move" action has a binding to the left gamepad stick and the WSAD keys, which means input through any of these bindings will perform the action.
-
-You can also bind multiple controls from the same device to an action. For example, both the left and right trigger of a gamepad could be mapped to the same action, so that pulling either trigger has the same result in your game.
-
-/leftStick"`|
-|[`overridePath`](../api/UnityEngine.InputSystem.InputBinding.html#UnityEngine_InputSystem_InputBinding_overridePath)|[Control path](Controls.md#control-paths) that overrides `path`. Unlike `path`, `overridePath` is not persistent, so you can use it to non-destructively override the path on a Binding. If it is set to something other than null, it takes effect and overrides `path`. To get the path which is currently in effect (that is, either `path` or `overridePath`), you can query the [`effectivePath`](../api/UnityEngine.InputSystem.InputBinding.html#UnityEngine_InputSystem_InputBinding_effectivePath) property.|
-|[`action`](../api/UnityEngine.InputSystem.InputBinding.html#UnityEngine_InputSystem_InputBinding_action)|The name or ID of the Action that the Binding should trigger. Note that this can be null or empty (for instance, for [composites](#composite-bindings)). Not case-sensitive./leftStick`, you get deadzones applied twice: once from the deadzone Processor sitting on the `leftStick` Control, and once from the Binding./rightTrigger")
- .With("Negative", "/leftTrigger");
-```
-
-Each Composite consists of one Binding that has [`InputBinding.isComposite`](../api/UnityEngine.InputSystem.InputBinding.html#UnityEngine_InputSystem_InputBinding_isComposite) set to true, followed by one or more Bindings that have [`InputBinding.isPartOfComposiste`](../api/UnityEngine.InputSystem.InputBinding.html#UnityEngine_InputSystem_InputBinding_isPartOfComposite) set to true. In other words, several consecutive entries in [`InputActionMap.bindings`](../api/UnityEngine.InputSystem.InputActionMap.html#UnityEngine_InputSystem_InputActionMap_bindings) or [`InputAction.bindings`](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_bindings) together form a Composite.
-
-Note that each composite part can be bound arbitrary many times.
-
-```CSharp
-// Make both shoulders and triggers pull on the axis.
-myAction.AddCompositeBinding("Axis")
- .With("Positive", "/rightTrigger")
- .With("Positive", "/rightShoulder")
- .With("Negative", "/leftTrigger");
- .With("Negative", "/leftShoulder");
-```
-
-Composites can have parameters, just like [Interactions](Interactions.md) and [Processors](Processors.md).
-
-```CSharp
-myAction.AddCompositeBinding("Axis(whichSideWins=1)");
-```
-
-There are currently five Composite types that come with the system out of the box: [1D-Axis](#1d-axis), [2D-Vector](#2d-vector), [3D-Vector](#3d-vector), [One Modifier](#one-modifier) and [Two Modifiers](#two-modifiers). Additionally, you can [add your own](#writing-custom-composites) types of Composites.
-
-### 1D axis
-
-
-
-
-
-A Composite made of two buttons: one that pulls a 1D axis in its negative direction, and another that pulls it in its positive direction. Implemented in the [`AxisComposite`](../api/UnityEngine.InputSystem.Composites.AxisComposite.html) class. The result is a `float`.
-
-```CSharp
-myAction.AddCompositeBinding("1DAxis") // Or just "Axis"
- .With("Positive", "/rightTrigger")
- .With("Negative", "/leftTrigger");
-```
-
-The axis Composite has two part bindings.
-
-|Part|Type|Description|
-|----|----|-----------|
-|[`positive`](../api/UnityEngine.InputSystem.Composites.AxisComposite.html#UnityEngine_InputSystem_Composites_AxisComposite_positive)|`Button`|Controls pulling in the positive direction (towards [`maxValue`](../api/UnityEngine.InputSystem.Composites.AxisComposite.html#UnityEngine_InputSystem_Composites_AxisComposite_maxValue)).|
-|[`negative`](../api/UnityEngine.InputSystem.Composites.AxisComposite.html#UnityEngine_InputSystem_Composites_AxisComposite_negative)|`Button`|Controls pulling in the negative direction, (towards [`minValue`](../api/UnityEngine.InputSystem.Composites.AxisComposite.html#UnityEngine_InputSystem_Composites_AxisComposite_minValue)).|
-
-You can set the following parameters on an axis Composite:
-
-|Parameter|Description|
-|---------|-----------|
-|[`whichSideWins`](../api/UnityEngine.InputSystem.Composites.AxisComposite.html#UnityEngine_InputSystem_Composites_AxisComposite_whichSideWins)|What happens if both [`positive`](../api/UnityEngine.InputSystem.Composites.AxisComposite.html#UnityEngine_InputSystem_Composites_AxisComposite_positive) and [`negative`](../api/UnityEngine.InputSystem.Composites.AxisComposite.html#UnityEngine_InputSystem_Composites_AxisComposite_negative) are actuated. See table below.|
-|[`minValue`](../api/UnityEngine.InputSystem.Composites.AxisComposite.html#UnityEngine_InputSystem_Composites_AxisComposite_minValue)|The value returned if the [`negative`](../api/UnityEngine.InputSystem.Composites.AxisComposite.html#UnityEngine_InputSystem_Composites_AxisComposite_negative) side is actuated. Default is -1.|
-|[`maxValue`](../api/UnityEngine.InputSystem.Composites.AxisComposite.html#UnityEngine_InputSystem_Composites_AxisComposite_maxValue)|The value returned if the [`positive`](../api/UnityEngine.InputSystem.Composites.AxisComposite.html#UnityEngine_InputSystem_Composites_AxisComposite_positive) side is actuated. Default is 1.|
-
-If Controls from both the `positive` and the `negative` side are actuated, then the resulting value of the axis Composite depends on the `whichSideWin` parameter setting.
-
-|[`WhichSideWins`](../api/UnityEngine.InputSystem.Composites.AxisComposite.WhichSideWins.html)|Description|
-|---------------|-----------|
-|(0) `Neither`|Neither side has precedence. The Composite returns the midpoint between `minValue` and `maxValue` as a result. At their default settings, this is 0./w")
- .With("Down", "/s")
- .With("Left", "/a")
- .With("Right", "/d");
-
-// To set mode (2=analog, 1=digital, 0=digitalNormalized):
-myAction.AddCompositeBinding("2DVector(mode=2)")
- .With("Up", "/leftStick/up")
- .With("Down", "/leftStick/down")
- .With("Left", "/leftStick/left")
- .With("Right", "/leftStick/right");
-```
-
-The 2D vector Composite has four part Bindings.
-
-|Part|Type|Description|
-|----|----|-----------|
-|[`up`](../api/UnityEngine.InputSystem.Composites.Vector2Composite.html#UnityEngine_InputSystem_Composites_Vector2Composite_up)|`Button`|Controls representing `(0,1)` (+Y).|
-|[`down`](../api/UnityEngine.InputSystem.Composites.Vector2Composite.html#UnityEngine_InputSystem_Composites_Vector2Composite_down)|`Button`|Controls representing `(0,-1)` (-Y).|
-|[`left`](../api/UnityEngine.InputSystem.Composites.Vector2Composite.html#UnityEngine_InputSystem_Composites_Vector2Composite_left)|`Button`|Controls representing `(-1,0)` (-X).|
-|[`right`](../api/UnityEngine.InputSystem.Composites.Vector2Composite.html#UnityEngine_InputSystem_Composites_Vector2Composite_right)|`Button`|Controls representing `(1,0)` (+X).|
-
-In addition, you can set the following parameters on a 2D vector Composite:
-
-|Parameter|Description|
-|---------|-----------|
-|[`mode`](../api/UnityEngine.InputSystem.Composites.Vector2Composite.html#UnityEngine_InputSystem_Composites_Vector2Composite_mode)|Whether to treat the inputs as digital or as analog controls./w")
- .With("Down", "/s")
- .With("Left", "/a")
- .With("Right", "/d");
-
-// To set mode (2=analog, 1=digital, 0=digitalNormalized):
-myAction.AddCompositeBinding("3DVector(mode=2)")
- .With("Up", "/leftStick/up")
- .With("Down", "/leftStick/down")
- .With("Left", "/leftStick/left")
- .With("Right", "/leftStick/right");
-```
-
-The 3D vector Composite has four part Bindings.
-
-|Part|Type|Description|
-|----|----|-----------|
-|[`up`](../api/UnityEngine.InputSystem.Composites.Vector3Composite.html#UnityEngine_InputSystem_Composites_Vector3Composite_up)|`Button`|Controls representing `(0,1,0)` (+Y).|
-|[`down`](../api/UnityEngine.InputSystem.Composites.Vector3Composite.html#UnityEngine_InputSystem_Composites_Vector3Composite_down)|`Button`|Controls representing `(0,-1,0)` (-Y).|
-|[`left`](../api/UnityEngine.InputSystem.Composites.Vector3Composite.html#UnityEngine_InputSystem_Composites_Vector3Composite_left)|`Button`|Controls representing `(-1,0,0)` (-X).|
-|[`right`](../api/UnityEngine.InputSystem.Composites.Vector3Composite.html#UnityEngine_InputSystem_Composites_Vector3Composite_right)|`Button`|Controls representing `(1,0,0)` (+X).|
-|[`forward`](../api/UnityEngine.InputSystem.Composites.Vector3Composite.html#UnityEngine_InputSystem_Composites_Vector3Composite_forward)|`Button`|Controls representing `(0,0,1)` (+Z).|
-|[`backward`](../api/UnityEngine.InputSystem.Composites.Vector3Composite.html#UnityEngine_InputSystem_Composites_Vector3Composite_backward)|`Button`|Controls representing `(0,0,-1)` (-Z).|
-
-In addition, you can set the following parameters on a 3D vector Composite:
-
-|Parameter|Description|
-|---------|-----------|
-|[`mode`](../api/UnityEngine.InputSystem.Composites.Vector3Composite.html#UnityEngine_InputSystem_Composites_Vector3Composite_mode)|Whether to treat the inputs as digital or as analog controls./1")
- .With("Modifier", "/ctrl")
-
-// Add binding to mouse delta such that it only takes effect
-// while the ALT key is down.
-myAction.AddCompositeBinding("OneModifier")
- .With("Binding", "/delta")
- .With("Modifier", "/alt");
-```
-
-The button with one modifier Composite has two part Bindings.
-
-|Part|Type|Description|
-|----|----|-----------|
-|[`modifier`](../api/UnityEngine.InputSystem.Composites.OneModifierComposite.html#UnityEngine_InputSystem_Composites_OneModifierComposite_modifier)|`Button`|Modifier that has to be held for `binding` to come through. If the user holds any of the buttons bound to the `modifier` at the same time as the button that triggers the action, the Composite assumes the value of the `modifier` Binding. If the user does not press any button bound to the `modifier`, the Composite remains at default value.|
-|[`binding`](../api/UnityEngine.InputSystem.Composites.OneModifierComposite.html#UnityEngine_InputSystem_Composites_OneModifierComposite_binding)|Any|The control(s) whose value the Composite assumes while the user holds down the `modifier` button.|
-
-This Composite has no parameters.
-
-### Two Modifiers
-
-
-
-
-
-A Composite that requires the user to hold down two "modifier" buttons in addition to another control from which the actual value of the Binding is determined. This can be used, for example, for Bindings such as "SHIFT+CTRL+1". Implemented in the [`TwoModifiersComposite`](../api/UnityEngine.InputSystem.Composites.TwoModifiersComposite.html) class. The buttons can be on any Device, and can be toggle buttons or full-range buttons such as gamepad triggers.
-
-The result is a value of the same type as the controls bound to the [`binding`](../api/UnityEngine.InputSystem.Composites.TwoModifiersComposite.html#UnityEngine_InputSystem_Composites_TwoModifiersComposite_binding) part.
-
-```CSharp
-myAction.AddCompositeBinding("TwoModifiers")
- .With("Button", "/1")
- .With("Modifier1", "/leftCtrl")
- .With("Modifier1", "/rightCtrl")
- .With("Modifier2", "/leftShift")
- .With("Modifier2", "/rightShift");
-```
-
-The button with two modifiers Composite has three part Bindings.
-
-|Part|Type|Description|
-|----|----|-----------|
-|[`modifier1`](../api/UnityEngine.InputSystem.Composites.TwoModifiersComposite.html#UnityEngine_InputSystem_Composites_TwoModifiersComposite_modifier1)|`Button`|The first modifier the user must hold alongside `modifier2`, for `binding` to come through. If the user does not press any button bound to the `modifier1`, the Composite remains at default value.|
-|[`modifier2`](../api/UnityEngine.InputSystem.Composites.TwoModifiersComposite.html#UnityEngine_InputSystem_Composites_TwoModifiersComposite_modifier2)|`Button`|The second modifier the user must hold alongside `modifier1`, for `binding` to come through. If the user does not press any button bound to the `modifier2`, the Composite remains at default value.|
-|[`binding`](../api/UnityEngine.InputSystem.Composites.TwoModifiersComposite.html#UnityEngine_InputSystem_Composites_TwoModifiersComposite_binding)|Any|The control(s) whose value the Composite assumes while the user presses both `modifier1` and `modifier2` at the same time.|
-
-This Composite has no parameters.
-
-### Writing custom Composites
-
-You can define new types of Composites, and register them with the API. Unity treats these the same as predefined types, which the Input System internally defines and registers in the same way.
-
-To define a new type of Composite, create a class based on [`InputBindingComposite`](../api/UnityEngine.InputSystem.InputBindingComposite-1.html).
-
-> __IMPORTANT__: Composites must be __stateless__. This means that you cannot store local state that changes depending on the input being processed. For __stateful__ processing on Bindings, see [interactions](./Interactions.md#writing-custom-interactions).
-
-```CSharp
-// Use InputBindingComposite as a base class for a composite that returns
-// values of type TValue.
-// NOTE: It is possible to define a composite that returns different kinds of values
-// but doing so requires deriving directly from InputBindingComposite.
-#if UNITY_EDITOR
-[InitializeOnLoad] // Automatically register in editor.
-#endif
-// Determine how GetBindingDisplayString() formats the composite by applying
-// the DisplayStringFormat attribute.
-[DisplayStringFormat("{firstPart}+{secondPart}")]
-public class CustomComposite : InputBindingComposite
-{
- // Each part binding is represented as a field of type int and annotated with
- // InputControlAttribute. Setting "layout" restricts the controls that
- // are made available for picking in the UI.
- //
- // On creation, the int value is set to an integer identifier for the binding
- // part. This identifier can read values from InputBindingCompositeContext.
- // See ReadValue() below.
- [InputControl(layout = "Button")]
- public int firstPart;
-
- [InputControl(layout = "Button")]
- public int secondPart;
-
- // Any public field that is not annotated with InputControlAttribute is considered
- // a parameter of the composite. This can be set graphically in the UI and also
- // in the data (e.g. "custom(floatParameter=2.0)").
- public float floatParameter;
- public bool boolParameter;
-
- // This method computes the resulting input value of the composite based
- // on the input from its part bindings.
- public override float ReadValue(ref InputBindingCompositeContext context)
- {
- var firstPartValue = context.ReadValue(firstPart);
- var secondPartValue = context.ReadValue(secondPart);
-
- //... do some processing and return value
- }
-
- // This method computes the current actuation of the binding as a whole.
- public override float EvaluateMagnitude(ref InputBindingCompositeContext context)
- {
- // Compute normalized [0..1] magnitude value for current actuation level.
- }
-
- static CustomComposite()
- {
- // Can give custom name or use default (type name with "Composite" clipped off).
- // Same composite can be registered multiple times with different names to introduce
- // aliases.
- //
- // NOTE: Registering from the static constructor using InitializeOnLoad and
- // RuntimeInitializeOnLoadMethod is only one way. You can register the
- // composite from wherever it works best for you. Note, however, that
- // the registration has to take place before the composite is first used
- // in a binding. Also, for the composite to show in the editor, it has
- // to be registered from code that runs in edit mode.
- InputSystem.RegisterBindingComposite();
- }
-
- [RuntimeInitializeOnLoadMethod(RuntimeInitializeLoadType.BeforeSceneLoad)]
- static void Init() {} // Trigger static constructor.
-}
-```
-
-The Composite should now appear in the editor UI when you add a Binding, and you can now use it in scripts.
-
-```CSharp
- myAction.AddCompositeBinding("custom(floatParameter=2.0)")
- .With("firstpart", "/buttonSouth")
- .With("secondpart", "/buttonNorth");
-```
-
-To define a custom parameter editor for the Composite, you can derive from [`InputParameterEditor`](../api/UnityEngine.InputSystem.Editor.InputParameterEditor-1.html).
-
-```CSharp
-#if UNITY_EDITOR
-public class CustomParameterEditor : InputParameterEditor
-{
- public override void OnGUI()
- {
- EditorGUILayout.Label("Custom stuff");
- target.floatParameter = EditorGUILayout.FloatField("Some Parameter", target.floatParameter);
- }
-}
-#endif
-```
-
-## Working with Bindings
-
-## Looking up Bindings
-
-You can retrieve the bindings of an action using its [`InputAction.bindings`](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_bindings) property which returns a read-only array of [`InputBinding`](../api/UnityEngine.InputSystem.InputBinding.html) structs.
-
-```CSharp
- // Get bindings of "fire" action.
- var fireBindings = playerInput.actions["fire"].bindings;
-```
-
-Also, all the bindings for all actions in an [`InputActionMap`](../api/UnityEngine.InputSystem.InputActionMap.html) are made available through the [`InputActionMap.bindings`](../api/UnityEngine.InputSystem.InputActionMap.html#UnityEngine_InputSystem_InputActionMap_bindings) property. The bindings are associated with actions through an [action ID](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_id) or [action name](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_name) stored in the [`InputBinding.action`](../api/UnityEngine.InputSystem.InputBinding.html#UnityEngine_InputSystem_InputBinding_action) property.
-
-```CSharp
- // Get all bindings in "gameplay" action map.
- var gameplayBindings = playerInput.actions.FindActionMap("gameplay").bindings;
-```
-
-You can also look up specific the indices of specific bindings in [`InputAction.bindings`](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_bindings) using the [`InputActionRebindingExtensions.GetBindingIndex`](../api/UnityEngine.InputSystem.InputActionRebindingExtensions.html#UnityEngine_InputSystem_InputActionRebindingExtensions_GetBindingIndex_UnityEngine_InputSystem_InputAction_UnityEngine_InputSystem_InputBinding_) method.
-
-```CSharp
- // Find the binding in the "Keyboard" control scheme.
- playerInput.actions["fire"].GetBindingIndex(group: "Keyboard");
-
- // Find the first binding to the space key in the "gameplay" action map.
- playerInput.FindActionMap("gameplay").GetBindingIndex(
- new InputBinding { path = "/space" });
-```
-
-Finally, you can look up the binding that corresponds to a specific control through [`GetBindingIndexForControl`](../api/UnityEngine.InputSystem.InputActionRebindingExtensions.html#UnityEngine_InputSystem_InputActionRebindingExtensions_GetBindingIndexForControl_). This way, you can, for example, map a control found in the [`controls`](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_controls) array of an [`InputAction`](../api/UnityEngine.InputSystem.InputAction.html) back to an [`InputBinding`](../api/UnityEngine.InputSystem.InputBinding.html).
-
-```CSharp
- // Find the binding that binds LMB to "fire". If there is no such binding,
- // bindingIndex will be -1.
- var fireAction = playerInput.actions["fire"];
- var bindingIndex = fireAction.GetBindingIndexForControl(Mouse.current.leftButton);
- if (binding == -1)
- Debug.Log("Fire is not bound to LMB of the current mouse.");
-```
-
-## Changing Bindings
-
-In general, you can change existing bindings via the [`InputActionSetupExtensions.ChangeBinding`](../api/UnityEngine.InputSystem.InputActionSetupExtensions.html#UnityEngine_InputSystem_InputActionSetupExtensions_ChangeBinding_UnityEngine_InputSystem_InputAction_System_Int32_) method. This returns an accessor that can be used to modify the properties of the targeted [`InputBinding`](../api/UnityEngine.InputSystem.InputBinding.html). Note that most of the write operations of the accessor are destructive. For non-destructive changes to bindings, see [Applying Overrides](#applying-overrides).
-
-```CSharp
-// Get write access to the second binding of the 'fire' action.
-var accessor = playerInput.actions['fire'].ChangeBinding(1);
-
-// You can also gain access through the InputActionMap. Each
-// map contains an array of all its bindings (see InputActionMap.bindings).
-// Here we gain access to the third binding in the map.
-accessor = playerInput.actions.FindActionMap("gameplay").ChangeBinding(2);
-```
-
-You can use the resulting accessor to modify properties through methods such as [`WithPath`](../api/UnityEngine.InputSystem.InputActionSetupExtensions.BindingSyntax.html#UnityEngine_InputSystem_InputActionSetupExtensions_BindingSyntax_WithPath_) or [`WithProcessors`](../api/UnityEngine.InputSystem.InputActionSetupExtensions.BindingSyntax.html#UnityEngine_InputSystem_InputActionSetupExtensions_BindingSyntax_WithProcessors_).
-
-```CSharp
-playerInput.actions["fire"].ChangeBinding(1)
- // Change path to space key.
- .WithPath("/space");
-```
-
-You can also use the accessor to iterate through bindings using [`PreviousBinding`](../api/UnityEngine.InputSystem.InputActionSetupExtensions.BindingSyntax.html#UnityEngine_InputSystem_InputActionSetupExtensions_BindingSyntax_PreviousBinding_) and [`NextBinding`](../api/UnityEngine.InputSystem.InputActionSetupExtensions.BindingSyntax.html#UnityEngine_InputSystem_InputActionSetupExtensions_BindingSyntax_NextBinding_).
-
-```CSharp
-// Move accessor to previous binding.
-accessor = accessor.PreviousBinding();
-
-// Move accessor to next binding.
-accessor = accessor.NextBinding();
-```
-
-If the given binding is a [composite](../api/UnityEngine.InputSystem.InputBinding.html#UnityEngine_InputSystem_InputBinding_isComposite), you can address it by its name rather than by index.
-
-```CSharp
-// Change the 2DVector composite of the "move" action.
-playerInput.actions["move"].ChangeCompositeBinding("2DVector")
-
-
-//
-playerInput.actions["move"].ChangeBinding("WASD")
-```
-
-### Applying overrides
-
-You can override aspects of any Binding at run-time non-destructively. Specific properties of [`InputBinding`](../api/UnityEngine.InputSystem.InputBinding.html) have an `override` variant that, if set, will take precedent over the property that they shadow. All `override` properties are of type `String`.
-
-|Property|Override|Description|
-|--------|--------|-----------|
-|[`path`](../api/UnityEngine.InputSystem.InputBinding.html#UnityEngine_InputSystem_InputBinding_path)|[`overridePath`](../api/UnityEngine.InputSystem.InputBinding.html#UnityEngine_InputSystem_InputBinding_overridePath)|Replaces the [Control path](./Controls.md#control-paths) that determines which Control(s) are referenced in the binding. If [`overridePath`](../api/UnityEngine.InputSystem.InputBinding.html#UnityEngine_InputSystem_InputBinding_overridePath) is set to an empty string, the binding is effectively disabled./leftStick"`|
-|[`processors`](../api/UnityEngine.InputSystem.InputBinding.html#UnityEngine_InputSystem_InputBinding_processors)|[`overrideProcessors`](../api/UnityEngine.InputSystem.InputBinding.html#UnityEngine_InputSystem_InputBinding_overrideProcessors)|Replaces the [processors](./Processors.md) applied to the binding./leftTrigger");
-```
-
-In most cases, it is best to locate specific bindings using APIs such as [`GetBindingIndexForControl`](../api/UnityEngine.InputSystem.InputActionRebindingExtensions.html#UnityEngine_InputSystem_InputActionRebindingExtensions_GetBindingIndexForControl_) and to then apply the override to that specific binding.
-
-```CSharp
-// Find the "Jump" binding for the space key.
-var jumpAction = playerInput.actions["Jump"];
-var bindingIndex = jumpAction.GetBindingIndexForControl(Keyboard.current.spaceKey);
-
-// And change it to the enter key.
-jumpAction.ApplyBindingOverride(bindingIndex, "/enter");
-```
-
-### Erasing Bindings
-
-You can erase a binding by calling [`Erase`](../api/UnityEngine.InputSystem.InputActionSetupExtensions.BindingSyntax.html#UnityEngine_InputSystem_InputActionSetupExtensions_BindingSyntax_Erase_) on the [binding accessor](../api/UnityEngine.InputSystem.InputActionSetupExtensions.BindingSyntax.html).
-
-```CSharp
-// Erase first binding on "fire" action.
-playerInput.actions["fire"].ChangeBinding(0).Erase();
-
-// Erase "2DVector" composite. This will also erase the part
-// bindings of the composite.
-playerInput.actions["move"].ChangeCompositeBinding("2DVector").Erase();
-
-// Can also do this by using the name given to the composite binding.
-playerInput.actions["move"].ChangeCompositeBinding("WASD").Erase();
-
-// Erase first binding in "gameplay" action map.
-playerInput.actions.FindActionMap("gameplay").ChangeBinding(0).Erase();
-```
-
-### Adding Bindings
-
-New bindings can be added to an Action using [`AddAction`](../api/UnityEngine.InputSystem.InputActionSetupExtensions.html#UnityEngine_InputSystem_InputActionSetupExtensions_AddBinding_UnityEngine_InputSystem_InputAction_System_String_System_String_System_String_System_String_) or [`AddCompositeBinding`](../api/UnityEngine.InputSystem.InputActionSetupExtensions.html#UnityEngine_InputSystem_InputActionSetupExtensions_AddCompositeBinding_UnityEngine_InputSystem_InputAction_System_String_System_String_System_String_).
-
-```CSharp
-// Add a binding for the left mouse button to the "fire" action.
-playerInput.actions["fire"].AddBinding("/leftButton");
-
-// Add a WASD composite binding to the "move" action.
-playerInput.actions["move"]
- .AddCompositeBinding("2DVector")
- .With("Up", "/w")
- .With("Left", "/a")
- .With("Down", "/s")
- .With("Right", "/d");
-```
-
-### Setting parameters
-
-A Binding may, either through itself or through its associated Action, lead to [processor](Processors.md), [interaction](Interactions.md), and/or [composite](#composite-bindings) objects being created. These objects can have parameters you can configure through in the [Binding properties view](ActionsEditor.md#bindings) of the Action editor or through the API. This configuration will give parameters their default value.
-
-```CSharp
-// Create an action with a "Hold" interaction on it.
-// Set the "duration" parameter to 4 seconds.
-var action = new InputAction(interactions: "hold(duration=4)");
-```
-
-You can query the current value of any such parameter using the [`GetParameterValue`](../api/UnityEngine.InputSystem.InputActionRebindingExtensions.html#UnityEngine_InputSystem_InputActionRebindingExtensions_GetParameterValue_UnityEngine_InputSystem_InputAction_System_String_UnityEngine_InputSystem_InputBinding_) API.
-
-```CSharp
-// This returns a PrimitiveValue?. It will be null if the
-// parameter is not found. Otherwise, it is a PrimitiveValue
-// which can be converted to a number or boolean.
-var p = action.GetParameterValue("duration");
-Debug.Log("'duration' is set to: " + p.Value);
-```
-
-The above looks for the parameter on any object found on any of the bindings on the action. You can restrict either or both to a more narrow set.
-
-```CSharp
-// Retrieve the value of the "duration" parameter specifically of a
-// "Hold" interaction and only look on bindings in the "Gamepad" group.
-action.GetParameterValue("hold:duration", InputBinding.MaskByGroup("Gamepad"));
-```
-
-Alternatively, you can use an expression parameter to encapsulate both the type and the name of the parameter you want to get the value of. This has the advantage of not needing a string parameter but rather references both the type and the name of the parameter in a typesafe way.
-
-```CSharp
-// Retrieve the value of the "duration" parameter of TapInteraction.
-// This version returns a float? instead of a PrimitiveValue? as it
-// sees the type of "duration" at compile-time.
-action.GetParameterValue((TapInteraction x) => x.duration);
-```
-
-To alter the current value of a parameter, you can use what is referred to as a "parameter override". You can apply these at the level of an individual [`InputAction`](../api/UnityEngine.InputSystem.InputAction.html), or at the level of an entire [`InputActionMap`](../api/UnityEngine.InputSystem.InputActionMap.html), or even at the level of an entire [`InputActionAsset`](../api/UnityEngine.InputSystem.InputActionAsset.html). Such overrides are stored internally and applied automatically even on bindings added later.
-
-To add an override, use the [`ApplyParameterOverride`](../api/UnityEngine.InputSystem.InputActionRebindingExtensions.html#UnityEngine_InputSystem_InputActionRebindingExtensions_ApplyParameterOverride_UnityEngine_InputSystem_InputAction_System_String_UnityEngine_InputSystem_Utilities_PrimitiveValue_UnityEngine_InputSystem_InputBinding_) API or any of its overloads.
-
-```CSharp
-// Set the "duration" parameter on all bindings of the action to 4.
-action.ApplyParameterOverride("duration", 4f);
-
-// Set the "duration" parameter specifically for "tap" interactions only.
-action.ApplyParameterOverride("tap:duration", 0.5f);
-
-// Set the "duration" parameter on tap interactions but only for bindings
-// in the "Gamepad" group.
-action.ApplyParameterOverride("tap:duration", 0.5f, InputBinding.MaskByGroup("Gamepad");
-
-// Set tap duration for all bindings in an action map.
-map.ApplyParameterOverride("tap:duration", 0.5f);
-
-// Set tap duration for all bindings in an entire asset.
-asset.ApplyParameterOverride("tap:duration", 0.5f);
-
-// Like for GetParameterValue, overloads are available that take
-// an expression instead.
-action.ApplyParameterOverride((TapInteraction x) => x.duration, 0.4f);
-map.ApplyParameterOverride((TapInteraction x) => x.duration, 0.4f);
-asset.ApplyParameterOverride((TapInteraction x) => x.duration, 0.4f);
-```
-
-The new value will be applied immediately and affect all composites, processors, and interactions already in use and targeted by the override.
-
-Note that if multiple parameter overrides are applied – especially when applying some directly to actions and some to maps or assets –, there may be conflicts between which override to apply. In this case, an attempt is made to chose the "most specific" override to apply.
-
-```CSharp
-// Let's say you have an InputAction `action` that is part of an InputActionAsset asset.
-var map = action.actionMap;
-var asset = map.asset;
-
-// And you apply a "tap:duration" override to the action.
-action.ApplyParameterOverride("tap:duration", 0.6f);
-
-// But also apply a "tap:duration" override to the action specifically
-// for bindings in the "Gamepad" group.
-action.ApplyParameterOverride("tap:duration", 1f, InputBinding.MaskByGroup("Gamepad"));
-
-// And finally also apply a "tap:duration" override to the entire asset.
-asset.ApplyParameterOverride("tap:duration", 0.3f);
-
-// Now, bindings on `action` in the "Gamepad" group will use a value of 1 for tap durations,
-// other bindings on `action` will use 0.6, and every other binding in the asset will use 0.3.
-```
-
-You can use parameter overrides, for example, to scale mouse delta values on a "Look" action.
-
-```CSharp
-// Set up an example "Look" action.
-var look = new InputAction("look", type: InputActionType.Value);
-look.AddBinding("/delta", groups: "KeyboardMouse", processors: "scaleVector2");
-look.AddBinding("/rightStick", groups: "Gamepad", processors: "scaleVector2");
-
-// Now you can adjust stick sensitivity separately from mouse sensitivity.
-look.ApplyParameterOverride("scaleVector2:x", 0.5f, InputBinding.MaskByGroup("KeyboardMouse"));
-look.ApplyParameterOverride("scaleVector2:y", 0.5f, InputBinding.MaskByGroup("KeyboardMouse"));
-
-look.ApplyParameterOverride("scaleVector2:x", 2f, InputBinding.MaskByGroup("Gamepad"));
-look.ApplyParameterOverride("scaleVector2:y", 2f, InputBinding.MaskByGroup("Gamepad"));
-
-// Alternative to using groups, you can also apply overrides directly to specific binding paths.
-look.ApplyParameterOverride("scaleVector2:x", 0.5f, new InputBinding("/delta"));
-look.ApplyParameterOverride("scaleVector2:y", 0.5f, new InputBinding("/delta"));
-```
-
->NOTE: Parameter overrides are *not* persisted along with an asset.
-
-## Interactive rebinding
-
->__Note:__ To download a sample project which demonstrates how to set up a rebinding user interface with Input System APIs, open the Package Manager, select the Input System Package, and choose the sample project "Rebinding UI" to download.
-
-Runtime rebinding allows users of your application to set their own Bindings.
-
-To allow users to choose their own Bindings interactively, use the [`InputActionRebindingExtensions.RebindingOperation`](../api/UnityEngine.InputSystem.InputActionRebindingExtensions.RebindingOperation.html) class. Call the [`PerformInteractiveRebinding()`](../api/UnityEngine.InputSystem.InputActionRebindingExtensions.html#UnityEngine_InputSystem_InputActionRebindingExtensions_PerformInteractiveRebinding_UnityEngine_InputSystem_InputAction_System_Int32_) method on an Action to create a rebinding operation. This operation waits for the Input System to register any input from any Device which matches the Action's expected Control type, then uses [`InputBinding.overridePath`](../api/UnityEngine.InputSystem.InputBinding.html#UnityEngine_InputSystem_InputBinding_overridePath) to assign the Control path for that Control to the Action's Bindings. If the user actuates multiple Controls, the rebinding operation chooses the Control with the highest [magnitude](Controls.md#control-actuation).
-
->IMPORTANT: You must dispose of [`InputActionRebindingExtensions.RebindingOperation`](../api/UnityEngine.InputSystem.InputActionRebindingExtensions.RebindingOperation.html) instances via `Dispose()`, so that they don't leak memory on the unmanaged memory heap.
-
-```C#
- void RemapButtonClicked(InputAction actionToRebind)
- {
- var rebindOperation = actionToRebind
- .PerformInteractiveRebinding().Start();
- }
-```
-
-The [`InputActionRebindingExtensions.RebindingOperation`](../api/UnityEngine.InputSystem.InputActionRebindingExtensions.RebindingOperation.html) API is highly configurable to match your needs. For example, you can:
-
-* Choose expected Control types ([`WithExpectedControlType()`](../api/UnityEngine.InputSystem.InputActionRebindingExtensions.RebindingOperation.html#UnityEngine_InputSystem_InputActionRebindingExtensions_RebindingOperation_WithExpectedControlType_System_Type_)).
-
-* Exclude certain Controls ([`WithControlsExcluding()`](../api/UnityEngine.InputSystem.InputActionRebindingExtensions.RebindingOperation.html#UnityEngine_InputSystem_InputActionRebindingExtensions_RebindingOperation_WithControlsExcluding_System_String_)).
-
-* Set a Control to cancel the operation ([`WithCancelingThrough()`](../api/UnityEngine.InputSystem.InputActionRebindingExtensions.RebindingOperation.html#UnityEngine_InputSystem_InputActionRebindingExtensions_RebindingOperation_WithCancelingThrough_UnityEngine_InputSystem_InputControl_)).
-
-* Choose which Bindings to apply the operation on if the Action has multiple Bindings ([`WithTargetBinding()`](../api/UnityEngine.InputSystem.InputActionRebindingExtensions.RebindingOperation.html#UnityEngine_InputSystem_InputActionRebindingExtensions_RebindingOperation_WithTargetBinding_System_Int32_), [`WithBindingGroup()`](../api/UnityEngine.InputSystem.InputActionRebindingExtensions.RebindingOperation.html#UnityEngine_InputSystem_InputActionRebindingExtensions_RebindingOperation_WithBindingGroup_System_String_), [`WithBindingMask()`](../api/UnityEngine.InputSystem.InputActionRebindingExtensions.RebindingOperation.html#UnityEngine_InputSystem_InputActionRebindingExtensions_RebindingOperation_WithBindingMask_System_Nullable_UnityEngine_InputSystem_InputBinding__)).
-
-Refer to the scripting API reference for [`InputActionRebindingExtensions.RebindingOperation`](../api/UnityEngine.InputSystem.InputActionRebindingExtensions.RebindingOperation.html) for a full overview.
-
-Note that [`PerformInteractiveRebinding()`](../api/UnityEngine.InputSystem.InputActionRebindingExtensions.html#UnityEngine_InputSystem_InputActionRebindingExtensions_PerformInteractiveRebinding_UnityEngine_InputSystem_InputAction_System_Int32_) automatically applies a set of default configurations based on the given action and targeted binding.
-
-## Saving and loading rebinds
-
-You can serialize override properties of [Bindings](../api/UnityEngine.InputSystem.InputBinding.html) by serializing them as JSON strings and restoring them from these. Use [`SaveBindingOverridesAsJson`](../api/UnityEngine.InputSystem.InputActionRebindingExtensions.html#UnityEngine_InputSystem_InputActionRebindingExtensions_SaveBindingOverridesAsJson_UnityEngine_InputSystem_IInputActionCollection2_) to create these strings and [`LoadBindingOverridesFromJson`](../api/UnityEngine.InputSystem.InputActionRebindingExtensions.html#UnityEngine_InputSystem_InputActionRebindingExtensions_LoadBindingOverridesFromJson_UnityEngine_InputSystem_IInputActionCollection2_System_String_System_Boolean_) to restore overrides from them.
-
-```CSharp
-// Store player rebinds in PlayerPrefs.
-var rebinds = playerInput.actions.SaveBindingOverridesAsJson();
-PlayerPrefs.SetString("rebinds", rebinds);
-
-// Restore player rebinds from PlayerPrefs (removes all existing
-// overrides on the actions; pass `false` for second argument
-// in case you want to prevent that).
-var rebinds = PlayerPrefs.GetString("rebinds");
-playerInput.actions.LoadBindingOverridesFromJson(rebinds);
-```
-
-### Restoring original Bindings
-
-You can remove Binding overrides and thus restore defaults by using [`RemoveBindingOverride`](../api/UnityEngine.InputSystem.InputActionRebindingExtensions.html#UnityEngine_InputSystem_InputActionRebindingExtensions_RemoveBindingOverride_UnityEngine_InputSystem_InputAction_System_Int32_) or [`RemoveAllBindingOverrides`](../api/UnityEngine.InputSystem.InputActionRebindingExtensions.html#UnityEngine_InputSystem_InputActionRebindingExtensions_RemoveAllBindingOverrides_UnityEngine_InputSystem_IInputActionCollection2_).
-
-```CSharp
-// Remove binding overrides from the first binding of the "fire" action.
-playerInput.actions["fire"].RemoveBindingOverride(0);
-
-// Remove all binding overrides from the "fire" action.
-playerInput.actions["fire"].RemoveAllBindingOverrides();
-
-// Remove all binding overrides from a player's actions.
-playerInput.actions.RemoveAllBindingOverrides();
-```
-
-### Displaying Bindings
-
-It can be useful for the user to know what an Action is currently bound to (taking any potentially active rebindings into account) while rebinding UIs, and for on-screen hints while the app is running. You can use [`InputBinding.effectivePath`](../api/UnityEngine.InputSystem.InputBinding.html#UnityEngine_InputSystem_InputBinding_effectivePath) to get the currently active path for a Binding (which returns [`overridePath`](../api/UnityEngine.InputSystem.InputBinding.html#UnityEngine_InputSystem_InputBinding_overridePath) if set, or otherwise returns [`path`](../api/UnityEngine.InputSystem.InputBinding.html#UnityEngine_InputSystem_InputBinding_path)).
-
-The easiest way to retrieve a display string for an action is to call [`InputActionRebindingExtensions.GetBindingDisplayString`](../api/UnityEngine.InputSystem.InputActionRebindingExtensions.html#UnityEngine_InputSystem_InputActionRebindingExtensions_GetBindingDisplayString_) which is an extension method for [`InputAction`](../api/UnityEngine.InputSystem.InputAction.html).
-
-```CSharp
- // Get a binding string for the action as a whole. This takes into account which
- // bindings are currently active and the actual controls bound to the action.
- m_RebindButton.GetComponentInChildren().text = action.GetBindingDisplayString();
-
- // Get a binding string for a specific binding on an action by index.
- m_RebindButton.GetComponentInChildren().text = action.GetBindingDisplayString(1);
-
- // Look up binding indices with GetBindingIndex.
- var bindingIndex = action.GetBindingIndex(InputBinding.MaskByGroup("Gamepad"));
- m_RebindButton.GetComponentInChildren().text =
- action.GetBindingDisplayString(bindingIndex);
-```
-
-You can also use this method to replace the text string with images.
-
-```CSharp
- // Call GetBindingDisplayString() such that it also returns information about the
- // name of the device layout and path of the control on the device. This information
- // is useful for reliably associating imagery with individual controls.
- // NOTE: The first argument is the index of the binding within InputAction.bindings.
- var bindingString = action.GetBindingDisplayString(0, out deviceLayout, out controlPath);
-
- // If it's a gamepad, look up an icon for the control.
- Sprite icon = null;
- if (!string.IsNullOrEmpty(deviceLayout)
- && !string.IsNullOrEmpty(controlPath)
- && InputSystem.IsFirstLayoutBasedOnSecond(deviceLayout, "Gamepad"))
- {
- switch (controlPath)
- {
- case "buttonSouth": icon = aButtonIcon; break;
- case "dpad/up": icon = dpadUpIcon; break;
- //...
- }
- }
-
- // If you have an icon, display it instead of the text.
- var text = m_RebindButton.GetComponentInChildren();
- var image = m_RebindButton.GetComponentInChildren();
- if (icon != null)
- {
- // Display icon.
- text.gameObject.SetActive(false);
- image.gameObject.SetActive(true);
- image.sprite = icon;
- }
- else
- {
- // Display text.
- text.gameObject.SetActive(true);
- image.gameObject.SetActive(false);
- text.text = bindingString;
- }
-```
-
-Additionally, each Binding has a [`ToDisplayString`](../api/UnityEngine.InputSystem.InputBinding.html#UnityEngine_InputSystem_InputBinding_ToDisplayString_UnityEngine_InputSystem_InputBinding_DisplayStringOptions_UnityEngine_InputSystem_InputControl_) method, which you can use to turn individual Bindings into display strings. There is also a generic formatting method for Control paths, [`InputControlPath.ToHumanReadableString`](../api/UnityEngine.InputSystem.InputControlPath.html#UnityEngine_InputSystem_InputControlPath_ToHumanReadableString_System_String_UnityEngine_InputSystem_InputControlPath_HumanReadableStringOptions_UnityEngine_InputSystem_InputControl_), which you can use with arbitrary Control path strings.
-
-Note that the Controls a Binding resolves to can change at any time, and the display strings for controls might change dynamically. For example, if the user switches the currently active keyboard layout, the display string for each individual key on the [`Keyboard`](../api/UnityEngine.InputSystem.Keyboard.html) might change.
-
-## Control Schemes
-
-A Binding can belong to any number of Binding groups. Unity stores these on the [`InputBinding`](../api/UnityEngine.InputSystem.InputBinding.html) class as a semicolon-separated string in the [`InputBinding.groups`](../api/UnityEngine.InputSystem.InputBinding.html#UnityEngine_InputSystem_InputBinding_groups) property, and you can use them for any arbitrary grouping of bindings. To enable different sets of binding groups for an [`InputActionMap`](../api/UnityEngine.InputSystem.InputActionMap.html) or [`InputActionAsset`](../api/UnityEngine.InputSystem.InputActionAsset.html), you can use the [`InputActionMap.bindingMask`](../api/UnityEngine.InputSystem.InputActionMap.html#UnityEngine_InputSystem_InputActionMap_bindingMask)/[`InputActionAsset.bindingMask`](../api/UnityEngine.InputSystem.InputActionAsset.html#UnityEngine_InputSystem_InputActionAsset_bindingMask) property. The Input System uses this to implement the concept of grouping Bindings into different [`InputControlSchemes`](../api/UnityEngine.InputSystem.InputControlScheme.html).
-
-Control Schemes use Binding groups to map Bindings in an [`InputActionMap`](../api/UnityEngine.InputSystem.InputActionMap.html) or [`InputActionAsset`](../api/UnityEngine.InputSystem.InputActionAsset.html) to different types of Devices. The [`PlayerInput`](PlayerInput.md) class uses these to enable a matching Control Scheme for a new [user](UserManagement.md) joining the game, based on the Device they are playing on.
-
-## Details
-
-### Binding resolution
-
-When the Input System accesses the [Controls](Controls.md) bound to an Action for the first time, the Action resolves its Bindings to match them to existing Controls on existing Devices. In this process, the Action calls [`InputSystem.FindControls<>()`](../api/UnityEngine.InputSystem.InputSystem.html#UnityEngine_InputSystem_InputSystem_FindControls__1_System_String_UnityEngine_InputSystem_InputControlList___0___) (filtering for devices assigned to the InputActionMap, if there are any) for the Binding path of each of the Action's bindings. This creates a list of resolved Controls that are now bound to the Action.
-
-Note that a single [Binding path](Controls.md#control-paths) can match multiple Controls:
-
-* A specific Device path such as `/buttonEast` matches the "Circle" button on a [PlayStation controller](Gamepad.md#playstation-controllers). If you have multiple PlayStation controllers connected, it resolves to the "Circle" button on each of these controllers.
-
-* An abstract Device path such as `/buttonEast` matches the right action button on any connected gamepad. If you have a PlayStation controller and an [Xbox controller](Gamepad.md#xbox-controllers) connected, it resolves to the "Circle" button on the PlayStation controller, and to the "B" button on the Xbox controller.
-
-* A Binding path can also contain wildcards, such as `/button*`. This matches any Control on any gamepad with a name starting with "button", which matches all the four action buttons on any connected gamepad. A different example: `*/{Submit}` matches any Control tagged with the "Submit" [usage](Controls.md#control-usages) on any Device.
-
-If there are multiple Bindings on the same Action that all reference the same Control(s), the Control will effectively feed into the Action multiple times. This is to allow, for example, a single Control to produce different input on the same Action by virtue of being bound in a different fashion (composites, processors, interactions, etc). However, regardless of how many times a Control is bound on any given action, it will only be mentioned once in the Action's [array of `controls`](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_controls).
-
-To query the Controls that an Action resolves to, you can use [`InputAction.controls`](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_controls). You can also run this query if the Action is disabled.
-
-To be notified when binding resolution happens, you can listen to [`InputSystem.onActionChange`](../api/UnityEngine.InputSystem.InputSystem.html#UnityEngine_InputSystem_InputSystem_onActionChange) which triggers [`InputActionChange.BoundControlsAboutToChange`](../api/UnityEngine.InputSystem.InputActionChange.html#UnityEngine_InputSystem_InputActionChange_BoundControlsAboutToChange) before modifying Control lists and triggers [`InputActionChange.BoundControlsChanged`](../api/UnityEngine.InputSystem.InputActionChange.html#UnityEngine_InputSystem_InputActionChange_BoundControlsChanged) after having updated them.
-
-#### Binding resolution while Actions are enabled
-
-In certain situations, the [Controls](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_controls) bound to an Action have to be updated more than once. For example, if a new [Device](Devices.md) becomes usable with an Action, the Action may now pick up input from additional controls. Also, if Bindings are added, removed, or modified, Control lists will need to be updated.
-
-This updating of Controls usually happens transparently in the background. However, when an Action is [enabled](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_enabled) and especially when it is [in progress](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_IsInProgress_), there may be a noticeable effect on the Action.
-
-Adding or removing a device – either [globally](../api/UnityEngine.InputSystem.InputSystem.html#UnityEngine_InputSystem_InputSystem_devices) or to/from the [device list](../api/UnityEngine.InputSystem.InputActionAsset.html#UnityEngine_InputSystem_InputActionAsset_devices) of an Action – will remain transparent __except__ if an Action is in progress and it is the device of its [active Control](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_activeControl) that is being removed. In this case, the Action will automatically be [cancelled](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_canceled).
-
-Modifying the [binding mask](../api/UnityEngine.InputSystem.InputActionAsset.html#UnityEngine_InputSystem_InputActionAsset_bindingMask) or modifying any of the Bindings (such as through [rebinding](#interactive-rebinding) or by adding or removing bindings) will, however, lead to all enabled Actions being temporarily disabled and then re-enabled and resumed.
-
-#### Choosing which Devices to use
-
->__Note__: [`InputUser`](UserManagement.md) and [`PlayerInput`](PlayerInput.md) make use of this facility automatically. They set [`InputActionMap.devices`](../api/UnityEngine.InputSystem.InputActionMap.html#UnityEngine_InputSystem_InputActionMap_devices) automatically based on the Devices that are paired to the user.
-
-By default, Actions resolve their Bindings against all Devices present in the Input System (that is, [`InputSystem.devices`](../api/UnityEngine.InputSystem.InputSystem.html#UnityEngine_InputSystem_InputSystem_devices)). For example, if there are two gamepads present in the system, a Binding to `/buttonSouth` picks up both gamepads and allows the Action to be used from either.
-
-You can override this behavior by restricting [`InputActionAssets`](../api/UnityEngine.InputSystem.InputActionAsset.html) or individual [`InputActionMaps`](../api/UnityEngine.InputSystem.InputActionMap.html) to a specific set of Devices. If you do this, Binding resolution only takes the Controls of the given Devices into account.
-
-```
- var actionMap = new InputActionMap();
-
- // Restrict the action map to just the first gamepad.
- actionMap.devices = new[] { Gamepad.all[0] };
-```
-
-### Conflicting inputs
-
-There are two situations where a given input may lead to ambiguity:
-
-1. Several Controls are bound to the same Action and more than one is feeding input into the Action at the same time. Example: an Action that is bound to both the left and right trigger on a Gamepad and both triggers are pressed.
-2. The input is part of a sequence of inputs and there are several possible such sequences. Example: one Action is bound to the `B` key and another Action is bound to `Shift-B`.
-
-#### Multiple, concurrently used Controls
-
->__Note:__ This section does not apply to [`PassThrough`](RespondingToActions.md#pass-through) Actions as they are by design meant to allow multiple concurrent inputs.
-
-For a [`Button`](RespondingToActions.md#button) or [`Value`](RespondingToActions.md#value) Action, there can only be one Control at any time that is "driving" the Action. This Control is considered the [`activeControl`](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_activeControl).
-
-When an Action is bound to multiple Controls, the [`activeControl`](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_activeControl) at any point is the one with the greatest level of ["actuation"](Controls.md#control-actuation), that is, the largest value returned from [`EvaluateMagnitude`](../api/UnityEngine.InputSystem.InputControl.html#UnityEngine_InputSystem_InputControl_EvaluateMagnitude_). If a Control exceeds the actuation level of the current [`activeControl`](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_activeControl), it will itself become the active Control.
-
-The following example demonstrates this mechanism with a [`Button`](RespondingToActions.md#button) Action and also demonstrates the difference to a [`PassThrough`](RespondingToActions.md#pass-through) Action.
-
-```CSharp
-// Create a button and a pass-through action and bind each of them
-// to both triggers on the gamepad.
-var buttonAction = new InputAction(type: InputActionType.Button,
- binding: "/*Trigger");
-var passThroughAction = new InputAction(type: InputActionType.PassThrough,
- binding: "/*Trigger");
-
-buttonAction.performed += c => Debug.Log("${c.control.name} pressed (Button)");
-passThroughAction.performed += c => Debug.Log("${c.control.name} changed (Pass-Through)");
-
-buttonAction.Enable();
-passThroughAction.Enable();
-
-// Press the left trigger all the way down.
-// This will trigger both buttonAction and passThroughAction. Both will
-// see leftTrigger becoming the activeControl.
-Set(gamepad.leftTrigger, 1f);
-
-// Will log
-// "leftTrigger pressed (Button)" and
-// "leftTrigger changed (Pass-Through)"
-
-// Press the right trigger halfway down.
-// This will *not* trigger or otherwise change buttonAction as the right trigger
-// is actuated *less* than the left one that is already driving action.
-// However, passThrough action is not performing such tracking and will thus respond
-// directly to the value change. It will perform and make rightTrigger its activeControl.
-Set(gamepad.rightTrigger, 0.5f);
-
-// Will log
-// "rightTrigger changed (Pass-Through)"
-
-// Release the left trigger.
-// For buttonAction, this will mean that now all controls feeding into the action have
-// been released and thus the button releases. activeControl will go back to null.
-// For passThrough action, this is just another value change. So, the action performs
-// and its active control changes to leftTrigger.
-Set(gamepad.leftTrigger, 0f);
-
-// Will log
-// "leftTrigger changed (Pass-Through)"
-```
-
-For [composite bindings](#composite-bindings), magnitudes of the composite as a whole rather than for individual Controls are tracked. However, [`activeControl`](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_activeControl) will stick track individual Controls from the composite.
-
-##### Disabling Conflict Resolution
-
-Conflict resolution is always applied to [Button](RespondingToActions.md#button) and [Value](RespondingToActions.md#value) type Actions. However, it can be undesirable in situations when an Action is simply used to gather any and all inputs from bound Controls. For example, the following Action would monitor the A button of all available gamepads:
-
-```CSharp
-var action = new InputAction(type: InputActionType.PassThrough, binding: "/buttonSouth");
-action.Enable();
-```
-
-By using the [Pass-Through](RespondingToActions.md#pass-through) Action type, conflict resolution is bypassed and thus, pressing the A button on one gamepad will not result in a press on a different gamepad being ignored.
-
-#### Multiple input sequences (such as keyboard shortcuts)
-
->__Note__: The mechanism described here only applies to Actions that are part of the same [`InputActionMap`](../api/UnityEngine.InputSystem.InputActionMap.html) or [`InputActionAsset`](../api/UnityEngine.InputSystem.InputActionAsset.html).
-
-Inputs that are used in combinations with other inputs may also lead to ambiguities. If, for example, the `b` key on the Keyboard is bound both on its own as well as in combination with the `shift` key, then if you first press `shift` and then `b`, the latter key press would be a valid input for either of the Actions.
-
-The way this is handled is that Bindings will be processed in the order of decreasing "complexity". This metric is derived automatically from the Binding:
-
-* A binding that is *not* part of a [composite](#composite-bindings) is assigned a complexity of 1.
-* A binding that *is* part of a [composite](#composite-bindings) is assigned a complexity equal to the number of part bindings in the composite.
-
-In our example, this means that a [`OneModifier`](#one-modifier) composite Binding to `Shift+B` has a higher "complexity" than a Binding to `B` and thus is processed first.
-
-Additionally, the first Binding that results in the Action changing [phase](RespondingToActions.md#action-callbacks) will "consume" the input. This consuming will result in other Bindings to the same input not being processed. So in our example, when `Shift+B` "consumes" the `B` input, the Binding to `B` will be skipped.
-
-The following example illustrates how this works at the API level.
-
-```CSharp
-// Create two actions in the same map.
-var map = new InputActionMap();
-var bAction = map.AddAction("B");
-var shiftbAction = map.AddAction("ShiftB");
-
-// Bind one of the actions to 'B' and the other to 'SHIFT+B'.
-bAction.AddBinding("/b");
-shiftbAction.AddCompositeBinding("OneModifier")
- .With("Modifier", "/shift")
- .With("Binding", "/b");
-
-// Print something to the console when the actions are triggered.
-bAction.performed += _ => Debug.Log("B action performed");
-shiftbAction.performed += _ => Debug.Log("SHIFT+B action performed");
-
-// Start listening to input.
-map.Enable();
-
-// Now, let's assume the left shift key on the keyboard is pressed (here, we manually
-// press it with the InputTestFixture API).
-Press(Keyboard.current.leftShiftKey);
-
-// And then the B is pressed. This is a valid input for both
-// bAction as well as shiftbAction.
-//
-// What will happen now is that shiftbAction will do its processing first. In response,
-// it will *perform* the action (i.e. we see the `performed` callback being invoked) and
-// thus "consume" the input. bAction will stay silent as it will in turn be skipped over.
-Press(keyboard.bKey);
-```
-
-### Initial state check
-
-After an Action is [enabled](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_enabled), it will start reacting to input as it comes in. However, at the time the Action is enabled, one or more of the Controls that are [bound](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_controls) to an action may already have a non-default state at that point.
-x
-Using what is referred to as an "initial state check", an Action can be made to respond to such a non-default state as if the state change happened *after* the Action was enabled. The way this works is that in the first input [update](../api/UnityEngine.InputSystem.InputSystem.html#UnityEngine_InputSystem_InputSystem_Update_) after the Action was enabled, all its bound controls are checked in turn. If any of them has a non-default state, the Action responds right away.
-
-This check is implicitly enabled for [Value](RespondingToActions.md#value) actions. If, for example, you have a `Move` Action bound to the left stick on the gamepad and the stick is already pushed in a direction when `Move` is enabled, the character will immediately start walking.
-
-By default, [Button](RespondingToActions.md#button) and [Pass-Through](RespondingToActions.md#pass-through) type Actions, do not perform this check. A button that is pressed when its respective Action is enabled first needs to be released and then pressed again for it to trigger the Action.
-
-However, you can manually enable initial state checks on these types of Actions using the checkbox in the editor:
-
-
diff --git a/Packages/com.unity.inputsystem/Documentation~/Actions.md b/Packages/com.unity.inputsystem/Documentation~/Actions.md
index 780d0e2ddc..bbb3e2a5ec 100644
--- a/Packages/com.unity.inputsystem/Documentation~/Actions.md
+++ b/Packages/com.unity.inputsystem/Documentation~/Actions.md
@@ -3,13 +3,13 @@ uid: input-system-actions
---
# Actions
-**Actions** are an important concept in the Input System. They allow you to separate the purpose of an input from the device controls which perform that input. Actions allow you to associate the purpose and device controls together in a flexible way.
+**Actions** allow you to separate the purpose of an input from the device controls which perform that input, and associate the purpose and device controls together in a flexible way.
-For example, the purpose of an input in a game might be to make the player's character move around. The device control associated with that action might be the motion of the left gamepad stick.
+For example, the purpose of an input in a game might be to make the player's character move. The device control associated with that action might be the left gamepad stick.
The association between an Action and the device controls which perform that input is a **binding**, and you can set up bindings in the [Input Actions editor](ActionsEditor.md). When you use Actions in your code, you do not need to refer to specific devices because the binding defines which device's controls are used to perform the action.
-To use actions in your code, you must use the [Input Actions editor](ActionsEditor.md) to establish the mapping between the Action and one or more device controls. For example in this screenshot, the "Move" action is displayed, showing its bindings the left gamepad stick, and the keyboard's arrow keys.
+To use actions in your code, you must use the [Input Actions editor](ActionsEditor.md) to configure the mapping between the Action and one or more device controls. For example in this screenshot, the "Move" action is displayed, showing its bindings the left gamepad stick, and the keyboard's arrow keys.
/leftStick");
-var moveAction = new InputAction("move", binding: "/rightStick");
-
-lookAction.AddBinding("/delta");
-moveAction.AddCompositeBinding("Dpad")
- .With("Up", "/w")
- .With("Down", "/s")
- .With("Left", "/a")
- .With("Right", "/d");
-
-// Create an Action Map with Actions.
-var map = new InputActionMap("Gameplay");
-var lookAction = map.AddAction("look");
-lookAction.AddBinding("/leftStick");
-
-// Create an Action Asset.
-var asset = ScriptableObject.CreateInstance();
-var gameplayMap = new InputActionMap("gameplay");
-asset.AddActionMap(gameplayMap);
-var lookAction = gameplayMap.AddAction("look", "/leftStick");
-```
-
-Any action that you create in this way during Play mode do not persist in the Input Action Asset after you exit Play mode. This means you can test your application in a realistic manner in the Editor without having to worry about inadvertently modifying the asset.
-
-
-## Enabling actions
-
-Actions have an **enabled** state, meaning you can enable or disable them to suit different situations.
-
-If you have an Action Asset assigned as [project-wide](./ProjectWideActions.md), the actions it contains are enabled by default and ready to use.
-
-For actions defined elsewhere, such as in an Action Asset not assigned as project-wide, or defined your own code, they begin in a disabled state, and you must enable them before they will respond to input.
-
-You can enable actions individually, or as a group by enabling the Action Map which contains them.
-
-```CSharp
-// Enable a single action.
-lookAction.Enable();
-
-// Enable an en entire action map.
-gameplayActions.Enable();
-```
-
-When you enable an Action, the Input System resolves its bindings, unless it has done so already, or if the set of devices that the Action can use has not changed. For more details about this process, see the documentation on [binding resolution](ActionBindings.md#binding-resolution).
-
-You can't change certain aspects of the configuration, such Action Bindings, while an Action is enabled. To stop Actions or Action Maps from responding to input, call [`Disable`](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_Disable).
-
-While enabled, an Action actively monitors the [Control(s)](Controls.md) it's bound to. If a bound Control changes state, the Action processes the change. If the Control's change represents an [Interaction](Interactions.md) change, the Action creates a response. All of this happens during the Input System update logic. Depending on the [update mode](Settings.md#update-mode) selected in the input settings, this happens once every frame, once every fixed update, or manually if updates are set to manual.
diff --git a/Packages/com.unity.inputsystem/Documentation~/Architecture.md b/Packages/com.unity.inputsystem/Documentation~/Architecture.md
index 427ab04ac5..758db9c7ba 100644
--- a/Packages/com.unity.inputsystem/Documentation~/Architecture.md
+++ b/Packages/com.unity.inputsystem/Documentation~/Architecture.md
@@ -27,8 +27,8 @@ The low-level system code also contains structs which describe the data layout o
-The high-level Input System code interprets the data in a Device's state buffers by using [layouts](Layouts.md), which describe the data layout of a Device and its Controls in memory. The Input System creates layouts from either the pre-defined structs of commonly known Devices supplied by the low level system, or dynamically at runtime, as in the case of [generic HIDs](HID.md#auto-generated-layouts).
+The high-level Input System code interprets the data in a Device's state buffers by using [layouts](layouts.md), which describe the data layout of a Device and its Controls in memory. The Input System creates layouts from either the pre-defined structs of commonly known Devices supplied by the low level system, or dynamically at runtime, as in the case of [generic HIDs](HID.md#auto-generated-layouts).
Based on the information in the layouts, the Input System then creates [Control](Controls.md) representations for each of the Device's controls, which let you read the state of each individual Control in a Device.
-As part of the high-level system, you can also build another abstraction layer to map Input Controls to your application mechanics. Use [Actions](Actions.md) to [bind](ActionBindings.md) one or more Controls to an input in your application. The Input System then monitors these Controls for state changes, and notifies your game logic using [callbacks](RespondingToActions.md#responding-to-actions-using-callbacks). You can also specify more complex behaviors for your Actions using [Processors](Processors.md) (which perform processing on the input data before sending it to you) and [Interactions](Interactions.md) (which let you specify patterns of input on a Control to listen to, such as multi-taps).
+As part of the high-level system, you can also build another abstraction layer to map Input Controls to your application mechanics. Use [Actions](actions.md) to [bind](ActionBindings.md) one or more Controls to an input in your application. The Input System then monitors these Controls for state changes, and notifies your game logic using [callbacks](RespondingToActions.md#responding-to-actions-using-callbacks). You can also specify more complex behaviors for your Actions using [Processors](Processors.md) (which perform processing on the input data before sending it to you) and [Interactions](Interactions.md) (which let you specify patterns of input on a Control to listen to, such as multi-taps).
diff --git a/Packages/com.unity.inputsystem/Documentation~/Controls.md b/Packages/com.unity.inputsystem/Documentation~/Controls.md
index 19292386ea..db21787921 100644
--- a/Packages/com.unity.inputsystem/Documentation~/Controls.md
+++ b/Packages/com.unity.inputsystem/Documentation~/Controls.md
@@ -3,15 +3,15 @@ uid: input-system-controls
---
# Controls
-* [Hierarchies](#control-hierarchies)
-* [Types](#control-types)
-* [Usages](#control-usages)
-* [Paths](#control-paths)
-* [State](#control-state)
-* [Actuation](#control-actuation)
-* [Noisy Controls](#noisy-controls)
-* [Synthetic Controls](#synthetic-controls)
-* [Performance Optimization](#performance-optimization)
+- [Control paths](#control-paths)
+- [Control state](#control-state)
+- [Control actuation](#control-actuation)
+- [Noisy Controls](#noisy-controls)
+- [Synthetic Controls](#synthetic-controls)
+- [Performance Optimization](#performance-optimization)
+ - [Avoiding defensive copies](#avoiding-defensive-copies)
+ - [Control Value Caching](#control-value-caching)
+ - [Optimized control read value](#optimized-control-read-value)
An Input Control represents a source of values. These values can be of any structured or primitive type. The only requirement is that the type is [blittable](https://docs.microsoft.com/en-us/dotnet/framework/interop/blittable-and-non-blittable-types).
@@ -23,263 +23,6 @@ Additionally, a Control might have one or more aliases which provide alternative
Finally, a Control might also have a short display name which can be accessed through the [`InputControl.shortDisplayName`](../api/UnityEngine.InputSystem.InputControl.html#UnityEngine_InputSystem_InputControl_shortDisplayName) property. For example, the short display name for the left mouse button is "LMB".
-## Control hierarchies
-Controls can form hierarchies. The root of a Control hierarchy is always a [Device](Devices.md).
-The setup of hierarchies is exclusively controlled through [layouts](Layouts.md).
-You can access the parent of a Control using [`InputControl.parent`](../api/UnityEngine.InputSystem.InputControl.html#UnityEngine_InputSystem_InputControl_parent), and its children using [`InputControl.children`](../api/UnityEngine.InputSystem.InputControl.html#UnityEngine_InputSystem_InputControl_children). To access the flattened hierarchy of all Controls on a Device, use [`InputDevice.allControls`](../api/UnityEngine.InputSystem.InputDevice.html#UnityEngine_InputSystem_InputDevice_allControls).
-
-## Control types
-
-All controls are based on the [`InputControl`](../api/UnityEngine.InputSystem.InputControl.html) base class. Most concrete implementations are based on [`InputControl`](../api/UnityEngine.InputSystem.InputControl-1.html).
-
-The Input System provides the following types of controls out of the box:
-
-|Control Type|Description|Example|
-|------------|-----------|-------|
-|[`AxisControl`](../api/UnityEngine.InputSystem.Controls.AxisControl.html)|A 1D floating-point axis.|[`Gamepad.leftStick.x`](../api/UnityEngine.InputSystem.Controls.Vector2Control.html#UnityEngine_InputSystem_Controls_Vector2Control_x)|
-|[`ButtonControl`](../api/UnityEngine.InputSystem.Controls.ButtonControl.html)|A button expressed as a floating-point value. Whether the button can have a value other than 0 or 1 depends on the underlying representation. For example, gamepad trigger buttons can have values other than 0 and 1, but gamepad face buttons generally can't.|[`Mouse.leftButton`](../api/UnityEngine.InputSystem.Mouse.html#UnityEngine_InputSystem_Mouse_leftButton)|
-|[`KeyControl`](../api/UnityEngine.InputSystem.Controls.KeyControl.html)|A specialized button that represents a key on a [`Keyboard`](../api/UnityEngine.InputSystem.Keyboard.html). Keys have an associated [`keyCode`](../api/UnityEngine.InputSystem.Controls.KeyControl.html#UnityEngine_InputSystem_Controls_KeyControl_keyCode) and, unlike other types of Controls, change their display name in accordance to the currently active system-wide keyboard layout. See the [Keyboard](Keyboard.md) documentation for details.|[`Keyboard.aKey`](../api/UnityEngine.InputSystem.Keyboard.html#UnityEngine_InputSystem_Keyboard_aKey)|
-|[`Vector2Control`](../api/UnityEngine.InputSystem.Controls.Vector2Control.html)|A 2D floating-point vector.|[`Pointer.position`](../api/UnityEngine.InputSystem.Pointer.html#UnityEngine_InputSystem_Pointer_position)|
-|[`Vector3Control`](../api/UnityEngine.InputSystem.Controls.Vector3Control.html)|A 3D floating-point vector.|[`Accelerometer.acceleration`](../api/UnityEngine.InputSystem.Accelerometer.html#UnityEngine_InputSystem_Accelerometer_acceleration)|
-|[`QuaternionControl`](../api/UnityEngine.InputSystem.Controls.QuaternionControl.html)|A 3D rotation.|[`AttitudeSensor.attitude`](../api/UnityEngine.InputSystem.AttitudeSensor.html#UnityEngine_InputSystem_AttitudeSensor_attitude)|
-|[`IntegerControl`](../api/UnityEngine.InputSystem.Controls.IntegerControl.html)|An integer value.|[`Touchscreen.primaryTouch.touchId`](../api/UnityEngine.InputSystem.Controls.TouchControl.html#UnityEngine_InputSystem_Controls_TouchControl_touchId)|
-|[`StickControl`](../api/UnityEngine.InputSystem.Controls.StickControl.html)|A 2D stick control like the thumbsticks on gamepads or the stick control of a joystick.|[`Gamepad.rightStick`](../api/UnityEngine.InputSystem.Gamepad.html#UnityEngine_InputSystem_Gamepad_rightStick)|
-|[`DpadControl`](../api/UnityEngine.InputSystem.Controls.DpadControl.html)|A 4-way button control like the D-pad on gamepads or hatswitches on joysticks.|[`Gamepad.dpad`](../api/UnityEngine.InputSystem.Gamepad.html#UnityEngine_InputSystem_Gamepad_dpad)|
-|[`TouchControl`](../api/UnityEngine.InputSystem.Controls.TouchControl.html)|A control that represents all the properties of a touch on a [touch screen](Touch.md).|[`Touchscreen.primaryTouch`](../api/UnityEngine.InputSystem.Touchscreen.html#UnityEngine_InputSystem_Touchscreen_primaryTouch)|
-
-You can browse the set of all registered control layouts in the [input debugger](Debugging.md#debugging-layouts).
-
-## Control usages
-
-A Control can have one or more associated usages. A usage is a string that denotes the Control's intended use. An example of a Control usage is `Submit`, which labels a Control that is commonly used to confirm a selection in the UI. On a gamepad, this usage is commonly found on the `buttonSouth` Control.
-
-You can access a Control's usages using the [`InputControl.usages`](../api/UnityEngine.InputSystem.InputControl.html#UnityEngine_InputSystem_InputControl_usages) property.
-
-Usages can be arbitrary strings. However, a certain set of usages is very commonly used and comes predefined in the API in the form of the [`CommonUsages`](../api/UnityEngine.InputSystem.CommonUsages.html) static class. Check out the [`CommonUsages` scripting API page](../api/UnityEngine.InputSystem.CommonUsages.html) for an overview.
-
-## Control paths
-
->Example: `/leftStick/x` means "X Control on left stick of gamepad".
-
-The Input System can look up Controls using textual paths. [Bindings](ActionBindings.md) on Input Actions rely on this feature to identify the Control(s) they read input from. However, you can also use them for lookup directly on Controls and Devices, or to let the Input System search for Controls among all devices using [`InputSystem.FindControls`](../api/UnityEngine.InputSystem.InputSystem.html#UnityEngine_InputSystem_InputSystem_FindControls_System_String_).
-
-```CSharp
-var gamepad = Gamepad.all[0];
-var leftStickX = gamepad["leftStick/x"];
-var submitButton = gamepad["{Submit}"];
-var allSubmitButtons = InputSystem.FindControls("*/{Submit}");
-```
-
-Control paths resemble file system paths. Each path consists of one or more components separated by a forward slash:
-
- component/component...
-
-Each component uses a similar syntax made up of multiple fields. Each field is optional, but at least one field must be present. All fields are case-insensitive.
-
- {usageName}controlName#(displayName)
-
-The following table explains the use of each field:
-
-|Field|Description|Example|
-|-----|-----------|-------|
-|``|Requires the Control at the current level to be based on the given layout. The actual layout of the Control may be the same or a layout *based* on the given layout.|`/buttonSouth`|
-|`{usageName}`|Works differently for Controls and Devices.{LeftHand}/trigger`/{Submit}`|
-|`controlName`|Requires the Control at the current level to have the given name. Takes both "proper" names ([`InputControl.name`](../api/UnityEngine.InputSystem.InputControl.html#UnityEngine_InputSystem_InputControl_name)) and aliases ([`InputControl.aliases`](../api/UnityEngine.InputSystem.InputControl.html#UnityEngine_InputSystem_InputControl_aliases)) into account./#(a)` (matches the key that generates the "a" character, if any, according to the current keyboard layout)./#(Cross)`|
-
-You can access the literal path of a given control via its [`InputControl.path`](../api/UnityEngine.InputSystem.InputControl.html#UnityEngine_InputSystem_InputControl_path) property.
-
-If needed, you can manually parse a control path into its components using the [`InputControlPath.Parse(path)`](../api/UnityEngine.InputSystem.InputControlPath.html#UnityEngine_InputSystem_InputControlPath_Parse_System_String_) API.
-
-```CSharp
-var parsed = InputControlPath.Parse("{LeftHand}/trigger").ToArray();
-
-Debug.Log(parsed.Length); // Prints 2.
-Debug.Log(parsed[0].layout); // Prints "XRController".
-Debug.Log(parsed[0].name); // Prints an empty string.
-Debug.Log(parsed[0].usages.First()); // Prints "LeftHand".
-Debug.Log(parsed[1].layout); // Prints null.
-Debug.Log(parsed[1].name); // Prints "trigger".
-```
-
-## Control state
-
-Each Control is connected to a block of memory that is considered the Control's "state". You can query the size, format, and location of this block of memory from a Control through the [`InputControl.stateBlock`](../api/UnityEngine.InputSystem.InputControl.html#UnityEngine_InputSystem_InputControl_stateBlock) property.
-
-The state of Controls is stored in unmanaged memory that the Input System handles internally. All Devices added to the system share one block of unmanaged memory that contains the state of all the Controls on the Devices.
-
-A Control's state might not be stored in the natural format for that Control. For example, the system often represents buttons as bitfields, and axis controls as 8-bit or 16-bit integer values. This format is determined by the combination of platform, hardware, and drivers. Each Control knows the format of its storage and how to translate the values as needed. The Input System uses [layouts](Layouts.md) to understand this representation.
-
-You can access the current state of a Control through its [`ReadValue`](../api/UnityEngine.InputSystem.InputControl-1.html#UnityEngine_InputSystem_InputControl_1_ReadValue) method.
-
-```CSharp
-Gamepad.current.leftStick.x.ReadValue();
-```
-
-Each type of Control has a specific type of values that it returns, regardless of how many different types of formats it supports for its state. You can access this value type through the [`InputControl.valueType`](../api/UnityEngine.InputSystem.InputControl.html#UnityEngine_InputSystem_InputControl_valueType) property.
-
-Reading a value from a Control might apply one or more value Processors. See documentation on [Processors](Processors.md) for more information.
-
-[//]: # (#### Default State - TODO)
-
-[//]: # (#### Reading State vs Reading Values - TODO)
-
-#### Recording state history
-
-You might want to access the history of value changes on a Control (for example, in order to compute exit velocity on a touch release).
-
-To record state changes over time, you can use [`InputStateHistory`](../api/UnityEngine.InputSystem.LowLevel.InputStateHistory.html) or [`InputStateHistory`](../api/UnityEngine.InputSystem.LowLevel.InputStateHistory-1.html). The latter restricts Controls to those of a specific value type, which in turn simplifies some of the API.
-
-```CSharp
-// Create history that records Vector2 control value changes.
-// NOTE: You can also pass controls directly or use paths that match multiple
-// controls (e.g. "/").
-// NOTE: The unconstrained InputStateHistory class can record changes on controls
-// of different value types.
-var history = new InputStateHistory("/primaryTouch/position");
-
-// To start recording state changes of the controls to which the history
-// is attached, call StartRecording.
-history.StartRecording();
-
-// To stop recording state changes, call StopRecording.
-history.StopRecording();
-
-// Recorded history can be accessed like an array.
-for (var i = 0; i < history.Count; ++i)
-{
- // Each recorded value provides information about which control changed
- // value (in cases state from multiple controls is recorded concurrently
- // by the same InputStateHistory) and when it did so.
-
- var time = history[i].time;
- var control = history[i].control;
- var value = history[i].ReadValue();
-}
-
-// Recorded history can also be iterated over.
-foreach (var record in history)
- Debug.Log(record.ReadValue());
-Debug.Log(string.Join(",\n", history));
-
-// You can also record state changes manually, which allows
-// storing arbitrary histories in InputStateHistory.
-// NOTE: This records a value change that didn't actually happen on the control.
-history.RecordStateChange(Touchscreen.current.primaryTouch.position,
- new Vector2(0.123f, 0.234f));
-
-// State histories allocate unmanaged memory and need to be disposed.
-history.Dispose();
-```
-
-For example, if you want to have the last 100 samples of the left stick on the gamepad available, you can use this code:
-
-```CSharp
-var history = new InputStateHistory(Gamepad.current.leftStick);
-history.historyDepth = 100;
-history.StartRecording();
-```
-
-## Control actuation
-
-A Control is considered actuated when it has moved away from its default state in such a way that it affects the actual value of the Control. You can query whether a Control is currently actuated using [`IsActuated`](../api/UnityEngine.InputSystem.InputControlExtensions.html#UnityEngine_InputSystem_InputControlExtensions_IsActuated_UnityEngine_InputSystem_InputControl_System_Single_).
-
-```CSharp
-// Check if leftStick is currently actuated.
-if (Gamepad.current.leftStick.IsActuated())
- Debug.Log("Left Stick is actuated");
-```
-
-It can be useful to determine not just whether a Control is actuated at all, but also the amount by which it is actuated (that is, its magnitude). For example, for a [`Vector2Control`](../api/UnityEngine.InputSystem.Controls.Vector2Control.html) this would be the length of the vector, whereas for a button it is the raw, absolute floating-point value.
-
-In general, the current magnitude of a Control is always >= 0. However, a Control might not have a meaningful magnitude, in which case it returns -1. Any negative value should be considered an invalid magnitude.
-
-You can query the current amount of actuation using [`EvaluateMagnitude`](../api/UnityEngine.InputSystem.InputControl.html#UnityEngine_InputSystem_InputControl_EvaluateMagnitude).
-
-```CSharp
-// Check if left stick is actuated more than a quarter of its motion range.
-if (Gamepad.current.leftStick.EvaluateMagnitude() > 0.25f)
- Debug.Log("Left Stick actuated past 25%");
-```
-
-There are two mechanisms that most notably make use of Control actuation:
-
-- [Interactive rebinding](ActionBindings.md#interactive-rebinding) (`InputActionRebindingExceptions.RebindOperation`) uses it to select between multiple suitable Controls to find the one that is actuated the most.
-- [Conflict resolution](ActionBindings.md#conflicting-inputs) between multiple Controls that are bound to the same action uses it to decide which Control gets to drive the action.
-
-## Noisy Controls
-
-The Input System can label a Control as "noisy". You can query this using the [`InputControl.noisy`](../api/UnityEngine.InputSystem.InputControl.html#UnityEngine_InputSystem_InputControl_noisy) property.
-
-Noisy Controls are those that can change value without any actual or intentional user interaction required. A good example of this is a gravity sensor in a cellphone. Even if the cellphone is perfectly still, there are usually fluctuations in gravity readings. Another example are orientation readings from an HMD.
-
-If a Control is marked as noisy, it means that:
-
-1. The Control is not considered for [interactive rebinding](ActionBindings.md#interactive-rebinding). [`InputActionRebindingExceptions.RebindingOperation`](../api/UnityEngine.InputSystem.InputActionRebindingExtensions.RebindingOperation.html) ignores the Control by default (you can bypass this using [`WithoutIgnoringNoisyControls`](../api/UnityEngine.InputSystem.InputActionRebindingExtensions.RebindingOperation.html#UnityEngine_InputSystem_InputActionRebindingExtensions_RebindingOperation_WithoutIgnoringNoisyControls)).
-2. If enabled in the Project Settings, the system performs additional event filtering, then calls [`InputDevice.MakeCurrent`](../api/UnityEngine.InputSystem.InputDevice.html#UnityEngine_InputSystem_InputDevice_MakeCurrent). If an input event for a Device contains no state change on a Control that is not marked noisy, then the Device will not be made current based on the event. This avoids, for example, a plugged in PS4 controller constantly making itself the current gamepad ([`Gamepad.current`](../api/UnityEngine.InputSystem.Gamepad.html#UnityEngine_InputSystem_Gamepad_current)) due to its sensors constantly feeding data into the system.
-3. When the application loses focus and Devices are [reset](Devices.md#device-resets) as a result, the state of noisy Controls will be preserved as is. This ensures that sensor readinds will remain at their last value rather than being reset to default values.
-
->**Note**: If any Control on a Device is noisy, the Device itself is flagged as noisy.
-
-Parallel to the [`input state`](../api/UnityEngine.InputSystem.InputControl.html#UnityEngine_InputSystem_InputControl_currentStatePtr) and the [`default state`](../api/UnityEngine.InputSystem.InputControl.html#UnityEngine_InputSystem_InputControl_defaultStatePtr) that the Input System keeps for all Devices currently present, it also maintains a [`noise mask`](../api/UnityEngine.InputSystem.InputControl.html#UnityEngine_InputSystem_InputControl_noiseMaskPtr) in which only bits for state that is __not__ noise are set. This can be used to very efficiently mask out noise in input.
-
-## Synthetic Controls
-
-A synthetic Control is a Control that doesn't correspond to an actual physical control on a device (for example the `left`, `right`, `up`, and `down` child Controls on a [`StickControl`](../api/UnityEngine.InputSystem.Controls.StickControl.html)). These Controls synthesize input from other, actual physical Controls and present it in a different way (in this example, they allow you to treat the individual directions of a stick as buttons).
-
-Whether a given Control is synthetic is indicated by its [`InputControl.synthetic`](../api/UnityEngine.InputSystem.InputControl.html#UnityEngine_InputSystem_InputControl_synthetic) property.
-
-The system considers synthetic Controls for [interactive rebinding](ActionBindings.md#interactive-rebinding) but always favors non-synthetic Controls. If both a synthetic and a non-synthetic Control that are a potential match exist, the non-synthetic Control wins by default. This makes it possible to interactively bind to `/leftStick/left`, for example, but also makes it possible to bind to `/leftStickPress` without getting interference from the synthetic buttons on the stick.
-
-## Performance Optimization
-
-### Avoiding defensive copies
-
-Use [`InputControl.value`](../api/UnityEngine.InputSystem.InputControl-1.html#UnityEngine_InputSystem_InputControl_1_value) instead of [`InputControl.ReadValue`](../api/UnityEngine.InputSystem.InputControl-1.html#UnityEngine_InputSystem_InputControl_1_ReadValue) to avoid creating a copy of the control state on every call, as the former returns the value as `ref readonly` while the latter always makes a copy. Note that this optimization only applies if the call site assigns the return value to a variable that has been declared 'ref readonly'. Otherwise a copy will be made as before. Additionally, be aware of defensive copies that can be allocated by the compiler when it is unable to determine that it can safely use the readonly reference i.e. if it can't determine that the reference won't be changed, it will create a defensive copy for you. For more details, see https://learn.microsoft.com/en-us/dotnet/csharp/write-safe-efficient-code#use-ref-readonly-return-statements.
-
-
-### Control Value Caching
-
-When the `'USE_READ_VALUE_CACHING'` internal feature flag is set, the Input System will switch to an optimized path for reading control values. This path efficiently marks controls as 'stale' when they have been actuated. Subsequent calls to [`InputControl.ReadValue`](../api/UnityEngine.InputSystem.InputControl-1.html#UnityEngine_InputSystem_InputControl_1_ReadValue) will only apply control processing when there have been changes to that control or in case of control processing. Control processing in this case can mean any hard-coded processing that might exist on the control, such as with [`AxisControl`](../api/UnityEngine.InputSystem.Controls.AxisControl.html) which has built-in inversion, normalisation, scaling etc, or any processors that have been applied to the controls' [processor stack](Processors.md#processors-on-controls).
-> Note: Performance improvements **are currently not guaranteed** for all use cases. Even though this performance path marks controls as "stale" in an efficient way, it still has an overhead which can degrade performance in some cases.
-
-A positive performance impact has been seen when:
-- Reading from controls that do not change frequently.
-- In case the controls change every frame, are being read and have actions bound to them as well, e.g. on a Gamepad, reading `leftStick`, `leftStick.x` and `leftStick.left` for example when there's a action with composite bindings setup.
-
-On the other hand, it is likely to have a negative performance impact when:
-- No control reads are performed for a control, and there are a lot of changes for that particular control.
-- Reading from controls that change frequently that have no actions bound to those controls.
-
-Moreover, this feature is not enabled by default as it can result in the following minor behavioural changes:
- * Some control processors use global state. Without cached value optimizations, it is possible to read the control value, change the global state, read the control value again, and get a new value due to the fact that the control processor runs on every call. With cached value optimizations, reading the control value will only ever return a new value if the physical control has been actuated. Changing the global state of a control processor will have no effect otherwise.
- * Writing to device state using low-level APIs like [`InputControl.WriteValueIntoState`](../api/UnityEngine.InputSystem.InputControl-1.html#UnityEngine_InputSystem_InputControl_1_WriteValueIntoState__0_System_Void__) does not set the stale flag and subsequent calls to [`InputControl.value`](../api/UnityEngine.InputSystem.InputControl-1.html#UnityEngine_InputSystem_InputControl_1_value) will not reflect those changes.
- * After changing properties on [`AxisControl`](../api/UnityEngine.InputSystem.Controls.AxisControl.html) the [`ApplyParameterChanges`](../api/UnityEngine.InputSystem.InputControl.html#UnityEngine_InputSystem_InputControl_ApplyParameterChanges) has to be called to invalidate cached value.
-
-Processors that need to run on every read can set their respective caching policy to EvaluateOnEveryRead. That will disable caching on controls that are using such processor.
-
-If there are any non-obvious inconsistencies, 'PARANOID_READ_VALUE_CACHING_CHECKS' internal feature flag can be enabled to compare cached and uncached value on every read and log an error if they don't match.
-
-### Optimized control read value
-
-When the `'USE_OPTIMIZED_CONTROLS'` internal feature flag is set, the Input System will use faster way to use state memory for some controls instances. This is very specific optimization and should be used with caution.
-
-> __Please note__: This optimization has a performance impact on `PlayMode` as we do extra checks to ensure that the controls have the correct memory representation during development. Don't be alarmed if you see a performance drop in `PlayMode` when using this optimization as it's expected at this stage.
-
-Most controls are flexible with regards to memory representation, like [`AxisControl`](../api/UnityEngine.InputSystem.Controls.AxisControl.html) can be one bit, multiple bits, a float, etc, or in [`Vector2Control`](../api/UnityEngine.InputSystem.Controls.Vector2Control.html) where x and y can have different memory representation.
-Yet for most controls there are common memory representation patterns, for example [`AxisControl`](../api/UnityEngine.InputSystem.Controls.AxisControl.html) are floats or single bytes. Or some [`Vector2Control`](../api/UnityEngine.InputSystem.Controls.Vector2Control.html) are two consequitive floats in memory.
-If a control matches a common representation we can bypass reading its children control and cast the memory directly to the common representation. For example if [`Vector2Control`](../api/UnityEngine.InputSystem.Controls.Vector2Control.html) is two consecutive floats in memory we can bypass reading `x` and `y` separately and just cast the state memory to `Vector2`.
-
-> __Please note__: This optimization only works if the controls don't need any processing applied to them, such as `invert`, `clamp`, `normalize`, `scale` or any other processor. If any of these are applied to the control, **there won't be any optimization applied** and the control will be read as usual.
-
-Also, [`InputControl.ApplyParameterChanges()`](../api/UnityEngine.InputSystem.InputControl.html#UnityEngine_InputSystem_InputControl_ApplyParameterChanges) **must be explicitly called** in specific changes to ensure [`InputControl.optimizedControlDataType`](../api/UnityEngine.InputSystem.InputControl.html#UnityEngine_InputSystem_InputControl_optimizedControlDataType) is updated to the correct memory representation. Make sure to call it when:
-* Configuration changes after [`InputControl.FinishSetup()`](../api/UnityEngine.InputSystem.InputControl.html#UnityEngine_InputSystem_InputControl_FinishSetup_) is called.
-* Changing parameters such [`AxisControl.invert`](../api/UnityEngine.InputSystem.Controls.AxisControl.html#UnityEngine_InputSystem_Controls_AxisControl_invert), [`AxisControl.clamp`](../api/UnityEngine.InputSystem.Controls.AxisControl.html#UnityEngine_InputSystem_Controls_AxisControl_clamp), [`AxisControl.normalize`](../api/UnityEngine.InputSystem.Controls.AxisControl.html#UnityEngine_InputSystem_Controls_AxisControl_normalize), [`AxisControl.scale`](../api/UnityEngine.InputSystem.Controls.AxisControl.html#UnityEngine_InputSystem_Controls_AxisControl_scale) or changing processors. The memory representation needs to be recalculated after these changes so that we know that the control is not optimized anymore. Otherwise, the control will be read with wrong values.
-
-The optimized controls work as follows:
-* A potential memory representation is set using [`InputControl.CalculateOptimizedControlDataType()`](../api/UnityEngine.InputSystem.InputControl.html#UnityEngine_InputSystem_InputControl_CalculateOptimizedControlDataType)
-* Its memory representation is stored in [`InputControl.optimizedControlDataType`](../api/UnityEngine.InputSystem.InputControl.html#UnityEngine_InputSystem_InputControl_optimizedControlDataType)
-* Finally, [`ReadUnprocessedValueFromState`](../api/UnityEngine.InputSystem.InputControl-1.html#UnityEngine_InputSystem_InputControl_1_ReadUnprocessedValueFromState_) uses the optimized memory representation to decide if it should cast to memory directly instead of reading every children control on it's own to reconstruct the controls state.
diff --git a/Packages/com.unity.inputsystem/Documentation~/Debugging.md b/Packages/com.unity.inputsystem/Documentation~/Debugging.md
index 28af1b73de..6971599165 100644
--- a/Packages/com.unity.inputsystem/Documentation~/Debugging.md
+++ b/Packages/com.unity.inputsystem/Documentation~/Debugging.md
@@ -1,176 +1,13 @@
----
-uid: input-system-debugging
----
# Debugging
-- [Debugging](#debugging)
- - [Input Debugger](#input-debugger)
- - [Debugging Devices](#debugging-devices)
- - [Debugging Actions](#debugging-actions)
- - [Debugging users and PlayerInput](#debugging-users-and-playerinput)
- - [Debugging layouts](#debugging-layouts)
- - [Debugging remotely](#debugging-remotely)
- - [Input visualizers](#input-visualizers)
- - [`InputControlVisualizer`](#inputcontrolvisualizer)
- - [`InputActionVisualizer`](#inputactionvisualizer)
- - [Device Simulator](#device-simulator)
- - [Unity Remote (iOS, Android)](#unity-remote)
- - [Other tips:](#other-tips)
-
-When something isn't working as expected, the quickest way to troubleshoot what's wrong is the Input Debugger in the Unity Editor. The Input Debugger provides access to the activity of the Input System in both the Editor and the connected Players.
-
-To open the Input Debugger, go to __Window > Analysis > Input Debugger__ from Unity's main menu.
-
-## Input Debugger
-
-
-
-The Input Debugger displays a tree breakdown of the state of the Input System.
-
-|Item|Description|
-|----|-----------|
-|Devices|A list of all [Input Devices](Devices.md) that are currently in the system, and a list of unsupported/unrecognized Devices.|
-|Layouts|A list of all registered Control and Device layouts. This is the database of supported hardware, and information on how to represent a given piece of input hardware.|
-|Actions|Only visible in Play mode, and only if at least one [Action](Actions.md) is enabled.(
- matches: new InputDeviceMatcher()
- .WithInterface("HID")
- .WithProduct("MyDevice.*")
- .WithManufacturer("MyBrand");
-
-// Register an alternate matcher for an already registered layout.
-InputSystem.RegisterLayoutMatcher(
- new InputDeviceMatcher()
- .WithInterface("HID")
-
-```
-
-If multiple matchers are matching the same [`InputDeviceDescription`](../api/UnityEngine.InputSystem.Layouts.InputDeviceDescription.html), the Input System chooses the matcher that has the larger number of properties to match against.
-
-#### Hijacking the matching process
-
-You can overrule the internal matching process from outside to select a different layout for a Device than the system would normally choose. This also makes it possible to quickly build new layouts. To do this, add a custom handler to the [`InputSystem.onFindControlLayoutForDevice`](../api/UnityEngine.InputSystem.InputSystem.html#UnityEngine_InputSystem_InputSystem_onFindLayoutForDevice) event. If your handler returns a non-null layout string, then the Input System uses this layout.
-
-### Device lifecycle
-
-#### Device creation
-
-Once the system has chosen a [layout](Layouts.md) for a device, it instantiates an [`InputDevice`](../api/UnityEngine.InputSystem.InputDevice.html) and populates it with [`InputControls`](../api/UnityEngine.InputSystem.InputControl.html) as the layout dictates. This process is internal and happens automatically.
-
->__Note__: You can't create valid [`InputDevices`](../api/UnityEngine.InputSystem.InputDevice.html) and [`InputControls`](../api/UnityEngine.InputSystem.InputControl.html) by manually instantiating them with `new`. To guide the creation process, you must use [layouts](Layouts.md).
-
-After the Input System assembles the [`InputDevice`](../api/UnityEngine.InputSystem.InputDevice.html), it calls [`FinishSetup`](../api/UnityEngine.InputSystem.InputControl.html#UnityEngine_InputSystem_InputControl_FinishSetup_) on each control of the device and on the device itself. Use this to finalize the setup of the Controls.
-
-After an [`InputDevice`](../api/UnityEngine.InputSystem.InputDevice.html) is fully assembled, the Input System adds it to the system. As part of this process, the Input System calls [`MakeCurrent`](../api/UnityEngine.InputSystem.InputDevice.html#UnityEngine_InputSystem_InputDevice_MakeCurrent_) on the Device, and signals [`InputDeviceChange.Added`](../api/UnityEngine.InputSystem.InputDeviceChange.html#UnityEngine_InputSystem_InputDeviceChange_Added) on [`InputSystem.onDeviceChange`](../api/UnityEngine.InputSystem.InputSystem.html#UnityEngine_InputSystem_InputSystem_onDeviceChange). The Input System also calls [`InputDevice.OnAdded`](../api/UnityEngine.InputSystem.InputDevice.html#UnityEngine_InputSystem_InputDevice_OnAdded_).
-
-Once added, the [`InputDevice.added`](../api/UnityEngine.InputSystem.InputDevice.html#UnityEngine_InputSystem_InputDevice_added) flag is set to true.
-
-To add devices manually, you can call one of the `InputSystem.AddDevice` methods such as [`InputSystem.AddDevice(layout)`](../api/UnityEngine.InputSystem.InputSystem.html#UnityEngine_InputSystem_InputSystem_AddDevice_System_String_System_String_System_String_).
-
-```CSharp
-// Add a gamepad. This bypasses the matching process and creates a device directly
-// with the Gamepad layout.
-InputSystem.AddDevice();
-
-// Add a device such that the matching process is employed:
-InputSystem.AddDevice(new InputDeviceDescription
-{
- interfaceName = "XInput",
- product = "Xbox Controller",
-});
-```
-
-When a device is added, the Input System automatically issues a [sync request](../api/UnityEngine.InputSystem.LowLevel.RequestSyncCommand.html) on the device. This instructs the device to send an event representing its current state. Whether this request succeeds depends on the whether the given device supports the sync command.
-
-#### Device removal
-
-When a Device is disconnected, it is removed from the system. A notification appears for [`InputDeviceChange.Removed`](../api/UnityEngine.InputSystem.InputDeviceChange.html) (sent via [`InputSystem.onDeviceChange`](../api/UnityEngine.InputSystem.InputSystem.html#UnityEngine_InputSystem_InputSystem_onDeviceChange)) and the Devices are removed from the [`devices`](../api/UnityEngine.InputSystem.InputSystem.html#UnityEngine_InputSystem_InputSystem_onDeviceChange) list. The system also calls [`InputDevice.OnRemoved`](../api/UnityEngine.InputSystem.InputDevice.html#UnityEngine_InputSystem_InputDevice_OnRemoved_).
-
-The [`InputDevice.added`](../api/UnityEngine.InputSystem.InputDevice.html#UnityEngine_InputSystem_InputDevice_added) flag is reset to false in the process.
-
-Note that Devices are not destroyed when removed. Device instances remain valid and you can still access them in code. However, trying to read values from the controls of these Devices leads to exceptions.
-
-#### Device resets
-
-Resetting a Device resets its Controls to their default state. You can do this manually using [`InputSystem.ResetDevice`](../api/UnityEngine.InputSystem.InputSystem.html#UnityEngine_InputSystem_InputSystem_ResetDevice_UnityEngine_InputSystem_InputDevice_System_Boolean_):
-
-```CSharp
- InputSystem.ResetDevice(Gamepad.current);
-```
-
-There are two types of resets as determined by the second parameter to [`InputSystem.ResetDevice`](../api/UnityEngine.InputSystem.InputSystem.html#UnityEngine_InputSystem_InputSystem_ResetDevice_UnityEngine_InputSystem_InputDevice_System_Boolean_):
-
-|Type|Description|
-|----|-----------|
-|"Soft" Resets|This is the default. With this type, only controls that are *not* marked as [`dontReset`](Layouts.md#control-items) are reset to their default value. This excludes controls such as [`Pointer.position`](../api/UnityEngine.InputSystem.Pointer.html#UnityEngine_InputSystem_Pointer_position) from resets and thus prevents mouse positions resetting to `(0,0)`.|
-|"Hard" Resets|In this type, *all* controls are reset to their default value regardless of whether they have [`dontReset`](Layouts.md#control-items) set or not.|
-
-Resetting Controls this way is visible on [Actions](Actions.md). If you reset a Device that is currently driving one or more Action, the Actions are cancelled. This cancellation is different from sending an event with default state. Whereas the latter may inadvertently [perform](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_performed) Actions (e.g. a button that was pressed would not appear to have been released), a reset will force clean cancellation.
-
-Resets may be triggered automatically by the Input System depending on [application focus](#background-and-focus-change-behavior).
-
-#### Device syncs
-
-A Device may be requested to send an event with its current state through [`RequestSyncCommand`](../api/UnityEngine.InputSystem.LowLevel.RequestSyncCommand.html). It depends on the platform and type of Device whether this is supported or not.
-
-A synchronization request can be explicitly sent using [`InputSystem.TrySyncDevice`](../api/UnityEngine.InputSystem.InputSystem.html#UnityEngine_InputSystem_InputSystem_TrySyncDevice_UnityEngine_InputSystem_InputDevice_). If the device supports sync requests, the method returns true and an [`InputEvent`](../api/UnityEngine.InputSystem.LowLevel.InputEvent.html) will have been queued on the device for processing in the next [update](../api/UnityEngine.InputSystem.InputSystem.html#UnityEngine_InputSystem_InputSystem_Update_).
-
-Synchronization requests are also automatically sent by the Input System in certain situations. See [Background and focus change behavior](#background-and-focus-change-behavior) for more details.
-
-#### Device enabling and disabling
-
-When a Device is added, the Input System sends it an initial [`QueryEnabledStateCommand`](../api/UnityEngine.InputSystem.LowLevel.QueryEnabledStateCommand.html) to find out whether the device is currently enabled or not. The result of this is reflected in the [`InputDevice.enabled`](../api/UnityEngine.InputSystem.InputDevice.html#UnityEngine_InputSystem_InputDevice_enabled) property.
-
-When disabled, no events other than removal ([`DeviceRemoveEvent`](../api/UnityEngine.InputSystem.LowLevel.DeviceRemoveEvent.html)) and configuration change ([`DeviceConfigurationEvent`](../api/UnityEngine.InputSystem.LowLevel.DeviceConfigurationEvent.html)) events are processed for a Device, even if they are sent.
-
-A Device can be manually disabled and re-enabled via [`InputSystem.DisableDevice`](../api/UnityEngine.InputSystem.InputSystem.html#UnityEngine_InputSystem_InputSystem_DisableDevice_) and [`InputSystem.EnableDevice`](../api/UnityEngine.InputSystem.InputSystem.html#UnityEngine_InputSystem_InputSystem_EnableDevice_) respectively.
-
-Note that [sensors](Sensors.md) start in a disabled state by default, and you need to enable them in order for them to generate events.
-
-The Input System may automatically disable and re-enable Devices in certain situations, as detailed in the [next section](#background-and-focus-change-behavior).
-
-#### Background and focus change behavior
-
-In general, input is tied to [application focus](https://docs.unity3d.com/ScriptReference/Application-isFocused.html). This means that Devices do not receive input while the application is not in the foreground and thus no [Actions](Actions.md) will receive input either. When the application comes back into focus, all devices will receive a [sync](#device-syncs) request to have them send their current state (which may have changed while the application was in the background) to the application. Devices that do not support sync requests will see a [soft reset](#device-resets) that resets all Controls not marked as [`dontReset`](Layouts.md#control-items) to their default state.
-
-On platforms such as iOS and Android, that do not support running Unity applications in the background, this is the only supported behavior.
-
-If the application is configured to run while in the background (that is, not having focus), input behavior can be selected from several options. This is supported in two scenarios:
-
-* In Unity's [Player Settings](https://docs.unity3d.com/Manual/class-PlayerSettings.html) you can explicity enable `Run In Background` for specific players that support it (such as Windows or Mac standalone players). Note that in these players this setting is always enabled automatically in *development* players.
-* In the editor, application focus is tied to focus on the Game View. If no Game View is focused, the application is considered to be running in the background. However, while in play mode, the editor will *always* keep running the player loop regardless of focus on the Game View window. This means that in the editor, `Run In Background` is considered to always be enabled.
-
-If the application is configured this way to keep running while in the background, the player loop and thus the Input System, too, will keep running even when the application does not have focus. What happens with respect to input then depends on two factors:
-
-1. On the ability of individual devices to receive input while the application is not running in the foreground. This is only supported by a small subset of devices and platforms. VR devices ([`TrackedDevice`](../api/UnityEngine.InputSystem.TrackedDevice.html)) such as HMDs and VR controllers generally support this.`](../api/UnityEngine.InputSystem.InputDevice.html#UnityEngine_InputSystem_InputDevice_ExecuteCommand__1___0__). To monitor Device commands, use [`InputSystem.onDeviceCommand`](../api/UnityEngine.InputSystem.InputSystem.html#UnityEngine_InputSystem_InputSystem_onDeviceCommand).
-
-Each Device command implements the [`IInputDeviceCommandInfo`](../api/UnityEngine.InputSystem.LowLevel.IInputDeviceCommandInfo.html) interface, which only requires the [`typeStatic`](../api/UnityEngine.InputSystem.LowLevel.IInputDeviceCommandInfo.html#UnityEngine_InputSystem_LowLevel_IInputDeviceCommandInfo_typeStatic) property to identify the type of the command. The native implementation of the Device should then understand how to handle that command. One common case is the `"HIDO"` command type which is used to send [HID output reports](HID.md#hid-output) to HIDs.
-
-### Adding custom device Commands
-
-To create custom Device commands (for example, to support some functionality for a specific HID), create a `struct` that contains all the data to be sent to the Device, and add a [`typeStatic`](../api/UnityEngine.InputSystem.LowLevel.IInputDeviceCommandInfo.html#UnityEngine_InputSystem_LowLevel_IInputDeviceCommandInfo_typeStatic) property to make that struct implement the [`IInputDeviceCommandInfo`](../api/UnityEngine.InputSystem.LowLevel.IInputDeviceCommandInfo.html) interface. To send data to a HID, this property should return `"HIDO"`.
-
-You can then create an instance of this struct and populate all its fields, then use [`InputDevice.ExecuteCommand`](../api/UnityEngine.InputSystem.InputDevice.html#UnityEngine_InputSystem_InputDevice_ExecuteCommand__1___0__) to send it to the Device. The data layout of the struct must match the native representation of the data as the device interprets it.
-
-## Device state
-
-Like any other type of [Control](Controls.md#control-state), each Device has a block of memory allocated to it which stores the state of all the Controls associated with the Device.
-
-### State changes
-
-State changes are usually initiated through [state events](Events.md#state-events) from the native backend, but you can use [`InputControl<>.WriteValueIntoState()`](../api/UnityEngine.InputSystem.InputControl-1.html#UnityEngine_InputSystem_InputControl_1_WriteValueIntoState__0_System_Void__) to manually overwrite the state of any Control.
-
-#### Monitoring state changes
-
-You can use [`InputState.AddChangeMonitor()`](../api/UnityEngine.InputSystem.LowLevel.InputState.html#UnityEngine_InputSystem_LowLevel_InputState_AddChangeMonitor_UnityEngine_InputSystem_InputControl_System_Action_UnityEngine_InputSystem_InputControl_System_Double_UnityEngine_InputSystem_LowLevel_InputEventPtr_System_Int64__System_Int32_System_Action_UnityEngine_InputSystem_InputControl_System_Double_System_Int64_System_Int32__) to register a callback to be called whenever the state of a Control changes. The Input System uses the same mechanism to implement [input Actions](Actions.md).
-
-#### Synthesizing state
-
-The Input System can synthesize a new state from an existing state. An example of such a synthesized state is the [`press`](../api/UnityEngine.InputSystem.Pointer.html#UnityEngine_InputSystem_Pointer_press) button Control that [`Touchscreen`](../api/UnityEngine.InputSystem.Touchscreen.html) inherits from [`Pointer`](../api/UnityEngine.InputSystem.Pointer.html). Unlike a mouse, which has a physical button, for [`Touchscreen`](../api/UnityEngine.InputSystem.Touchscreen.html) this is a [synthetic Control](Controls.md#synthetic-controls) that doesn't correspond to actual data coming in from the Device backend. Instead, the Input System considers the button to be pressed if any touch is currently ongoing, and released otherwise.
-
-To do this, the Input System uses [`InputState.Change`](../api/UnityEngine.InputSystem.LowLevel.InputState.html#UnityEngine_InputSystem_LowLevel_InputState_Change__1_UnityEngine_InputSystem_InputControl___0_UnityEngine_InputSystem_LowLevel_InputUpdateType_UnityEngine_InputSystem_LowLevel_InputEventPtr_), which allows feeding arbitrary state changes into the system without having to run them through the input event queue. The Input System incorporates state changes directly and synchronously. State change [monitors](#monitoring-state-changes) still trigger as expected.
-
-## Working with Devices
-
-### Monitoring Devices
-
-To be notified when new Devices are added or existing Devices are removed, use [`InputSystem.onDeviceChange`](../api/UnityEngine.InputSystem.InputSystem.html#UnityEngine_InputSystem_InputSystem_onDeviceChange).
-
-```CSharp
-InputSystem.onDeviceChange +=
- (device, change) =>
- {
- switch (change)
- {
- case InputDeviceChange.Added:
- // New Device.
- break;
- case InputDeviceChange.Disconnected:
- // Device got unplugged.
- break;
- case InputDeviceChange.Connected:
- // Plugged back in.
- break;
- case InputDeviceChange.Removed:
- // Remove from Input System entirely; by default, Devices stay in the system once discovered.
- break;
- default:
- // See InputDeviceChange reference for other event types.
- break;
- }
- }
-```
-
-[`InputSystem.onDeviceChange`](../api/UnityEngine.InputSystem.InputSystem.html#UnityEngine_InputSystem_InputSystem_onDeviceChange) delivers notifications for other device-related changes as well. See the [`InputDeviceChange` enum](../api/UnityEngine.InputSystem.InputDeviceChange.html) for more information.
-
-### Adding and removing Devices
-
-To manually add and remove Devices through the API, use [`InputSystem.AddDevice()`](../api/UnityEngine.InputSystem.InputSystem.html#UnityEngine_InputSystem_InputSystem_AddDevice_UnityEngine_InputSystem_InputDevice_) and [`InputSystem.RemoveDevice()`](../api/UnityEngine.InputSystem.InputSystem.html#UnityEngine_InputSystem_InputSystem_RemoveDevice_UnityEngine_InputSystem_InputDevice_).
-
-This allows you to create your own Devices, which can be useful for testing purposes, or for creating virtual Input Devices which synthesize input from other events. As an example, see the [on-screen Controls](OnScreen.md) that the Input System provides. The Input Devices used for on-screen Controls are created entirely in code and have no [native representation](#native-devices).
-
-### Creating custom Devices
-
->__Note__: This example deals only with Devices that have fixed layouts (that is, you know the specific model or models that you want to implement). This is different from an interface such as HID, where Devices can describe themselves through the interface and take on a wide variety of forms. A fixed Device layout can't cover self-describing Devices, so you need to use a [layout builder](Layouts.md#generated-layouts) to build Device layouts from information you obtain at runtime.
-
-There are two main situations in which you might need to create a custom Device:
-
-1. You have an existing API that generates input, and which you want to reflect into the Input System.
-2. You have an HID that the Input System ignores, or that the Input system auto-generates a layout for that doesn't work well enough for your needs.
-
-For the second scenario, see [Overriding the HID Fallback](HID.md#creating-a-custom-device-layout).
-
-The steps below deal with the first scenario, where you want to create a new Input Device entirely from scratch and provide input to it from a third-party API.
-
-#### Step 1: The state struct
-
-The first step is to create a C# `struct` that represents the form in which the system receives and stores input, and also describes the `InputControl` instances that the Input System must create for the Device in order to retrieve its state.
-
-```CSharp
-// A "state struct" describes the memory format that a Device uses. Each Device can
-// receive and store memory in its custom format. InputControls then connect to
-// the individual pieces of memory and read out values from them.
-//
-// If it's important for the memory format to match 1:1 at the binary level
-// to an external representation, it's generally advisable to use
-// LayoutLind.Explicit.
-[StructLayout(LayoutKind.Explicit, Size = 32)]
-public struct MyDeviceState : IInputStateTypeInfo
-{
- // You must tag every state with a FourCC code for type
- // checking. The characters can be anything. Choose something that allows
- // you to easily recognize memory that belongs to your own Device.
- public FourCC format => new FourCC('M', 'Y', 'D', 'V');
-
- // InputControlAttributes on fields tell the Input System to create Controls
- // for the public fields found in the struct.
-
- // Assume a 16bit field of buttons. Create one button that is tied to
- // bit #3 (zero-based). Note that buttons don't need to be stored as bits.
- // They can also be stored as floats or shorts, for example. The
- // InputControlAttribute.format property determines which format the
- // data is stored in. If omitted, the system generally infers it from the value
- // type of the field.
- [InputControl(name = "button", layout = "Button", bit = 3)]
- public ushort buttons;
-
- // Create a floating-point axis. If a name is not supplied, it is taken
- // from the field.
- [InputControl(layout = "Axis")]
- public short axis;
-}
-```
-
-The Input System's layout mechanism uses [`InputControlAttribute`](../api/UnityEngine.InputSystem.Layouts.InputControlAttribute.html) annotations to add Controls to the layout of your Device. For details, see the [layout system](Layouts.md) documentation.
-
-With the state struct in place, you now have a way to send input data to the Input System and store it there. The next thing you need is an [`InputDevice`](../api/UnityEngine.InputSystem.InputDevice.html) that uses your custom state struct and represents your custom Device.
-
-#### Step 2: The Device class
-
-Next, you need a class derived from one of the [`InputDevice`](../api/UnityEngine.InputSystem.InputDevice.html) base classes. You can either base your Device directly on [`InputDevice`](../api/UnityEngine.InputSystem.InputDevice.html), or you can pick a more specific Device type, like [`Gamepad`](../api/UnityEngine.InputSystem.Gamepad.html).
-
-This example assumes that your Device doesn't fit into any of the existing Device classes, so it derives directly from [`InputDevice`](../api/UnityEngine.InputSystem.InputDevice.html).
-
-```CSharp
-// InputControlLayoutAttribute attribute is only necessary if you want
-// to override the default behavior that occurs when you register your Device
-// as a layout.
-// The most common use of InputControlLayoutAttribute is to direct the system
-// to a custom "state struct" through the `stateType` property. See below for details.
-[InputControlLayout(displayName = "My Device", stateType = typeof(MyDeviceState))]
-public class MyDevice : InputDevice
-{
- // In the state struct, you added two Controls that you now want to
- // surface on the Device, for convenience. The Controls
- // get added to the Device either way. When you expose them as properties,
- // it is easier to get to the Controls in code.
-
- public ButtonControl button { get; private set; }
- public AxisControl axis { get; private set; }
-
- // The Input System calls this method after it constructs the Device,
- // but before it adds the device to the system. Do any last-minute setup
- // here.
- protected override void FinishSetup()
- {
- base.FinishSetup();
-
- // NOTE: The Input System creates the Controls automatically.
- // This is why don't do `new` here but rather just look
- // the Controls up.
- button = GetChildControl("button");
- axis = GetChildControl("axis");
- }
-}
-```
-
-#### Step 3: The Update method
-
-You now have a Device in place along with its associated state format. You can call the following method to create a fully set-up Device with your two Controls on it:
-
-```CSharp
-InputSystem.AddDevice();
-```
-
-However, this Device doesn't receive input yet, because you haven't added any code that generates input. To do that, you can use [`InputSystem.QueueStateEvent`](../api/UnityEngine.InputSystem.InputSystem.html#UnityEngine_InputSystem_InputSystem_QueueStateEvent__1_UnityEngine_InputSystem_InputDevice___0_System_Double_) or [`InputSystem.QueueDeltaStateEvent`](../api/UnityEngine.InputSystem.InputSystem.html#UnityEngine_InputSystem_InputSystem_QueueDeltaStateEvent__1_UnityEngine_InputSystem_InputControl___0_System_Double_) from anywhere, including from a thread. The following example uses [`IInputUpdateCallbackReceiver`](../api/UnityEngine.InputSystem.LowLevel.IInputUpdateCallbackReceiver.html), which, when implemented by any [`InputDevice`](../api/UnityEngine.InputSystem.InputDevice.html), adds an [`OnUpdate()`](../api/UnityEngine.InputSystem.LowLevel.IInputUpdateCallbackReceiver.html#UnityEngine_InputSystem_LowLevel_IInputUpdateCallbackReceiver_OnUpdate) method that automatically gets called during [`InputSystem.onBeforeUpdate`](../api/UnityEngine.InputSystem.InputSystem.html#UnityEngine_InputSystem_InputSystem_onBeforeUpdate) and provides input events to the current input update.
-
->__Note__: If you already have a place where input for your device becomes available, you can skip this step and queue input events from there instead of using [`IInputUpdateCallbackReceiver`](../api/UnityEngine.InputSystem.LowLevel.IInputUpdateCallbackReceiver.html).
-
-```CSharp
-public class MyDevice : InputDevice, IInputUpdateCallbackReceiver
-{
- //...
-
- public void OnUpdate()
- {
- // In practice, this would read out data from an external
- // API. This example uses some empty input.
- var state = new MyDeviceState();
- InputSystem.QueueStateEvent(this, state);
- }
-}
-```
-
-#### Step 4: Device registration and creation
-
-You now have a functioning device, but you haven't registered it (added it to the system) yet. This means you can't see the device when, for example, you create bindings in the [Action editor](ActionAssets.md#editing-input-action-assets).
-
-You can register your device type with the system from within the code that runs automatically as part of Unity's startup. To do so, modify the definition of `MyDevice` like so:
-
-```CSharp
-// Add the InitializeOnLoad attribute to automatically run the static
-// constructor of the class after each C# domain load.
-#if UNITY_EDITOR
-[InitializeOnLoad]
-#endif
-public class MyDevice : InputDevice, IInputUpdateCallbackReceiver
-{
- //...
-
- static MyDevice()
- {
- // RegisterLayout() adds a "Control layout" to the system.
- // These can be layouts for individual Controls (like sticks)
- // or layouts for entire Devices (which are themselves
- // Controls) like in our case.
- InputSystem.RegisterLayout();
- }
-
- // You still need a way to trigger execution of the static constructor
- // in the Player. To do this, you can add the RuntimeInitializeOnLoadMethod
- // to an empty method.
- [RuntimeInitializeOnLoadMethod(RuntimeInitializeLoadType.BeforeSceneLoad)]
- private static void InitializeInPlayer() {}
-}
-```
-
-This registers the Device type with the system and makes it available in the Control picker. However, you still need a way to add an instance of the Device when it is connected.
-
-In theory, you could call [`InputSystem.AddDevice()`](../api/UnityEngine.InputSystem.InputSystem.html#UnityEngine_InputSystem_InputSystem_AddDevice__1_System_String_) somewhere, but in a real-world setup you likely have to correlate the Input Devices you create with their identities in the third-party API.
-
-It might be tempting to do something like this:
-
-```CSharp
-public class MyDevice : InputDevice, IInputUpdateCallbackReceiver
-{
- //...
-
- // This does NOT work correctly.
- public ThirdPartyAPI.DeviceId externalId { get; set; }
-}
-```
-
-and then set that on the Device after calling [`AddDevice`](../api/UnityEngine.InputSystem.InputSystem.html#UnityEngine_InputSystem_InputSystem_AddDevice__1_System_String_). However, this doesn't work as expected in the Editor, because the Input System requires Devices to be created solely from their [`InputDeviceDescription`](../api/UnityEngine.InputSystem.Layouts.InputDeviceDescription.html) in combination with the chosen layout (and layout variant). In addition, the system supports a fixed set of mutable per-device properties such as device usages (that is, [`InputSystem.SetDeviceUsage()`](../api/UnityEngine.InputSystem.InputSystem.html#UnityEngine_InputSystem_InputSystem_SetDeviceUsage_UnityEngine_InputSystem_InputDevice_System_String_) and related methods). This allows the system to easily recreate Devices after domain reloads in the Editor, as well as to create replicas of remote Devices when connecting to a Player. To comply with this requirement, you must cast that information provided by the third-party API into an [`InputDeviceDescription`](../api/UnityEngine.InputSystem.Layouts.InputDeviceDescription.html) and then use an [`InputDeviceMatcher`](../api/UnityEngine.InputSystem.Layouts.InputDeviceMatcher.html) to match the description to our custom `MyDevice` layout.
-
-This example assumes that the third-party API has two callbacks, like this:
-
-```CSharp
-public static ThirdPartyAPI
-{
- // This example assumes that the argument is a string that
- // contains the name of the Device, and that no two Devices
- // have the same name in the external API.
- public static Action deviceAdded;
- public static Action deviceRemoved;
-}
-```
-
-You can hook into those callbacks and create and destroy devices in response.
-
-```CSharp
-// This example uses a MonoBehaviour with [ExecuteInEditMode]
-// on it to run the setup code. You can do this many other ways.
-[ExecuteInEditMode]
-public class MyDeviceSupport : MonoBehaviour
-{
- protected void OnEnable()
- {
- ThirdPartyAPI.deviceAdded += OnDeviceAdded;
- ThirdPartyAPI.deviceRemoved += OnDeviceRemoved;
- }
-
- protected void OnDisable()
- {
- ThirdPartyAPI.deviceAdded -= OnDeviceAdded;
- ThirdPartyAPI.deviceRemoved -= OnDeviceRemoved;
- }
-
- private void OnDeviceAdded(string name)
- {
- // Feed a description of the Device into the system. In response, the
- // system matches it to the layouts it has and creates a Device.
- InputSystem.AddDevice(
- new InputDeviceDescription
- {
- interfaceName = "ThirdPartyAPI",
- product = name
- });
- }
-
- private void OnDeviceRemoved(string name)
- {
- var device = InputSystem.devices.FirstOrDefault(
- x => x.description == new InputDeviceDescription
- {
- interfaceName = "ThirdPartyAPI",
- product = name,
- });
-
- if (device != null)
- InputSystem.RemoveDevice(device);
- }
-
- // Move the registration of MyDevice from the
- // static constructor to here, and change the
- // registration to also supply a matcher.
- protected void Awake()
- {
- // Add a match that catches any Input Device that reports its
- // interface as "ThirdPartyAPI".
- InputSystem.RegisterLayout(
- matches: new InputDeviceMatcher()
- .WithInterface("ThirdPartyAPI"));
- }
-}
-```
-
-#### Step 5: `current` and `all` (optional)
-
-For convenience, you can quickly access the last used device of a given type, or list all devices of a specific type. To do this, add support for a `current` and for an `all` getter to the API of `MyDevice`.
-
-```CSharp
-public class MyDevice : InputDevice, IInputCallbackReceiver
-{
- //...
-
- public static MyDevice current { get; private set; }
-
- public static IReadOnlyList all => s_AllMyDevices;
- private static List s_AllMyDevices = new List();
-
- public override void MakeCurrent()
- {
- base.MakeCurrent();
- current = this;
- }
-
- protected override void OnAdded()
- {
- base.OnAdded();
- s_AllMyDevices.Add(this);
- }
-
- protected override void OnRemoved()
- {
- base.OnRemoved();
- s_AllMyDevices.Remove(this);
- }
-}
-```
-
-#### Step 6: Device Commands (Optional)
-
-A final, but optional, step is to add support for Device commands. A "device command" is that opposite of input. In other words, it consists of data traveling __to__ the input device, which might also return data as part of the operation (much like a function call). You can use this to communicate with the backend of the device in order to query configuration, or to initiate effects such as haptics. At the moment there isn't a proper interface available for this, however there are still some scenarios that can be solved with the current interfaces.
-
-E.g. the following shows, when implementing a non-hardware-backed device (simulated device), how to simulate hardware reporting that the device can be run in the background and supports sync commands. This is useful to prevent the device from cancelling Actions when application focus is lost and restored. For more info see [Device syncs](#device-syncs)
-
-```CSharp
-public class MyDevice : InputDevice, IInputCallbackReceiver
-{
- //...
-
- protected override unsafe long ExecuteCommand(InputDeviceCommand* commandPtr)
- {
- var type = commandPtr->type;
- if (type == RequestSyncCommand.Type)
- {
- // Report that the device supports the sync command and has handled it.
- // This will prevent device reset during focus changes.
- result = InputDeviceCommand.GenericSuccess;
- return true;
- }
-
- if (type == QueryCanRunInBackground.Type)
- {
- // Notify that the device supports running in the background.
- ((QueryCanRunInBackground*)commandPtr)->canRunInBackground = true;
- result = InputDeviceCommand.GenericSuccess;
- return true;
- }
-
- result = default;
- return false;
- }
-}
-```
+While you can configure and respond to a variety of input devices all together in the Actions Editor window, each type of device has its own unique features that sometimes requires special handling, such as touches on a touchscreen, or text input on a keyboard.
+
+Learn about supported input devices and their unique features in this section.
+
+| **Topic** | **Description** |
+| :------------------------------ | :------------------------------- |
+| **[Supported Input Devices](supported-input-devices.md)** | Summary |
+| **[Pointers](pointers.md)** | Summary |
+| **[Keyboard support](keyboard-support.md)** | Summary |
+| **[Gamepad support](gamepad-support.md)** | Summary |
+| **[Joystick support](joystick-support.md)** | Summary |
+| **[Sensor support](sensor-support.md)** | Summary |
+| **[HID support](hid-support.md)** | Summary |
+| **[Devices (scripting)](devices-scripting.md)** | Summary |
+| **[Create a custom device](create-custom-device.md)** | Summary |
\ No newline at end of file
diff --git a/Packages/com.unity.inputsystem/Documentation~/EditorFeatures.md b/Packages/com.unity.inputsystem/Documentation~/EditorFeatures.md
index d640a9c621..c2a0d2d2b9 100644
--- a/Packages/com.unity.inputsystem/Documentation~/EditorFeatures.md
+++ b/Packages/com.unity.inputsystem/Documentation~/EditorFeatures.md
@@ -13,6 +13,6 @@ Unlike Unity's old Input Manager, the Input System package allows you to read in
When something isn't working as expected, the quickest way to troubleshoot what's wrong is the Input Debugger in the Unity Editor. The Input Debugger provides access to the activity of the Input System in both the Editor and the connected Players. ([Read more](Debugging.md))
-### [Automated Input Testing](Testing.md)
+### [Automated Input Testing](testing.md)
-The Input System has built-in support for writing automated input tests. You can drive input entirely from code, without any dependencies on platform backends and physical hardware devices. The automated input tests you write consider the generated input to be the same as input generated at runtime by actual platform code. ([Read more](Testing.md))
+The Input System has built-in support for writing automated input tests. You can drive input entirely from code, without any dependencies on platform backends and physical hardware devices. The automated input tests you write consider the generated input to be the same as input generated at runtime by actual platform code. ([Read more](testing.md))
diff --git a/Packages/com.unity.inputsystem/Documentation~/HowDoI.md b/Packages/com.unity.inputsystem/Documentation~/HowDoI.md
index d0490f0546..cef92b1791 100644
--- a/Packages/com.unity.inputsystem/Documentation~/HowDoI.md
+++ b/Packages/com.unity.inputsystem/Documentation~/HowDoI.md
@@ -7,7 +7,7 @@ A collection of frequently asked questions, and where to find their answers in t
> **Note:**
>
-> If you're new to the Input System and have landed on this page looking for documentation, it's best to read the [QuickStart Guide](QuickStartGuide.md), and the [Concepts](Concepts.md) and [Workflows](Workflows.md) pages, so that you can make sure you're choosing the best workflow for your project's input requirements.
+> If you're new to the Input System and have landed on this page looking for documentation, it's best to read the [QuickStart Guide](quick-start-guide.md), and the [Concepts](understanding-input.md) and [Workflows](workflows.md) pages, so that you can make sure you're choosing the best workflow for your project's input requirements.
>
> This is because there are a number of different ways to read input using the Input System, and many of the answers on this page give you the quickest but least flexible solution, and may not be suitable for a project with more complex requirements.
@@ -27,7 +27,7 @@ How do I...?
- [create my own custom devices?](HID.md#creating-a-custom-device-layout)
- create a simple "Fire" type action?
-Use the same techniques shown for the "Jump" action in the [Workflows section](Workflows.md)
+Use the same techniques shown for the "Jump" action in the [Workflows section](workflows.md)
- [require a button to be held down for some duration before triggering an action?](Interactions.html#hold)
@@ -49,8 +49,8 @@ Use the same techniques shown for the "Jump" action in the [Workflows section](W
- [give my head tracking an extra update before rendering?](../api/UnityEngine.InputSystem.XR.XRHMD.html)
-- [record events flowing through the system?](Debugging.md#other-tips)
+- [record events flowing through the system?](debugging.md#other-tips)
-- [see events as they're processed?](Debugging.md#other-tips)
+- [see events as they're processed?](debugging.md#other-tips)
- [see what Devices I have and what state they're in?](Debugging.html#debugging-devices)
diff --git a/Packages/com.unity.inputsystem/Documentation~/Interactions.md b/Packages/com.unity.inputsystem/Documentation~/Interactions.md
index e7933342ce..6f6356c561 100644
--- a/Packages/com.unity.inputsystem/Documentation~/Interactions.md
+++ b/Packages/com.unity.inputsystem/Documentation~/Interactions.md
@@ -3,22 +3,21 @@ uid: input-system-interactions
---
# Interactions
-- [Interactions](#interactions)
- - [Operation](#operation)
- - [Multiple Controls on an Action](#multiple-controls-on-an-action)
- - [Multiple Interactions on a Binding](#multiple-interactions-on-a-binding)
- - [Timeouts](#timeouts)
- - [Using Interactions](#using-interactions)
- - [Interactions applied to Bindings](#interactions-applied-to-bindings)
- - [Interactions applied to Actions](#interactions-applied-to-actions)
- - [Predefined Interactions](#predefined-interactions)
- - [Default Interaction](#default-interaction)
- - [Press](#press)
- - [Hold](#hold)
- - [Tap](#tap)
- - [SlowTap](#slowtap)
- - [MultiTap](#multitap)
- - [Writing custom Interactions](#writing-custom-interactions)
+- [Operation](#operation)
+ - [Multiple Controls on an Action](#multiple-controls-on-an-action)
+ - [Multiple Interactions on a Binding](#multiple-interactions-on-a-binding)
+ - [Timeouts](#timeouts)
+- [Using Interactions](#using-interactions)
+ - [Interactions applied to Bindings](#interactions-applied-to-bindings)
+ - [Interactions applied to Actions](#interactions-applied-to-actions)
+- [Predefined Interactions](#predefined-interactions)
+ - [Default Interaction](#default-interaction)
+ - [Press](#press)
+ - [Hold](#hold)
+ - [Tap](#tap)
+ - [SlowTap](#slowtap)
+ - [MultiTap](#multitap)
+- [Writing custom Interactions](#writing-custom-interactions)
An Interaction represents a specific input pattern. For example, a [hold](#hold) is an Interaction that requires a Control to be held for at least a minimum amount of time.
@@ -26,293 +25,4 @@ Interactions drive responses on Actions. You can place them on individual Bindin
-## Operation
-An Interaction has a set of distinct phases it can go through in response to receiving input.
-
-|Phase|Description|
-|-----|-----------|
-|`Waiting`|The Interaction is waiting for input.|
-|`Started`|The Interaction has been started (that is, it received some of its expected input), but is not complete yet.|
-|`Performed`|The Interaction is complete.|
-|`Canceled`|The Interaction was interrupted and aborted. For example, the user pressed and then released a button before the minimum time required for a [hold Interaction](#hold) to complete.|
-
-Not every Interaction triggers every phase, and the pattern in which specific Interactions trigger phases depends on the Interaction type.
-
-While `Performed` is typically the phase that triggers the actual response to an Interaction, `Started` and `Canceled` can be useful for providing UI feedback while the Interaction is in progress. For example, when a [hold](#hold) is `Started`, the app can display a progress bar that fills up until the hold time has been reached. If, however, the hold is `Canceled` before it completes, the app can reset the progress bar to the beginning.
-
-The following example demonstrates this kind of setup with a fire Action that the user can tap to fire immediately, or hold to charge:
-
-```CSharp
-var fireAction = new InputAction("fire");
-fireAction.AddBinding("/buttonSouth")
- // Tap fires, slow tap charges. Both act on release.
- .WithInteractions("tap,slowTap");
-
-fireAction.started +=
- context =>
- {
- if (context.interaction is SlowTapInteraction)
- ShowChargingUI();
- };
-
-fireAction.performed +=
- context =>
- {
- if (context.interaction is SlowTapInteraction)
- ChargedFire();
- else
- Fire();
- };
-
-fireAction.canceled +=
- _ => HideChargingUI();
-fireAction.Enable();
-```
-
-### Multiple Controls on an Action
-
-If you have multiple Controls bound to a Binding or an Action which has an Interaction, then the Input System first applies the [Control conflict resolution](ActionBindings.md#conflicting-inputs) logic to get a single value for the Action, which it then feeds to the Interaction logic. Any of the bound Controls can perform the Interaction.
-
-### Multiple Interactions on a Binding
-
-If multiple Interactions are present on a single Binding or Action, then the Input System checks the Interactions in the order they are present on the Binding. The code example [above](#operation) illustrates this example. The Binding on the `fireAction` Action has two Interactions: `WithInteractions("tap;slowTap")`. The [tap](#tap) Interaction gets a first chance at interpreting the input from the Action. If the button is pressed, the Action calls the `Started` callback on the tap Interaction. If the user keeps holding the button, the tap Interaction times out, and the Action calls the [`Canceled`](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_canceled) callback for the tap Interaction and starts processing the [slow tap](#slowtap) Interaction (which now receives a `Started` callback).
-
-At any one time, only one Interaction can be "driving" the action (that is, it gets to determine the action's current [`phase`](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_phase)). If an Interaction higher up in the stack cancels, Interactions lower down in the stack can take over.
-
-Note that the order of interactions can affect which interaction is passed to your callback function. For example, an action with [Tap](#tap), [MultiTap](#multitap) and [Hold](#hold) interactions will have different behaviour when the interactions are in a different order, such as [Hold](#hold), [MultiTap](#multitap) and [Tap](#tap). If you get unexpected behaviour, you may need to experiment with a different ordering.
-
-### Timeouts
-
-Interactions might need to wait a certain time for a specific input to occur or to not occur. An example of this is the [Hold](#hold) interaction which, after a button is pressed, has to wait for a set [duration](../api/UnityEngine.InputSystem.Interactions.HoldInteraction.html#UnityEngine_InputSystem_Interactions_HoldInteraction_duration) until the "hold" is complete. To do this, an interaction installs a timeout using [`SetTimeout`](../api/UnityEngine.InputSystem.InputInteractionContext.html#UnityEngine_InputSystem_InputInteractionContext_SetTimeout_System_Single_).
-
-It can be useful to know how much of a timeout is left for an interaction to complete. For example, you might want to display a bar in the UI that is charging up while the interaction is waiting to complete. To query the percentage to which a timeout has completed, use [`GetTimeoutCompletionPercentage`](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_GetTimeoutCompletionPercentage_).
-
-```CSharp
-// Returns a value between 0 (inclusive) and 1 (inclusive).
-var warpActionCompletion = playerInput.actions["warp"].GetTimeoutCompletionPercentage();
-```
-
-Note that each Interaction can have its own separate timeout (but only a single one at any one time). If [multiple interactions](#multiple-interactions-on-a-binding) are in effect, then [`GetTimeoutCompletionPercentage`](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_GetTimeoutCompletionPercentage_) will only use the timeout of the one interaction that is currently driving the action.
-
-Some Interactions might involve multiple timeouts in succession. In this case, knowing only the completion of the currently running timeout (if any) is often not useful. An example is [`MultiTapInteraction`](../api/UnityEngine.InputSystem.Interactions.MultiTapInteraction.html), which involves a timeout on each individual tap, as well as a timeout in-between taps. The Interaction is complete only after a full tap sequence has been performed.
-
-An Interaction can use [`SetTotalTimeoutCompletionTime`](../api/UnityEngine.InputSystem.InputInteractionContext.html#UnityEngine_InputSystem_InputInteractionContext_SetTotalTimeoutCompletionTime_System_Single_) to inform the Input System of the total time it will run timeouts for.
-
-## Using Interactions
-
-You can install Interactions on [Bindings](ActionBindings.md) or [Actions](Actions.md).
-
-### Interactions applied to Bindings
-
-When you create Bindings for your [Actions](Actions.md), you can choose to add Interactions to the Bindings.
-
-If you're using [project-wide actions](ActionsEditor.md), or [Input Action Assets](ActionAssets.md), you can add any Interaction to your Bindings in the Input Action editor. Once you [created some Bindings](ActionsEditor.md#bindings), select the Binding you want to add Interactions to, so that the right pane of the window shows the properties for that Binding. Next, click on the plus icon on the __Interactions__ foldout to open a list of all available Interactions types. Choose an Interaction type to add an Interaction instance of that type. The Interaction now appears in the __Interactions__ foldout. If the Interaction has any parameters, you can now edit them here as well:
-
-
-
-To remove an Interaction, click the minus button next to it. To change the [order of Interactions](#multiple-interactions-on-a-binding), click the up and down arrows.
-
-If you create your Bindings in code, you can add Interactions like this:
-
-```CSharp
-var Action = new InputAction();
-action.AddBinding("/leftStick")
- .WithInteractions("tap(duration=0.8)");
-```
-
-### Interactions applied to Actions
-
-Applying Interactions directly to an Action is equivalent to applying them to all Bindings for the Action. It is thus more or less a shortcut that avoids manually adding the same Interaction(s) to each of the Bindings.
-
-If Interactions are applied __both__ to an Action and to its Bindings, then the effect is the same as if the Action's Interactions are *appended* to the list of Interactions on each of the Bindings. This means that the Binding's Interactions are applied *first*, and then the Action's Interactions are applied *after*.
-
-You can add and edit Interactions on Actions in the [Input Action Assets](ActionAssets.md) editor window the [same way](#interactions-applied-to-bindings) as you would do for Bindings: select an Action to Edit, then add the Interactions in the right window pane.
-
-If you create your Actions in code, you can add Interactions like this:
-
-```CSharp
-var Action = new InputAction(Interactions: "tap(duration=0.8)");
-```
-
-## Predefined Interactions
-
-The Input System package comes with a set of basic Interactions you can use. If an Action has no Interactions set, the system uses its [default Interaction](#default-interaction).
-
->__Note__: The built-in Interactions operate on Control actuation and don't use Control values directly. The Input System evaluates the `pressPoint` parameters against the magnitude of the Control actuation. This means you can use these Interactions on any Control which has a magnitude, such as sticks, and not just on buttons.
-
-The following diagram shows the behavior of the built-in Interactions for a simple button press.
-
-
-
-### Default Interaction
-
-If you haven't specifically added an Interaction to a Binding or its Action, the default Interaction applies to the Binding.
-
-[`Value`](RespondingToActions.md#value) type Actions have the following behavior:
-
-1. As soon as a bound Control becomes [actuated](Controls.md#control-actuation), the Action goes from `Waiting` to `Started`, and then immediately to `Performed` and back to `Started`. One callback occurs on [`InputAction.started`](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_started), followed by one callback on [`InputAction.performed`](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_performed).
-2. For as long as the bound Control remains actuated, the Action stays in `Started` and triggers `Performed` whenever the value of the Control changes (that is, one call occurs to [`InputAction.performed`](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_performed)).
-3. When the bound Control stops being actuated, the Action goes to `Canceled` and then back to `Waiting`. One call occurs to [`InputAction.canceled`](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_canceled).
-
-[`Button`](RespondingToActions.md#button) type Actions have the following behavior:
-
-1. As soon as a bound Control becomes [actuated](Controls.md#control-actuation), the Action goes from `Waiting` to `Started`. One callback occurs on [`InputAction.started`](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_started).
-2. If a Control then reaches or exceeds the button press threshold, the Action goes from `Started` to `Performed`. One callback occurs on [`InputAction.performed`](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_performed). The default value of the button press threshold is defined in the [input settings](../api/UnityEngine.InputSystem.InputSettings.html#UnityEngine_InputSystem_InputSettings_defaultButtonPressPoint). However, an individual control can [override](../api/UnityEngine.InputSystem.Controls.ButtonControl.html#UnityEngine_InputSystem_Controls_ButtonControl_pressPoint) this value.
-3. Once the Action has `Performed`, if all Controls then go back to a level of actuation at or below the [release threshold](../api/UnityEngine.InputSystem.InputSettings.html#UnityEngine_InputSystem_InputSettings_buttonReleaseThreshold), the Action goes from `Performed` to `Canceled`. One call occurs to [`InputAction.canceled`](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_canceled).
-4. If the Action never went to `Performed`, it will go to `Canceled` as soon as all Controls are released. One call occurs to [`InputAction.canceled`](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_canceled).
-
-[`PassThrough`](RespondingToActions.md#pass-through) type Actions have a simpler behavior. The Input System doesn't try to track bound Controls as a single source of input. Instead, it triggers a `Performed` callback for each value change.
-
-|__Callback__|[`InputActionType.Value`](RespondingToActions.md#value)|[`InputActionType.Button`](RespondingToActions.md#button)|[`InputActionType.PassThrough`](RespondingToActions.md#pass-through)|
-|-----------|-------------|------------|-----------------|
-|[`started`](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_started)|Control(s) changed value away from the default value.|Button started being pressed but has not necessarily crossed the press threshold yet.|not used|
-|[`performed`](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_performed)|Control(s) changed value.|Button was pressed to at least the button [press threshold](../api/UnityEngine.InputSystem.InputSettings.html#UnityEngine_InputSystem_InputSettings_defaultButtonPressPoint).|Control changed value.|
-|[`canceled`](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_canceled)|Control(s) are no longer actuated.|Button was released. If the button was pressed above the press threshold, the button has now fallen to or below the [release threshold](../api/UnityEngine.InputSystem.InputSettings.html#UnityEngine_InputSystem_InputSettings_buttonReleaseThreshold). If the button was never fully pressed, the button is now back to completely unpressed.|Action is disabled.|
-
-### Press
-
-You can use a [`PressInteraction`](../api/UnityEngine.InputSystem.Interactions.PressInteraction.html) to explicitly force button-like interactions. Use the [`behavior`](../api/UnityEngine.InputSystem.Interactions.PressInteraction.html#UnityEngine_InputSystem_Interactions_PressInteraction_behavior) parameter to select if the Interaction should trigger on button press, release, or both.
-
-|__Parameters__|Type|Default value|
-|---|---|---|
-|[`pressPoint`](../api/UnityEngine.InputSystem.Interactions.PressInteraction.html#UnityEngine_InputSystem_Interactions_PressInteraction_pressPoint)|`float`|[`InputSettings.defaultButtonPressPoint`](../api/UnityEngine.InputSystem.InputSettings.html#UnityEngine_InputSystem_InputSettings_defaultButtonPressPoint)|
-|[`behavior`](../api/UnityEngine.InputSystem.Interactions.PressInteraction.html#UnityEngine_InputSystem_Interactions_PressInteraction_behavior)|[`PressBehavior`](../api/UnityEngine.InputSystem.Interactions.PressBehavior.html)|`PressOnly`|
-
-
-|__Callbacks__/[`behavior`](../api/UnityEngine.InputSystem.Interactions.PressInteraction.html#UnityEngine_InputSystem_Interactions_PressInteraction_behavior)|`PressOnly`|`ReleaseOnly`|`PressAndRelease`|
-|---|-----------|-------------|-----------------|
-|[`started`](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_started)|Control magnitude crosses [`pressPoint`](../api/UnityEngine.InputSystem.Interactions.PressInteraction.html#UnityEngine_InputSystem_Interactions_PressInteraction_pressPoint)|Control magnitude crosses [`pressPoint`](../api/UnityEngine.InputSystem.Interactions.PressInteraction.html#UnityEngine_InputSystem_Interactions_PressInteraction_pressPoint)|Control magnitude crosses [`pressPoint`](../api/UnityEngine.InputSystem.Interactions.PressInteraction.html#UnityEngine_InputSystem_Interactions_PressInteraction_pressPoint)|
-|[`performed`](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_performed)|Control magnitude crosses [`pressPoint`](../api/UnityEngine.InputSystem.Interactions.PressInteraction.html#UnityEngine_InputSystem_Interactions_PressInteraction_pressPoint)|Control magnitude goes back below [`pressPoint`](../api/UnityEngine.InputSystem.Interactions.PressInteraction.html#UnityEngine_InputSystem_Interactions_PressInteraction_pressPoint)|- Control magnitude crosses [`pressPoint`](../api/UnityEngine.InputSystem.Interactions.PressInteraction.html#UnityEngine_InputSystem_Interactions_PressInteraction_pressPoint)() == 1)
- {
- context.Started();
- context.SetTimeout(duration);
- }
- break;
-
- case InputActionPhase.Started:
- if (context.Control.ReadValue() == -1)
- context.Performed();
- break;
- }
- }
-
- // Unlike processors, Interactions can be stateful, meaning that you can keep a
- // local state that mutates over time as input is received. The system might
- // invoke the Reset() method to ask Interactions to reset to the local state
- // at certain points.
- void Reset()
- {
- }
-}
-```
-
-Now, you need to tell the Input System about your Interaction. Call this method in your initialization code:
-
-```CSharp
-InputSystem.RegisterInteraction();
-```
-
-Your new Interaction is now available in the [Input Action Asset Editor window](ActionAssets.md). You can also add it in code like this:
-
-```CSharp
-var Action = new InputAction(Interactions: "MyWiggle(duration=0.5)");
-```
diff --git a/Packages/com.unity.inputsystem/Documentation~/Migration.md b/Packages/com.unity.inputsystem/Documentation~/Migration.md
index 8f313acd08..89ef7f71b2 100644
--- a/Packages/com.unity.inputsystem/Documentation~/Migration.md
+++ b/Packages/com.unity.inputsystem/Documentation~/Migration.md
@@ -17,7 +17,7 @@ This page is provided to help you match input-related API from Unity's old, buil
## Read the introductory documentation first
-If you're new to the Input System package and have landed on this page looking for documentation, it's best to read the [QuickStart Guide](QuickStartGuide.md), and the [Concepts](Concepts.md) and [Workflows](Workflows.md) pages from the introduction section of the documentation, so that you can make sure you're choosing the best workflow for your project's input requirements.
+If you're new to the Input System package and have landed on this page looking for documentation, it's best to read the [QuickStart Guide](quick-start-guide.md), and the [Concepts](understanding-input.md) and [Workflows](workflows.md) pages from the introduction section of the documentation, so that you can make sure you're choosing the best workflow for your project's input requirements.
This is because there are a number of different ways to read input using the Input System, and some of the directly corresponding API methods on this page might give you the quickest - but least flexible - solution, and may not be suitable for a project with more complex requirements.
@@ -78,7 +78,7 @@ Then, to read the action values, use the following:
### Directly reading Gamepad and Joystick controls
-Directly reading hardware controls bypasses the new Input System's action-based workflow, which has some benefits and some drawbacks. ([Read more about directly reading devices](./Workflow-Direct.md))
+Directly reading hardware controls bypasses the new Input System's action-based workflow, which has some benefits and some drawbacks. ([Read more about directly reading devices](./using-direct-workflow.md))
|Input Manager (Old)|Input System (New)|
diff --git a/Packages/com.unity.inputsystem/Documentation~/Mouse.md b/Packages/com.unity.inputsystem/Documentation~/Mouse.md
index dbcb1122a0..aca8e13677 100644
--- a/Packages/com.unity.inputsystem/Documentation~/Mouse.md
+++ b/Packages/com.unity.inputsystem/Documentation~/Mouse.md
@@ -3,7 +3,7 @@ uid: input-system-mouse
---
# Mouse support
-The Input System represents mouse input with the [`Mouse`](../api/UnityEngine.InputSystem.Mouse.html) Device layout that the [`Mouse`](../api/UnityEngine.InputSystem.Mouse.html) class implements. Mice are based on the [`Pointer`](Pointers.md) layout.
+The Input System represents mouse input with the [`Mouse`](../api/UnityEngine.InputSystem.Mouse.html) Device layout that the [`Mouse`](../api/UnityEngine.InputSystem.Mouse.html) class implements. Mice are based on the [`Pointer`](pointers.md) layout.
To query the last used or last added mouse, use [`Mouse.current`](../api/UnityEngine.InputSystem.Mouse.html#UnityEngine_InputSystem_Mouse_current).
@@ -17,7 +17,7 @@ To query the last used or last added mouse, use [`Mouse.current`](../api/UnityEn
## Controls
-In addition to the [Controls inherited from `Pointer`](Pointers.md#controls), Mouse devices implement the following Controls:
+In addition to the [Controls inherited from `Pointer`](pointers.md#controls), Mouse devices implement the following Controls:
|Control|Type|Description|
|-------|----|-----------|
diff --git a/Packages/com.unity.inputsystem/Documentation~/Pen.md b/Packages/com.unity.inputsystem/Documentation~/Pen.md
index 1202906f8c..92ad19bf34 100644
--- a/Packages/com.unity.inputsystem/Documentation~/Pen.md
+++ b/Packages/com.unity.inputsystem/Documentation~/Pen.md
@@ -7,7 +7,7 @@ Pen support comprises both tablets on desktops (such as the various tablets prod
Pens generally offer pressure sensitivity, in-range detection (being able to control the cursor while not yet touching the tablet/screen surface), and often the ability to flip the pen for eraser-like behavior.
-Pens are represented by the [`Pen`](../api/UnityEngine.InputSystem.Pen.html) Device layout implemented by the [`Pen`](../api/UnityEngine.InputSystem.Pen.html) class. Pens are based on the [`Pointer`](Pointers.md) layout.
+Pens are represented by the [`Pen`](../api/UnityEngine.InputSystem.Pen.html) Device layout implemented by the [`Pen`](../api/UnityEngine.InputSystem.Pen.html) class. Pens are based on the [`Pointer`](pointers.md) layout.
You can query the last used or last added pen with [`Pen.current`](../api/UnityEngine.InputSystem.Pen.html#UnityEngine_InputSystem_Pen_current).
@@ -18,7 +18,7 @@ You can query the last used or last added pen with [`Pen.current`](../api/UnityE
## Controls
-In addition to the [Controls inherited from `Pointer`](Pointers.md#controls), pen Devices implement the following Controls:
+In addition to the [Controls inherited from `Pointer`](pointers.md#controls), pen Devices implement the following Controls:
|Control|Type|Description|
|-------|----|-----------|
diff --git a/Packages/com.unity.inputsystem/Documentation~/PlayerInputManager.md b/Packages/com.unity.inputsystem/Documentation~/PlayerInputManager.md
index e7a581cdbd..aac755eba8 100644
--- a/Packages/com.unity.inputsystem/Documentation~/PlayerInputManager.md
+++ b/Packages/com.unity.inputsystem/Documentation~/PlayerInputManager.md
@@ -5,15 +5,15 @@ uid: input-system-player-input-manager
>NOTE: The Input System package comes with a sample called `Simple Multiplayer` which you can install from the package manager UI in the Unity editor. The sample demonstrates how to use [`PlayerInputManager`](../api/UnityEngine.InputSystem.PlayerInputManager.html) to set up a simple local multiplayer scenario.
-The [`Player Input`](PlayerInput.md) system facilitates setting up local multiplayer games, where multiple players share a single screen and multiple controllers. You can set this up using the [`PlayerInputManager`](../api/UnityEngine.InputSystem.PlayerInputManager.html) component, which automatically manages the creation and lifetime of `PlayerInput` instances as players join and leave the game.
+The [`Player Input`](player-input-component.md) system facilitates setting up local multiplayer games, where multiple players share a single screen and multiple controllers. You can set this up using the [`PlayerInputManager`](../api/UnityEngine.InputSystem.PlayerInputManager.html) component, which automatically manages the creation and lifetime of `PlayerInput` instances as players join and leave the game.
|Property|Description|
|--------|-----------|
-|[`Notification Behavior`](../api/UnityEngine.InputSystem.PlayerInputManager.html#UnityEngine_InputSystem_PlayerInputManager_notificationBehavior)|How the [`PlayerInputManager`](../api/UnityEngine.InputSystem.PlayerInput.html) component notifies game code about changes to the connected players. [This works the same way as for the `PlayerInput` component](PlayerInput.md#notification-behaviors).|
+|[`Notification Behavior`](../api/UnityEngine.InputSystem.PlayerInputManager.html#UnityEngine_InputSystem_PlayerInputManager_notificationBehavior)|How the [`PlayerInputManager`](../api/UnityEngine.InputSystem.PlayerInput.html) component notifies game code about changes to the connected players. [This works the same way as for the `PlayerInput` component](player-input-component.md#notification-behaviors).|
|[`Join Behavior`](../api/UnityEngine.InputSystem.PlayerInputManager.html#UnityEngine_InputSystem_PlayerInputManager_joinBehavior)|Determines the mechanism by which players can join when joining is enabled. See documentation on [join behaviors](#join-behaviors).|
-|[`Player Prefab`](../api/UnityEngine.InputSystem.PlayerInputManager.html#UnityEngine_InputSystem_PlayerInputManager_playerPrefab)|A prefab that represents a player in the game. The [`PlayerInputManager`](../api/UnityEngine.InputSystem.PlayerInputManager.html) component creates an instance of this prefab whenever a new player joins. This prefab must have one [`PlayerInput`](PlayerInput.md) component in its hierarchy.|
+|[`Player Prefab`](../api/UnityEngine.InputSystem.PlayerInputManager.html#UnityEngine_InputSystem_PlayerInputManager_playerPrefab)|A prefab that represents a player in the game. The [`PlayerInputManager`](../api/UnityEngine.InputSystem.PlayerInputManager.html) component creates an instance of this prefab whenever a new player joins. This prefab must have one [`PlayerInput`](player-input-component.md) component in its hierarchy.|
|[`Joining Enabled By Default`](../api/UnityEngine.InputSystem.PlayerInputManager.html#UnityEngine_InputSystem_PlayerInputManager_joiningEnabled)|While this is enabled, new players can join via the mechanism determined by [`Join Behavior`](../api/UnityEngine.InputSystem.PlayerInputManager.html#UnityEngine_InputSystem_PlayerInputManager_joinBehavior).|
|[`Limit Number of Players`](../api/UnityEngine.InputSystem.PlayerInputManager.html#UnityEngine_InputSystem_PlayerInputManager_maxPlayerCount)|Enable this if you want to limit the number of players who can join the game.|
|[`Max Player Count`](../api/UnityEngine.InputSystem.PlayerInputManager.html#UnityEngine_InputSystem_PlayerInputManager_maxPlayerCount)(Only shown when `Limit number of Players` is enabled.)|The maximum number of players allowed to join the game.|
@@ -27,7 +27,7 @@ You can use the [`Join Behavior`](../api/UnityEngine.InputSystem.PlayerInputMana
|--------|-----------|
|[`Join Players When Button IsPressed`](../api/UnityEngine.InputSystem.PlayerJoinBehavior.html)|Listen for button presses on Devices that are not paired to any player. If a player presses a button and joining is allowed, join the new player using the Device they pressed the button on.|
|[`Join Players When Join Action Is Triggered`](../api/UnityEngine.InputSystem.PlayerJoinBehavior.html)|Similar to `Join Players When Button IsPressed`, but this only joins a player if the control they triggered matches a specific action you define. For example, you can set up players to join when pressing a specific gamepad button.|
-|[`Join Players Manually`](../api/UnityEngine.InputSystem.PlayerJoinBehavior.html)|Don't join players automatically. Call [`JoinPlayer`](../api/UnityEngine.InputSystem.PlayerInputManager.html#UnityEngine_InputSystem_PlayerInputManager_JoinPlayer_System_Int32_System_Int32_System_String_UnityEngine_InputSystem_InputDevice_) explicitly to join new players. Alternatively, create GameObjects with [`PlayerInput`](PlayerInput.md) components directly and the Input System will automatically join them.|
+|[`Join Players Manually`](../api/UnityEngine.InputSystem.PlayerJoinBehavior.html)|Don't join players automatically. Call [`JoinPlayer`](../api/UnityEngine.InputSystem.PlayerInputManager.html#UnityEngine_InputSystem_PlayerInputManager_JoinPlayer_System_Int32_System_Int32_System_String_UnityEngine_InputSystem_InputDevice_) explicitly to join new players. Alternatively, create GameObjects with [`PlayerInput`](player-input-component.md) components directly and the Input System will automatically join them.|
### Split-screen
@@ -41,15 +41,15 @@ If you enable the [`Split-Screen`](../api/UnityEngine.InputSystem.PlayerInputMan
|[`Set Fixed Number`](../api/UnityEngine.InputSystem.PlayerInputManager.html#UnityEngine_InputSystem_PlayerInputManager_fixedNumberOfSplitScreens)|If this value is greater than zero, the [`PlayerInputManager`](../api/UnityEngine.InputSystem.PlayerInputManager.html) always splits the screen into a fixed number of rectangles, regardless of the actual number of players.|
|[`Screen Rectangle`](../api/UnityEngine.InputSystem.PlayerInputManager.html#UnityEngine_InputSystem_PlayerInputManager_splitScreenArea)|The normalized screen rectangle available for allocating player split-screens into.|
-By default, any player in the game can interact with any UI elements. However, in split-screen setups, your game can have screen-space UIs that are restricted to just one specific camera. See the [UI Input](PlayerInput.md#ui-input) section on the Player Input component page on how to set this up using the Player Input component, [`InputSystemUIInputModule`](UISupport.md#setting-up-ui-input) and [`MultiplayerEventSystem`](UISupport.md#multiplayer-uis) components.
+By default, any player in the game can interact with any UI elements. However, in split-screen setups, your game can have screen-space UIs that are restricted to just one specific camera. See the [UI Input](player-input-component.md#ui-input) section on the Player Input component page on how to set this up using the Player Input component, [`InputSystemUIInputModule`](UISupport.md#setting-up-ui-input) and [`MultiplayerEventSystem`](UISupport.md#multiplayer-uis) components.
### `PlayerInputManager` notifications
-`PlayerInputManager` sends notifications when something notable happens with the current player setup. These notifications are delivered according to the `Notification Behavior` property, in the [same way as for `PlayerInput`](PlayerInput.md#notification-behaviors).
+`PlayerInputManager` sends notifications when something notable happens with the current player setup. These notifications are delivered according to the `Notification Behavior` property, in the [same way as for `PlayerInput`](player-input-component.md#notification-behaviors).
Your game can listen to the following notifications:
|Notification|Description|
|------------|-----------|
|[`PlayerJoinedMessage`](../api/UnityEngine.InputSystem.PlayerInputManager.html#UnityEngine_InputSystem_PlayerInputManager_PlayerJoinedMessage)|A new player joined the game. Passes the [`PlayerInput`](PlayerInput.md`PlayerInputManager` sends a `Player Joined` notification for each of these.|
-|[`PlayerLeftMessage`](../api/UnityEngine.InputSystem.PlayerInputManager.html#UnityEngine_InputSystem_PlayerInputManager_PlayerLeftMessage)|A player left the game. Passes the [`PlayerInput`](PlayerInput.md) instance of the player who left.|
+|[`PlayerLeftMessage`](../api/UnityEngine.InputSystem.PlayerInputManager.html#UnityEngine_InputSystem_PlayerInputManager_PlayerLeftMessage)|A player left the game. Passes the [`PlayerInput`](player-input-component.md) instance of the player who left.|
diff --git a/Packages/com.unity.inputsystem/Documentation~/Processors.md b/Packages/com.unity.inputsystem/Documentation~/Processors.md
index 05d1740ed3..ee5506e07b 100644
--- a/Packages/com.unity.inputsystem/Documentation~/Processors.md
+++ b/Packages/com.unity.inputsystem/Documentation~/Processors.md
@@ -26,280 +26,5 @@ An Input Processor takes a value and returns a processed result for it. The rece
* [Stick deadzone](#stick-deadzone)
* [Writing custom Processors](#writing-custom-processors)
-## Using Processors
-You can install Processors on [bindings](ActionBindings.md), [actions](Actions.md) or on [controls](Controls.md).
-Each Processor is [registered](../api/UnityEngine.InputSystem.InputSystem.html#UnityEngine_InputSystem_InputSystem_RegisterProcessor__1_System_String_) using a unique name. To replace an existing Processor, register your own Processor under an existing name.
-
-Processors can have parameters which can be booleans, integers, or floating-point numbers. When created in data such as [bindings](./ActionBindings.md), processors are described as strings that look like function calls:
-
-```CSharp
- // This references the processor registered as "scale" and sets its "factor"
- // parameter (a floating-point value) to a value of 2.5.
-
- "scale(factor=2.5)"
-
- // Multiple processors can be chained together. They are processed
- // from left to right.
- //
- // Example: First invert the value, then normalize [0..10] values to [0..1].
-
- "invert,normalize(min=0,max=10)"
-```
-
-### Processors on Bindings
-
-When you create Bindings for your [actions](Actions.md), you can choose to add Processors to the Bindings. These process the values from the controls they bind to, before the system applies them to the Action value. For instance, you might want to invert the `Vector2` values from the controls along the Y axis before passing these values to the Action that drives the input logic for your application. To do this, you can add an [Invert Vector2](#invert-vector-2) Processor to your Binding.
-
-If you're using Actions defined in the [Input Actions Editor](ActionsEditor.md), or in an [Action Asset](ActionAssets.md), you can add any Processor to your Bindings in the Input Action editor. Select the Binding you want to add Processors to so that the right pane of the window displays the properties for that Binding. Select the Add (+) icon on the __Processors__ foldout to open a list of all available Processors that match your control type, then choose a Processor type to add a Processor instance of that type. The Processor now appears under the __Processors__ foldout. If the Processor has any parameters, you can edit them in the __Processors__ foldout.
-
-
-
-To remove a Processor, click the Remove (-) icon next to it. You can also use the up and down arrows to change the order of Processors. This affects the order in which the system processes values.
-
-If you create your Bindings in code, you can add Processors like this:
-
-```CSharp
-var action = new InputAction();
-action.AddBinding("/leftStick")
- .WithProcessor("invertVector2(invertX=false)");
-```
-
-### Processors on Actions
-
-Processors on Actions work in the same way as Processors on Bindings, but they affect all controls bound to an Action, rather than just the controls from a specific Binding. If there are Processors on both the Binding and the Action, the system processes the ones from the Binding first.
-
-You can add and edit Processors on Actions in the [Input Actions Editor](ActionsEditor.md), or in an [Action Asset](ActionAssets.md) the [same way](#processors-on-bindings) as you would for Bindings: select an Action to edit, then add one or more Processors in the right window pane.
-
-If you create your Actions in code, you can add Processors like this:
-
-```CSharp
-var action = new InputAction(processors: "invertVector2(invertX=false)");
-```
-
-### Processors on Controls
-
-You can have any number of Processors directly on an [`InputControl`](../api/UnityEngine.InputSystem.InputControl.html), which then process the values read from the Control. Whenever you call [`ReadValue`](../api/UnityEngine.InputSystem.InputControl-1.html#UnityEngine_InputSystem_InputControl_1_ReadValue) on a Control, all Processors on that Control process the value before it gets returned to you. You can use [`ReadUnprocessedValue`](../api/UnityEngine.InputSystem.InputControl-1.html#UnityEngine_InputSystem_InputControl_1_ReadUnprocessedValue) on a Control to bypass the Processors.
-
-The Input System adds Processors to a Control during device creation, if they're specified in the Control's [layout](Layouts.md). You can't add Processors to existing Controls after they've been created, so you can only add Processors to Controls when you're [creating custom devices](Devices.md#creating-custom-devices). The devices that the Input System supports out of the box already have some useful Processors added on their Controls. For instance, sticks on gamepads have a [Stick Deadzone](#stick-deadzone) Processor.
-
-If you're using a layout generated by the Input System from a [state struct](Devices.md#step-1-the-state-struct) using [`InputControlAttributes`](../api/UnityEngine.InputSystem.Layouts.InputControlAttribute.html), you can specify the Processors you want to use via the [`processors`](../api/UnityEngine.InputSystem.Layouts.InputControlAttribute.html#UnityEngine_InputSystem_Layouts_InputControlAttribute_processors) property of the attribute, like this:
-
-```CSharp
-public struct MyDeviceState : IInputStateTypeInfo
-{
- public FourCC format => return new FourCC('M', 'Y', 'D', 'V');
-
- // Add an axis deadzone to the Control to ignore values
- // smaller then 0.2, as our Control does not have a stable
- // resting position.
- [InputControl(layout = "Axis", processors = "AxisDeadzone(min=0.2)")]
- public short axis;
-}
-```
-
-If you [create a layout from JSON](Layouts.md#layout-from-json), you can specify Processors on your Controls like this:
-
-```CSharp
-{
- "name" : "MyDevice",
- "extend" : "Gamepad", // Or some other thing
- "controls" : [
- {
- "name" : "axis",
- "layout" : "Axis",
- "offset" : 4,
- "format" : "FLT",
- "processors" : "AxisDeadzone(min=0.2)"
- }
- ]
-}
-```
-
-## Predefined Processors
-
-The Input System package comes with a set of useful Processors you can use.
-
-### Clamp
-
-|__Name__|[`Clamp`](../api/UnityEngine.InputSystem.Processors.ClampProcessor.html)|
-|---|---|
-|__Operand Type__|`float`|
-|__Parameters__|`float min``](../api/UnityEngine.InputSystem.InputProcessor-1.html), and implement the [`Process`](../api/UnityEngine.InputSystem.InputProcessor-1.html#UnityEngine_InputSystem_InputProcessor_1_Process__0_UnityEngine_InputSystem_InputControl_) method:
-
->__IMPORTANT__: Processors must be __stateless__. This means you cannot store local state in a processor that will change depending on the input being processed. The reason for this is because processors are not part of the [input state](./Controls.md#control-state) that the Input System keeps.
-
-```CSharp
-public class MyValueShiftProcessor : InputProcessor
-{
- [Tooltip("Number to add to incoming values.")]
- public float valueShift = 0;
-
- public override float Process(float value, InputControl control)
- {
- return value + valueShift;
- }
-}
-```
-
-Now, you need to tell the Input System about your Processor. Call [`InputSystem.RegisterProcessor`](../api/UnityEngine.InputSystem.InputSystem.html#UnityEngine_InputSystem_InputSystem_RegisterProcessor__1_System_String_) in your initialization code. You can do so locally within the Processor class like this:
-
-```CSharp
-#if UNITY_EDITOR
-[InitializeOnLoad]
-#endif
-public class MyValueShiftProcessor : InputProcessor
-{
- #if UNITY_EDITOR
- static MyValueShiftProcessor()
- {
- Initialize();
- }
- #endif
-
- [RuntimeInitializeOnLoadMethod(RuntimeInitializeLoadType.BeforeSceneLoad)]
- static void Initialize()
- {
- InputSystem.RegisterProcessor();
- }
-
- //...
-}
-```
-
-Your new Processor is now available in the in the [Input Actions Editor](ActionsEditor.md) and you can also add it in code like this:
-
-```CSharp
-var action = new InputAction(processors: "myvalueshift(valueShift=2.3)");
-```
-
-If you want to customize the UI for editing your Processor, create a custom [`InputParameterEditor`](../api/UnityEngine.InputSystem.Editor.InputParameterEditor-1.html) class for it:
-
-```CSharp
-// No registration is necessary for an InputParameterEditor.
-// The system will automatically find subclasses based on the
-// <..> type parameter.
-#if UNITY_EDITOR
-public class MyValueShiftProcessorEditor : InputParameterEditor
-{
- private GUIContent m_SliderLabel = new GUIContent("Shift By");
-
- public override void OnEnable()
- {
- // Put initialization code here. Use 'target' to refer
- // to the instance of MyValueShiftProcessor that is being
- // edited.
- }
-
- public override void OnGUI()
- {
- // Define your custom UI here using EditorGUILayout.
- target.valueShift = EditorGUILayout.Slider(m_SliderLabel,
- target.valueShift, 0, 10);
- }
-}
-#endif
-```
diff --git a/Packages/com.unity.inputsystem/Documentation~/ProjectWideActions.md b/Packages/com.unity.inputsystem/Documentation~/ProjectWideActions.md
deleted file mode 100644
index 6248dea44f..0000000000
--- a/Packages/com.unity.inputsystem/Documentation~/ProjectWideActions.md
+++ /dev/null
@@ -1,64 +0,0 @@
----
-uid: project-wide-actions
----
-# Project-Wide Actions
-
-The Input System stores your configuration of [Input Actions](Actions.md) and their associated [Bindings](ActionBindings.md), [Action Maps](ActionsEditor.html#configure-action-maps) and [Control Schemes](ActionBindings.md#control-schemes) in an [Action Asset](ActionAssets.md) file.
-
-While it's possible to have more than one Action Asset in a project, most projects only ever need a single Action Asset. This is because an Action Asset can contain multiple [Action Maps](ActionsEditor.html#configure-action-maps), which each containing a set of actions relevant to the various parts of your project (such as UI navigation, gameplay, etc).
-
-The Input System's **project-wide actions** feature allows you to choose an individual Action Asset as being available project-wide, which means the actions within that asset are available more conveniently through the Input System API without needing to set up a reference to the Actions Asset.
-
-The Action Asset assigned as project-wide is also a [preloaded asset](https://docs.unity3d.com/ScriptReference/PlayerSettings.GetPreloadedAssets.html), loaded when your app starts up, and kept available until until it terminates.
-
-Unless you have specific project requirements that require more than one Action Asset, the recommended workflow is to use a single Action Asset assigned as the project-wide actions, as described below.
-
-## Create and Assign a Project-Wide Actions Asset
-
-To create and assign the current project-wide actions, go to **Edit** > **Project Settings** > **Input System Package**.
-
-If you don't yet have an Action Asset assigned as project-wide in your project, the Input System Package settings window displays an empty field for you to assign your action asset, and a button allowing you to create and assign one.
-
-*The Input System Package Project Settings with no project-wide actions assigned*
-
-> **Note:** If you already have an Action Asset assigned, this button is not displayed, and instead the Actions Editor is displayed, allowing you to edit the project-wide actions.
-
-To create an Action Asset with default actions pre-configured, click **"Create a new project-wide Action Asset"**. The asset is created in your project, and automatically assigned as the **project-wide actions**.
-
-The Action Asset appears in your Project view, and is named "InputSystem_Actions". This is where your new configuration of actions is saved, including any changes you make to it.
-
-();
- // your code would then use moveValue to apply movement
- // to your GameObject
- }
-}
-```
-
-Note that the value type has to correspond to the value type of the control that the value is being read from.
-
-There are two methods you can use to poll for `performed` [action callbacks](#action-callbacks) to determine whether an action was performed or stopped performing in the current frame.
-
-These methods differ from [`InputAction.WasPressedThisFrame()`](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_WasPressedThisFrame) and [`InputAction.WasReleasedThisFrame()`](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_WasReleasedThisFrame) in that these depend directly on the [Interactions](Interactions.md) driving the action (including the [default Interaction](Interactions.md#default-interaction) if no specific interaction has been added to the action or binding).
-
-|Method|Description|
-|------|-----------|
-|[`InputAction.WasPerformedThisFrame()`](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_WasPerformedThisFrame)|True if the [`InputAction.phase`](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_phase) of the action has, at any point during the current frame, changed to [`Performed`](../api/UnityEngine.InputSystem.InputActionPhase.html#UnityEngine_InputSystem_InputActionPhase_Performed).|
-|[`InputAction.WasCompletedThisFrame()`](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_WasCompletedThisFrame)|True if the [`InputAction.phase`](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_phase) of the action has, at any point during the current frame, changed away from [`Performed`](../api/UnityEngine.InputSystem.InputActionPhase.html#UnityEngine_InputSystem_InputActionPhase_Performed) to any other phase. This can be useful for [Button](#button) actions or [Value](#value) actions with interactions like [Press](Interactions.md#press) or [Hold](Interactions.md#hold) when you want to know the frame the interaction stops being performed. For actions with the [default Interaction](Interactions.md#default-interaction), this method will always return false for [Value](#value) and [Pass-Through](#pass-through) actions (since the phase stays in [`Started`](../api/UnityEngine.InputSystem.InputActionPhase.html#UnityEngine_InputSystem_InputActionPhase_Started) for Value actions and stays in [`Performed`](../api/UnityEngine.InputSystem.InputActionPhase.html#UnityEngine_InputSystem_InputActionPhase_Performed) for Pass-Through).|
-
-This example uses the Interact action from the [default actions](./ProjectWideActions.md#the-default-actions), which has a [Hold](Interactions.md#hold) interaction to make it perform only after the bound control is held for a period of time (for example, 0.4 seconds):
-
-```CSharp
-using UnityEngine;
-using UnityEngine.InputSystem;
-
-public class Example : MonoBehaviour
-{
- InputAction interactAction;
-
- private void Start()
- {
- interactAction = InputSystem.actions.FindAction("Interact");
- }
-
- void Update()
- {
- if (interactAction.WasPerformedThisFrame())
- {
- // your code to respond to the first frame that the Interact action is held for enough time
- }
-
- if (interactAction.WasCompletedThisFrame())
- {
- // your code to respond to the frame that the Interact action is released after being held for enough time
- }
- }
-}
-```
-
-Finally, there are three methods you can use to poll for button presses and releases:
-
-|Method|Description|
-|------|-----------|
-|[`InputAction.IsPressed()`](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_IsPressed)|True if the level of [actuation](../api/UnityEngine.InputSystem.InputControl.html#UnityEngine_InputSystem_InputControl_EvaluateMagnitude) on the action has crossed the [press point](../api/UnityEngine.InputSystem.InputSettings.html#UnityEngine_InputSystem_InputSettings_defaultButtonPressPoint) and did not yet fall to or below the [release threshold](../api/UnityEngine.InputSystem.InputSettings.html#UnityEngine_InputSystem_InputSettings_buttonReleaseThreshold).|
-|[`InputAction.WasPressedThisFrame()`](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_WasPressedThisFrame)|True if the level of [actuation](../api/UnityEngine.InputSystem.InputControl.html#UnityEngine_InputSystem_InputControl_EvaluateMagnitude) on the action has, at any point during the current frame, reached or gone above the [press point](../api/UnityEngine.InputSystem.InputSettings.html#UnityEngine_InputSystem_InputSettings_defaultButtonPressPoint).|
-|[`InputAction.WasReleasedThisFrame()`](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_WasReleasedThisFrame)|True if the level of [actuation](../api/UnityEngine.InputSystem.InputControl.html#UnityEngine_InputSystem_InputControl_EvaluateMagnitude) on the action has, at any point during the current frame, gone from being at or above the [press point](../api/UnityEngine.InputSystem.InputSettings.html#UnityEngine_InputSystem_InputSettings_defaultButtonPressPoint) to at or below the [release threshold](../api/UnityEngine.InputSystem.InputSettings.html#UnityEngine_InputSystem_InputSettings_buttonReleaseThreshold).|
-
-This example uses three actions called Shield, Teleport and Submit (which are not included in the [default actions](./ProjectWideActions.md#the-default-actions)):
-
-```CSharp
-using UnityEngine;
-using UnityEngine.InputSystem;
-
-public class Example : MonoBehaviour
-{
- InputAction shieldAction;
- InputAction teleportAction;
- InputAction submitAction;
-
- private void Start()
- {
- shieldAction = InputSystem.actions.FindAction("Shield");
- teleportAction = InputSystem.actions.FindAction("Teleport");
- submitAction = InputSystem.actions.FindAction("Submit");
- }
-
- void Update()
- {
- if (shieldAction.IsPressed())
- {
- // shield is active for every frame that the shield action is pressed
- }
-
- if (teleportAction.WasPressedThisFrame())
- {
- // teleport occurs on the first frame that the action is pressed, and not again until the button is released
- }
-
- if (submit.WasReleasedThisFrame())
- {
- // submit occurs on the frame that the action is released, a common technique for buttons relating to UI controls.
- }
- }
-}
-```
-
-
-
-## Responding to Actions using callbacks
-
-When you set up callbacks for your Action, the Action informs your code that a certain type of input has occurred, and your code can then respond accordingly.
-
-There are several ways to do this:
-
-1. You can use the [PlayerInput component](Workflow-PlayerInput.md) to set up callbacks in the inspector.
-1. Each Action has a [`started`, `performed`, and `canceled` callback](#action-callbacks).
-1. Each Action Map has an [`actionTriggered` callback](#inputactionmapactiontriggered-callback).
-1. The Input System has a global [`InputSystem.onActionChange` callback](#inputsystemonactionchange-callback).
-2. [`InputActionTrace`](#inputactiontrace) can record changes happening on Actions.
-
-#### The PlayerInput component
-
-The PlayerInput component is the simplest way to set up Action callbacks. It provides an interface in the inspector that allows you set up callbacks directly to your methods without requiring intermediate code. [Read more about the PlayerInput component](Workflow-PlayerInput.md).
-
-Alternatively, you can implement callbacks entirely from your own code using the following workflow:
-
-
-#### Action callbacks
-
-Every Action has a set of distinct phases it can go through in response to receiving input.
-
-|Phase|Description|
-|-----|-----------|
-|`Disabled`|The Action is disabled and can't receive input.|
-|`Waiting`|The Action is enabled and is actively waiting for input.|
-|`Started`|The Input System has received input that started an Interaction with the Action.|
-|`Performed`|An Interaction with the Action has been completed.|
-|`Canceled`|An Interaction with the Action has been canceled.|
-
-You can read the current phase of an action using [`InputAction.phase`](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_phase).
-
-The `Started`, `Performed`, and `Canceled` phases each have a callback associated with them:
-
-```CSharp
- var action = new InputAction();
-
- action.started += context => /* Action was started */;
- action.performed += context => /* Action was performed */;
- action.canceled += context => /* Action was canceled */;
-```
-
-Each callback receives an [`InputAction.CallbackContext`](../api/UnityEngine.InputSystem.InputAction.CallbackContext.html) structure, which holds context information that you can use to query the current state of the Action and to read out values from Controls that triggered the Action ([`InputAction.CallbackContext.ReadValue`](../api/UnityEngine.InputSystem.InputAction.CallbackContext.html#UnityEngine_InputSystem_InputAction_CallbackContext_ReadValue__1)).
-
->__Note__: The contents of the structure are only valid for the duration of the callback. In particular, it isn't safe to store the received context and later access its properties from outside the callback.
-
-When and how the callbacks are triggered depends on the [Interactions](Interactions.md) present on the respective Bindings. If the Bindings have no Interactions that apply to them, the [default Interaction](Interactions.md#default-interaction) applies.
-
-##### `InputActionMap.actionTriggered` callback
-
-Instead of listening to individual actions, you can listen on an entire Action Map for state changes on any of the Actions in the Action Map.
-
-```CSharp
-var actionMap = new InputActionMap();
-actionMap.AddAction("action1", "/buttonSouth");
-actionMap.AddAction("action2", "/buttonNorth");
-
-actionMap.actionTriggered +=
- context => { ... };
-```
-
-The argument received is the same `InputAction.CallbackContext` structure that you receive through the [`started`, `performed`, and `canceled` callbacks](#action-callbacks).
-
->__Note__: The Input System calls `InputActionMap.actionTriggered` for all three of the individual callbacks on Actions. That is, you get `started`, `performed`, and `canceled` all on a single callback.
-
-##### `InputSystem.onActionChange` callback
-
-Similar to `InputSystem.onDeviceChange`, your app can listen for any action-related change globally.
-
-```CSharp
-InputSystem.onActionChange +=
- (obj, change) =>
- {
- // obj can be either an InputAction or an InputActionMap
- // depending on the specific change.
- switch (change)
- {
- case InputActionChange.ActionStarted:
- case InputActionChange.ActionPerformed:
- case InputActionChange.ActionCanceled:
- Debug.Log($"{((InputAction)obj).name} {change}");
- break;
- }
- }
-```
-
-
-#### `InputActionTrace`
-
-You can trace Actions to generate a log of all activity that happened on a particular set of Actions. To do so, use [`InputActionTrace`](../api/UnityEngine.InputSystem.Utilities.InputActionTrace.html). This behaves in a similar way to [`InputEventTrace`](../api/UnityEngine.InputSystem.LowLevel.InputEventTrace.html) for events.
-
->__Note__: `InputActionTrace` allocates unmanaged memory and needs to be disposed of so that it doesn't create memory leaks.
-
-```CSharp
-var trace = new InputActionTrace();
-
-// Subscribe trace to single Action.
-// (Use UnsubscribeFrom to unsubscribe)
-trace.SubscribeTo(myAction);
-
-// Subscribe trace to entire Action Map.
-// (Use UnsubscribeFrom to unsubscribe)
-trace.SubscribeTo(myActionMap);
-
-// Subscribe trace to all Actions in the system.
-trace.SubscribeToAll();
-
-// Record a single triggering of an Action.
-myAction.performed +=
- ctx =>
- {
- if (ctx.ReadValue() > 0.5f)
- trace.RecordAction(ctx);
- };
-
-// Output trace to console.
-Debug.Log(string.Join(",\n", trace));
-
-// Walk through all recorded Actions and then clear trace.
-foreach (var record in trace)
-{
- Debug.Log($"{record.action} was {record.phase} by control {record.control}");
-
- // To read out the value, you either have to know the value type or read the
- // value out as a generic byte buffer. Here, we assume that the value type is
- // float.
-
- Debug.Log("Value: " + record.ReadValue());
-
- // If it's okay to accept a GC hit, you can also read out values as objects.
- // In this case, you don't have to know the value type.
-
- Debug.Log("Value: " + record.ReadValueAsObject());
-}
-trace.Clear();
-
-// Unsubscribe trace from everything.
-trace.UnsubscribeFromAll();
-
-// Release memory held by trace.
-trace.Dispose();
-```
-
-Once recorded, a trace can be safely read from multiple threads as long as it is not concurrently being written to and as long as the Action setup (that is, the configuration data accessed by the trace) is not concurrently being changed on the main thread.
-
-### Action types
-
-Each Action can be one of three different [Action types](../api/UnityEngine.InputSystem.InputActionType.html). You can select the Action type in the Input Action editor window, or by specifying the `type` parameter when calling the [`InputAction()`](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction__ctor_System_String_UnityEngine_InputSystem_InputActionType_System_String_System_String_System_String_System_String_) constructor. The Action type influences how the Input System processes state changes for the Action. The default Action type is `Value`.
-
-#### Value
-
-This is the default Action type. Use this for any inputs which should track continuous changes to the state of a Control.
-
- [`Value`](../api/UnityEngine.InputSystem.InputActionType.html#UnityEngine_InputSystem_InputActionType_Value) type actions continuously monitor all the Controls which are bound to the Action, and then choose the one which is the most actuated to be the Control driving the Action, and report the values from that Control in callbacks, triggered whenever the value changes. If a different bound Control actuated more, then that Control becomes the Control driving the Action, and the Action starts reporting values from that Control. This process is called [conflict resolution](ActionBindings.md#conflicting-inputs). This is useful if you want to allow different Controls to control an Action in the game, but only take input from one Control at the same time.
-
-When the Action initially enables, it performs an [initial state check](ActionBindings.md#initial-state-check) of all bound Controls. If any of them is actuated, the Action then triggers a callback with the current value.
-
-#### Button
-
-This is very similar to [`Value`](../api/UnityEngine.InputSystem.InputActionType.html#UnityEngine_InputSystem_InputActionType_Value), but [`Button`](../api/UnityEngine.InputSystem.InputActionType.html#UnityEngine_InputSystem_InputActionType_Button) type Actions can only be bound to [`ButtonControl`](../api/UnityEngine.InputSystem.Controls.ButtonControl.html) Controls, and don't perform an initial state check like [`Value`](../api/UnityEngine.InputSystem.InputActionType.html#UnityEngine_InputSystem_InputActionType_Value) Actions do (see the Value section above). Use this for inputs that trigger an Action once every time they are pressed. The initial state check is usually not useful in such cases, because it can trigger actions if the button is still held down from a previous press when the Action was enabled.
-
-#### Pass-Through
-
- [`Pass-Through`](../api/UnityEngine.InputSystem.InputActionType.html#UnityEngine_InputSystem_InputActionType_PassThrough) Actions bypass the [conflict resolution](ActionBindings.md#conflicting-inputs) process described above for `Value` Actions and don't use the concept of a specific Control driving the Action. Instead, any change to any bound Control triggers a callback with that Control's value. This is useful if you want to process all input from a set of Controls.
-
-### Debugging Actions
-
-To see currently enabled Actions and their bound Controls, use the [Input Debugger](Debugging.md#debugging-actions).
-
-You can also use the [`InputActionVisualizer`](Debugging.md#inputactionvisualizer) component from the Visualizers sample to get an on-screen visualization of an Action's value and Interaction state in real-time.
-
-### Using Actions with multiple players
-
-You can use the same Action definitions for multiple local players (for example, in a local co-op game). For more information, see documentation on the [Player Input Manager](PlayerInputManager.md) component.
diff --git a/Packages/com.unity.inputsystem/Documentation~/Settings.md b/Packages/com.unity.inputsystem/Documentation~/Settings.md
index e7a129913c..119c63fdfa 100644
--- a/Packages/com.unity.inputsystem/Documentation~/Settings.md
+++ b/Packages/com.unity.inputsystem/Documentation~/Settings.md
@@ -10,7 +10,10 @@ uid: input-system-settings
- [Compensate Orientation](#compensate-orientation)
- [Default value properties](#default-value-properties)
- [Supported Devices](#supported-devices)
+ - [Override in Editor](#override-in-editor)
- [Platform-specific settings](#platform-specific-settings)
+ - [iOS/tvOS](#iostvos)
+ - [Editor](#editor)
To configure the Input System individually for each project, go to __Edit__ > __Project Settings…__ > __Input System Package__ from Unity's main menu.
@@ -58,7 +61,7 @@ In the Editor, "Run In Background" is considered to always be enabled as the pla
|[`Reset And Disable All Devices`](../api/UnityEngine.InputSystem.InputSettings.BackgroundBehavior.html#UnityEngine_InputSystem_InputSettings_BackgroundBehavior_ResetAndDisableAllDevices)|When focus is lost, perform a [soft reset](../api/UnityEngine.InputSystem.InputSystem.html#UnityEngine_InputSystem_InputSystem_ResetDevice_UnityEngine_InputSystem_InputDevice_System_Boolean_) on all Devices and also subsequently [disable](../api/UnityEngine.InputSystem.InputSystem.html#UnityEngine_InputSystem_InputSystem_DisableDevice_UnityEngine_InputSystem_InputDevice_System_Boolean_) them.`](../api/UnityEngine.InputSystem.Controls.TouchControl.html)|An array of touch Controls that represents all the touches on the Device.|
-A touch screen Device consists of multiple [`TouchControls`](../api/UnityEngine.InputSystem.Controls.TouchControl.html). Each of these represents a potential finger touching the Device. The [`primaryTouch`](../api/UnityEngine.InputSystem.Touchscreen.html#UnityEngine_InputSystem_Touchscreen_primaryTouch) Control represents the touch which is currently driving the [`Pointer`](Pointers.md) representation, and which should be used to interact with the UI. This is usually the first finger that touches the screen.
+A touch screen Device consists of multiple [`TouchControls`](../api/UnityEngine.InputSystem.Controls.TouchControl.html). Each of these represents a potential finger touching the Device. The [`primaryTouch`](../api/UnityEngine.InputSystem.Touchscreen.html#UnityEngine_InputSystem_Touchscreen_primaryTouch) Control represents the touch which is currently driving the [`Pointer`](pointers.md) representation, and which should be used to interact with the UI. This is usually the first finger that touches the screen.
[`primaryTouch`](../api/UnityEngine.InputSystem.Touchscreen.html#UnityEngine_InputSystem_Touchscreen_primaryTouch) is always identical to one of the entries in the [`touches`](../api/UnityEngine.InputSystem.Touchscreen.html#UnityEngine_InputSystem_Touchscreen_touches) array. The [`touches`](../api/UnityEngine.InputSystem.Touchscreen.html#UnityEngine_InputSystem_Touchscreen_touches) array contains all the touches that the system can track. This array has a fixed size, regardless of how many touches are currently active. If you need an API that only represents active touches, see the higher-level [`EnhancedTouch.Touch` class](#enhancedtouchtouch-class).
@@ -58,7 +57,7 @@ Each [`TouchControl`](../api/UnityEngine.InputSystem.Controls.TouchControl.html)
### Using touch with Actions
-You can use touch input with Actions, like any other [`Pointer`](Pointers.md) Device. To do this, [bind](ActionBindings.md) to the [pointer Controls](Pointers.md#controls), like `/press` or `/delta`. This gets input from the primary touch, and any other non-touch pointer Devices.
+You can use touch input with Actions, like any other [`Pointer`](pointers.md) Device. To do this, [bind](ActionBindings.md) to the [pointer Controls](pointers.md#controls), like `/press` or `/delta`. This gets input from the primary touch, and any other non-touch pointer Devices.
However, if you want to get input from multiple touches in your Action, you can bind to individual touches by using Bindings like `/touch3/press`. Alternatively, use a wildcard Binding to bind one Action to all touches: `/touch*/press`.
@@ -92,7 +91,7 @@ See [`EnhancedTouch.Touch` API documentation](../api/UnityEngine.InputSystem.Enh
## Touch Simulation
-Touch input can be simulated from input on other kinds of [Pointer](./Pointers.md) devices such as [Mouse](./Mouse.md) and [Pen](./Pen.md) devices. To enable this, you can either add the [`TouchSimulation`](../api/UnityEngine.InputSystem.EnhancedTouch.TouchSimulation.html) `MonoBehaviour` to a `GameObject` in your scene or simply call [`TouchSimulation.Enable`](../api/UnityEngine.InputSystem.EnhancedTouch.TouchSimulation.html#UnityEngine_InputSystem_EnhancedTouch_TouchSimulation_Enable) somewhere in your startup code.
+Touch input can be simulated from input on other kinds of [Pointer](./pointers.md) devices such as [Mouse](./Mouse.md) and [Pen](./Pen.md) devices. To enable this, you can either add the [`TouchSimulation`](../api/UnityEngine.InputSystem.EnhancedTouch.TouchSimulation.html) `MonoBehaviour` to a `GameObject` in your scene or simply call [`TouchSimulation.Enable`](../api/UnityEngine.InputSystem.EnhancedTouch.TouchSimulation.html#UnityEngine_InputSystem_EnhancedTouch_TouchSimulation_Enable) somewhere in your startup code.
```CSharp
void OnEnable()
@@ -101,7 +100,7 @@ Touch input can be simulated from input on other kinds of [Pointer](./Pointers.m
}
```
-In the editor, you can also enable touch simulation by toggling "Simulate Touch Input From Mouse or Pen" on in the "Options" dropdown of the [Input Debugger](./Debugging.md).
+In the editor, you can also enable touch simulation by toggling "Simulate Touch Input From Mouse or Pen" on in the "Options" dropdown of the [Input Debugger](./debugging.md).
[`TouchSimulation`](../api/UnityEngine.InputSystem.EnhancedTouch.TouchSimulation.html) will add a [`Touchscreen`](../api/UnityEngine.InputSystem.Touchscreen.html) device and automatically mirror input on any [`Pointer`](../api/UnityEngine.InputSystem.Pointer.html) device to the virtual touchscreen device.
diff --git a/Packages/com.unity.inputsystem/Documentation~/UISupport.md b/Packages/com.unity.inputsystem/Documentation~/UISupport.md
index 8e196f820d..7a45d26615 100644
--- a/Packages/com.unity.inputsystem/Documentation~/UISupport.md
+++ b/Packages/com.unity.inputsystem/Documentation~/UISupport.md
@@ -30,7 +30,7 @@ The three main UI solutions are **UI Toolkit**, **Unity UI**, and **IMGUI**. The
**For [**UI Toolkit**](https://docs.unity3d.com/Manual/UIElements.html), also known as "UI Elements" (an XML/CSS style UI solution):**
-- From Unity 2023.2 and onwards, the UI actions defined in the default [project-wide actions](./ProjectWideActions.md) directly map to UI Toolkit input. You do not need to use the UI Input Module component.
+- From Unity 2023.2 and onwards, the UI actions defined in the default [project-wide actions](./about-project-wide-actions.md) directly map to UI Toolkit input. You do not need to use the UI Input Module component.
- In versions of Unity prior to 2023.2, you must use the UI Input Module component to define which actions are passed through from the Input System to the UI.
**For [**Unity UI**](https://docs.unity3d.com/Packages/com.unity.ugui@latest), also known as "uGUI" (a GameObject and Component style UI solution):**
@@ -53,7 +53,7 @@ IMGUI|No|n/a
## Setting up UI input
-The default [project-wide actions](./ProjectWideActions.md) comes with a "**UI**" Action Map, that contains all the actions required for UI interaction (shown in the image below). You can configure the bindings for these actions in the [Actions Editor](./ActionsEditor.md). Go to **Project Settings > Input System Package**, then select "**UI**" in the Action Maps column.
+The default [project-wide actions](./about-project-wide-actions.md) comes with a "**UI**" Action Map, that contains all the actions required for UI interaction (shown in the image below). You can configure the bindings for these actions in the [Actions Editor](./ActionsEditor.md). Go to **Project Settings > Input System Package**, then select "**UI**" in the Action Maps column.
@@ -221,7 +221,7 @@ The Input System can also handle multiple separate UI instances on the screen co
-Unlike the Event System component, you can have multiple Multiplayer Event Systems active in the Scene at the same time. That way, you can have multiple players, each with their own UI Input Module and Multiplayer Event System components, and each player can have their own set of Actions driving their own UI instance. If you are using the [Player Input](PlayerInput.md) component, you can also set it to automatically configure the player's UI Input Module to use the player's Actions. See the documentation on [Player Input](PlayerInput.md#ui-input) to learn how.
+Unlike the Event System component, you can have multiple Multiplayer Event Systems active in the Scene at the same time. That way, you can have multiple players, each with their own UI Input Module and Multiplayer Event System components, and each player can have their own set of Actions driving their own UI instance. If you are using the [Player Input](player-input-component.md) component, you can also set it to automatically configure the player's UI Input Module to use the player's Actions. See the documentation on [Player Input](player-input-component.md#ui-input) to learn how.
The properties of the Multiplayer Event System component are identical to those from the Event System component. Additionally, the Multplayer Event System component adds a [Player Root](../api/UnityEngine.InputSystem.UI.MultiplayerEventSystem.html#UnityEngine_InputSystem_UI_MultiplayerEventSystem_playerRoot) property, which you can set to a GameObject that contains all the UI [selectables](https://docs.unity3d.com/Manual/script-Selectable.html) this event system should handle in its hierarchy. Mouse input that this event system processes then ignores any UI selectables which are not on any GameObject in the Hierarchy under [Player Root](../api/UnityEngine.InputSystem.UI.MultiplayerEventSystem.html#UnityEngine_InputSystem_UI_MultiplayerEventSystem_playerRoot).
@@ -282,7 +282,7 @@ When ambiguities arise, they do so differently for [pointer-type](#pointer-type-
Input from pointers (mice, touchscreens, pens) can be ambiguous depending on whether or not the pointer is over a UI element when initiating an interaction. For example, if there is a button on screen, then clicking on the button may lead to a different outcome than clicking outside of the button and within the game scene.
-If all pointer input is handled via UI events, no ambiguities arise as the UI will implicitly route input to the respective receiver. If, however, input within the UI is handled via UI events and input in the game is handled via [Actions](./Actions.md), pointer input will by default lead to *both* being triggered.
+If all pointer input is handled via UI events, no ambiguities arise as the UI will implicitly route input to the respective receiver. If, however, input within the UI is handled via UI events and input in the game is handled via [Actions](./actions.md), pointer input will by default lead to *both* being triggered.
The easiest way to resolve such ambiguities is to respond to in-game actions by [polling](RespondingToActions.md#polling-actions) from inside [`MonoBehaviour.Update`](https://docs.unity3d.com/ScriptReference/MonoBehaviour.Update.html) methods and using [`EventSystem.IsPointerOverGameObject`](https://docs.unity3d.com/Packages/com.unity.ugui@1.0/api/UnityEngine.EventSystems.EventSystem.html?q=ispointerovergameobject#UnityEngine_EventSystems_EventSystem_IsPointerOverGameObject) to find out whether the pointer is over UI or not. Another way is to use [`EventSystem.RaycastAll`](https://docs.unity3d.com/Packages/com.unity.ugui@1.0/api/UnityEngine.EventSystems.EventSystem.html?q=ispointerovergameobj#UnityEngine_EventSystems_EventSystem_RaycastAll_UnityEngine_EventSystems_PointerEventData_System_Collections_Generic_List_UnityEngine_EventSystems_RaycastResult__) to determine if the pointer is currently over UI.
diff --git a/Packages/com.unity.inputsystem/Documentation~/UserManagement.md b/Packages/com.unity.inputsystem/Documentation~/UserManagement.md
index 47fa81c315..be3b664ca1 100644
--- a/Packages/com.unity.inputsystem/Documentation~/UserManagement.md
+++ b/Packages/com.unity.inputsystem/Documentation~/UserManagement.md
@@ -21,7 +21,7 @@ To query the Devices paired to a specific [`InputUser`](../api/UnityEngine.Input
### Initial engagement
-After you create a user, you can use [`InputUser.AssociateActionsWithUser`](../api/UnityEngine.InputSystem.Users.InputUser.html#UnityEngine_InputSystem_Users_InputUser_AssociateActionsWithUser_UnityEngine_InputSystem_IInputActionCollection_) to associate [Input Actions](Actions.md) to it, and use [`InputUser.ActivateControlScheme`](../api/UnityEngine.InputSystem.Users.InputUser.html#UnityEngine_InputSystem_Users_InputUser_ActivateControlScheme_System_String_) to associate and activate a [Control Scheme](ActionBindings.md#control-schemes). You can use [`InputControlScheme.FindControlSchemeForDevice`](../api/UnityEngine.InputSystem.InputControlScheme.html#UnityEngine_InputSystem_InputControlScheme_FindControlSchemeForDevice__1_UnityEngine_InputSystem_InputDevice___0_) to pick a control scheme that matches the selected Actions and Device:
+After you create a user, you can use [`InputUser.AssociateActionsWithUser`](../api/UnityEngine.InputSystem.Users.InputUser.html#UnityEngine_InputSystem_Users_InputUser_AssociateActionsWithUser_UnityEngine_InputSystem_IInputActionCollection_) to associate [Input Actions](actions.md) to it, and use [`InputUser.ActivateControlScheme`](../api/UnityEngine.InputSystem.Users.InputUser.html#UnityEngine_InputSystem_Users_InputUser_ActivateControlScheme_System_String_) to associate and activate a [Control Scheme](ActionBindings.md#control-schemes). You can use [`InputControlScheme.FindControlSchemeForDevice`](../api/UnityEngine.InputSystem.InputControlScheme.html#UnityEngine_InputSystem_InputControlScheme_FindControlSchemeForDevice__1_UnityEngine_InputSystem_InputDevice___0_) to pick a control scheme that matches the selected Actions and Device:
```
var scheme = InputControlScheme.FindControlSchemeForDevice(user.pairedDevices[0], user.actions.controlsSchemes);
diff --git a/Packages/com.unity.inputsystem/Documentation~/Workflows.md b/Packages/com.unity.inputsystem/Documentation~/Workflows.md
index 2e28018c34..d5ed2d0f59 100644
--- a/Packages/com.unity.inputsystem/Documentation~/Workflows.md
+++ b/Packages/com.unity.inputsystem/Documentation~/Workflows.md
@@ -13,6 +13,7 @@ You can choose to configure Actions and Bindings in the Editor UI, or you can se
The descriptions below describe these main workflows and link to more detailed description of them.
+
| | |
|---|---|
|[**Using Actions**](Workflow-Actions.md)/leftStick"`|
+|[`overridePath`](../api/UnityEngine.InputSystem.InputBinding.html#UnityEngine_InputSystem_InputBinding_overridePath)|[Control path](Controls.md#control-paths) that overrides `path`. Unlike `path`, `overridePath` is not persistent, so you can use it to non-destructively override the path on a Binding. If it is set to something other than null, it takes effect and overrides `path`. To get the path which is currently in effect (that is, either `path` or `overridePath`), you can query the [`effectivePath`](../api/UnityEngine.InputSystem.InputBinding.html#UnityEngine_InputSystem_InputBinding_effectivePath) property.|
+|[`action`](../api/UnityEngine.InputSystem.InputBinding.html#UnityEngine_InputSystem_InputBinding_action)|The name or ID of the Action that the Binding should trigger. Note that this can be null or empty (for instance, for [composites](#composite-bindings)). Not case-sensitive./leftStick`, you get deadzones applied twice: once from the deadzone Processor sitting on the `leftStick` Control, and once from the Binding./leftButton");
+
+// Add a WASD composite binding to the "move" action.
+playerInput.actions["move"]
+ .AddCompositeBinding("2DVector")
+ .With("Up", "/w")
+ .With("Left", "/a")
+ .With("Down", "/s")
+ .With("Right", "/d");
+```
+
+### Setting parameters
+
+A Binding may, either through itself or through its associated Action, lead to [processor](Processors.md), [interaction](Interactions.md), and/or [composite](#composite-bindings) objects being created. These objects can have parameters you can configure through in the [Binding properties view](ActionsEditor.md#bindings) of the Action editor or through the API. This configuration will give parameters their default value.
+
+```CSharp
+// Create an action with a "Hold" interaction on it.
+// Set the "duration" parameter to 4 seconds.
+var action = new InputAction(interactions: "hold(duration=4)");
+```
+
+You can query the current value of any such parameter using the [`GetParameterValue`](../api/UnityEngine.InputSystem.InputActionRebindingExtensions.html#UnityEngine_InputSystem_InputActionRebindingExtensions_GetParameterValue_UnityEngine_InputSystem_InputAction_System_String_UnityEngine_InputSystem_InputBinding_) API.
+
+```CSharp
+// This returns a PrimitiveValue?. It will be null if the
+// parameter is not found. Otherwise, it is a PrimitiveValue
+// which can be converted to a number or boolean.
+var p = action.GetParameterValue("duration");
+Debug.Log("'duration' is set to: " + p.Value);
+```
+
+The above looks for the parameter on any object found on any of the bindings on the action. You can restrict either or both to a more narrow set.
+
+```CSharp
+// Retrieve the value of the "duration" parameter specifically of a
+// "Hold" interaction and only look on bindings in the "Gamepad" group.
+action.GetParameterValue("hold:duration", InputBinding.MaskByGroup("Gamepad"));
+```
+
+Alternatively, you can use an expression parameter to encapsulate both the type and the name of the parameter you want to get the value of. This has the advantage of not needing a string parameter but rather references both the type and the name of the parameter in a typesafe way.
+
+```CSharp
+// Retrieve the value of the "duration" parameter of TapInteraction.
+// This version returns a float? instead of a PrimitiveValue? as it
+// sees the type of "duration" at compile-time.
+action.GetParameterValue((TapInteraction x) => x.duration);
+```
+
+To alter the current value of a parameter, you can use what is referred to as a "parameter override". You can apply these at the level of an individual [`InputAction`](../api/UnityEngine.InputSystem.InputAction.html), or at the level of an entire [`InputActionMap`](../api/UnityEngine.InputSystem.InputActionMap.html), or even at the level of an entire [`InputActionAsset`](../api/UnityEngine.InputSystem.InputActionAsset.html). Such overrides are stored internally and applied automatically even on bindings added later.
+
+To add an override, use the [`ApplyParameterOverride`](../api/UnityEngine.InputSystem.InputActionRebindingExtensions.html#UnityEngine_InputSystem_InputActionRebindingExtensions_ApplyParameterOverride_UnityEngine_InputSystem_InputAction_System_String_UnityEngine_InputSystem_Utilities_PrimitiveValue_UnityEngine_InputSystem_InputBinding_) API or any of its overloads.
+
+```CSharp
+// Set the "duration" parameter on all bindings of the action to 4.
+action.ApplyParameterOverride("duration", 4f);
+
+// Set the "duration" parameter specifically for "tap" interactions only.
+action.ApplyParameterOverride("tap:duration", 0.5f);
+
+// Set the "duration" parameter on tap interactions but only for bindings
+// in the "Gamepad" group.
+action.ApplyParameterOverride("tap:duration", 0.5f, InputBinding.MaskByGroup("Gamepad");
+
+// Set tap duration for all bindings in an action map.
+map.ApplyParameterOverride("tap:duration", 0.5f);
+
+// Set tap duration for all bindings in an entire asset.
+asset.ApplyParameterOverride("tap:duration", 0.5f);
+
+// Like for GetParameterValue, overloads are available that take
+// an expression instead.
+action.ApplyParameterOverride((TapInteraction x) => x.duration, 0.4f);
+map.ApplyParameterOverride((TapInteraction x) => x.duration, 0.4f);
+asset.ApplyParameterOverride((TapInteraction x) => x.duration, 0.4f);
+```
+
+The new value will be applied immediately and affect all composites, processors, and interactions already in use and targeted by the override.
+
+Note that if multiple parameter overrides are applied – especially when applying some directly to actions and some to maps or assets –, there may be conflicts between which override to apply. In this case, an attempt is made to chose the "most specific" override to apply.
+
+```CSharp
+// Let's say you have an InputAction `action` that is part of an InputActionAsset asset.
+var map = action.actionMap;
+var asset = map.asset;
+
+// And you apply a "tap:duration" override to the action.
+action.ApplyParameterOverride("tap:duration", 0.6f);
+
+// But also apply a "tap:duration" override to the action specifically
+// for bindings in the "Gamepad" group.
+action.ApplyParameterOverride("tap:duration", 1f, InputBinding.MaskByGroup("Gamepad"));
+
+// And finally also apply a "tap:duration" override to the entire asset.
+asset.ApplyParameterOverride("tap:duration", 0.3f);
+
+// Now, bindings on `action` in the "Gamepad" group will use a value of 1 for tap durations,
+// other bindings on `action` will use 0.6, and every other binding in the asset will use 0.3.
+```
+
+You can use parameter overrides, for example, to scale mouse delta values on a "Look" action.
+
+```CSharp
+// Set up an example "Look" action.
+var look = new InputAction("look", type: InputActionType.Value);
+look.AddBinding("/delta", groups: "KeyboardMouse", processors: "scaleVector2");
+look.AddBinding("/rightStick", groups: "Gamepad", processors: "scaleVector2");
+
+// Now you can adjust stick sensitivity separately from mouse sensitivity.
+look.ApplyParameterOverride("scaleVector2:x", 0.5f, InputBinding.MaskByGroup("KeyboardMouse"));
+look.ApplyParameterOverride("scaleVector2:y", 0.5f, InputBinding.MaskByGroup("KeyboardMouse"));
+
+look.ApplyParameterOverride("scaleVector2:x", 2f, InputBinding.MaskByGroup("Gamepad"));
+look.ApplyParameterOverride("scaleVector2:y", 2f, InputBinding.MaskByGroup("Gamepad"));
+
+// Alternative to using groups, you can also apply overrides directly to specific binding paths.
+look.ApplyParameterOverride("scaleVector2:x", 0.5f, new InputBinding("/delta"));
+look.ApplyParameterOverride("scaleVector2:y", 0.5f, new InputBinding("/delta"));
+```
+
+>NOTE: Parameter overrides are *not* persisted along with an asset.
+
+
+
+
+
diff --git a/Packages/com.unity.inputsystem/Documentation~/action-maps-panel.md b/Packages/com.unity.inputsystem/Documentation~/action-maps-panel.md
new file mode 100644
index 0000000000..1c69b055c2
--- /dev/null
+++ b/Packages/com.unity.inputsystem/Documentation~/action-maps-panel.md
@@ -0,0 +1,2 @@
+# The action maps panel
+
diff --git a/Packages/com.unity.inputsystem/Documentation~/action-properties-panel.md b/Packages/com.unity.inputsystem/Documentation~/action-properties-panel.md
new file mode 100644
index 0000000000..6049c24f1d
--- /dev/null
+++ b/Packages/com.unity.inputsystem/Documentation~/action-properties-panel.md
@@ -0,0 +1 @@
+# Action properties panel
diff --git a/Packages/com.unity.inputsystem/Documentation~/ActionsEditor.md b/Packages/com.unity.inputsystem/Documentation~/actions-editor.md
similarity index 91%
rename from Packages/com.unity.inputsystem/Documentation~/ActionsEditor.md
rename to Packages/com.unity.inputsystem/Documentation~/actions-editor.md
index 39ac1fe4b6..b7675ef640 100644
--- a/Packages/com.unity.inputsystem/Documentation~/ActionsEditor.md
+++ b/Packages/com.unity.inputsystem/Documentation~/actions-editor.md
@@ -3,15 +3,15 @@ uid: input-system-configuring-input
---
# Configuring Input with the Actions Editor
-The **Input Actions Editor** allows you to edit [Action Assets](ActionAssets.md), which contain a saved configuration of [Input Actions](Actions.md) and their associated [Bindings](ActionBindings.md).
+The **Input Actions Editor** allows you to edit [Action Assets](ActionAssets.md), which contain a saved configuration of [Input Actions](actions.md) and their associated [Bindings](ActionBindings.md).
It allows you to group collections of Actions into [Action Maps](ActionsEditor.html#configure-action-maps), which represent different input scenarios in your project (such as UI navigation, gameplay, etc.)
-It also alows you to define [Control Schemes](ActionBindings.md#control-schemes) which are a way to enable or disable a set of devices, or respond to which type of device is being used. This is often useful if you want to customise your UI based on whether your users are using mouse, keyboard, or gamepad as their chosen input.
+It also allows you to define [Control Schemes](ActionBindings.md#control-schemes) which are a way to enable or disable a set of devices, or respond to which type of device is being used. This is often useful if you want to customise your UI based on whether your users are using mouse, keyboard, or gamepad as their chosen input.
### Action Assets and Project-Wide Actions
-The typical workflow for most projects is to have a single Action Asset, which is assigned as the **project-wide actions**. If you have not yet created and assigned an Actions Asset as the project-wide actions, the recommended workflow is to do this first. Read more about [project-wide actions](ProjectWideActions.md).
+The typical workflow for most projects is to have a single Action Asset, which is assigned as the **project-wide actions**. If you have not yet created and assigned an Actions Asset as the project-wide actions, the recommended workflow is to do this first. Read more about [project-wide actions](about-project-wide-actions.md).
### Opening the Actions Editor
@@ -32,12 +32,6 @@ The Input Actions editor is divided into three panels (marked A, B & C above).
|**(B) Actions**|Displays all the actions defined in the currently selected Action Map, and the bindings associated with each Action.|
|**(C) Properties**|Displays the properties of the currently selected Action or Binding from the Actions panel. The title of this panel changes depending on whether you have an Action or a Binding selected in the Actions panel.|
-### Configure Action Maps
-
-* To add a new Action Map, select the Add (+) icon in the header of the Action Map panel.
-* To rename an existing Action Map, either long-click the name, or right-click the Action Map and select __Rename__ from the context menu. Note that Action Map names can't contain slashes (`/`).
-* To delete an existing Action Map, right-click it and select __Delete__ from the context menu.
-* To duplicate an existing Action Map, right-click it and select __Duplicate__ from the context menu.
### Configure Actions
@@ -45,7 +39,11 @@ The Input Actions editor is divided into three panels (marked A, B & C above).
* To rename an existing Action, either long-click the name, or right-click the Action Map and select __Rename__ from the context menu.
* To delete an existing Action, either right-click it and select __Delete__ from the context menu.
* To duplicate an existing Action, either right-click it and select __Duplicate__ from the context menu.
-*
+
+
+> **Note:**
+> Although you can reorder actions in this window, the ordering is for visual convenience only, and does not affect the order in which the actions are triggered in your code. If multiple actions are performed in the same frame, the order in which they are reported by the input system is undefined. To avoid problems, you should not write code that assumes they will be reported in a particular order.
+
## Action type and Control type
diff --git a/Packages/com.unity.inputsystem/Documentation~/actions-panel.md b/Packages/com.unity.inputsystem/Documentation~/actions-panel.md
new file mode 100644
index 0000000000..570673d3da
--- /dev/null
+++ b/Packages/com.unity.inputsystem/Documentation~/actions-panel.md
@@ -0,0 +1 @@
+# Actions panel
diff --git a/Packages/com.unity.inputsystem/Documentation~/add-custom-device-command.md b/Packages/com.unity.inputsystem/Documentation~/add-custom-device-command.md
new file mode 100644
index 0000000000..e12997b02d
--- /dev/null
+++ b/Packages/com.unity.inputsystem/Documentation~/add-custom-device-command.md
@@ -0,0 +1 @@
+# Add a custom device command
diff --git a/Packages/com.unity.inputsystem/Documentation~/add-duplicate-delete-binding.md b/Packages/com.unity.inputsystem/Documentation~/add-duplicate-delete-binding.md
new file mode 100644
index 0000000000..be1ed9b084
--- /dev/null
+++ b/Packages/com.unity.inputsystem/Documentation~/add-duplicate-delete-binding.md
@@ -0,0 +1 @@
+# Add, duplicate or delete a binding
diff --git a/Packages/com.unity.inputsystem/Documentation~/add-layout-from-cs.md b/Packages/com.unity.inputsystem/Documentation~/add-layout-from-cs.md
new file mode 100644
index 0000000000..bb3efae9b6
--- /dev/null
+++ b/Packages/com.unity.inputsystem/Documentation~/add-layout-from-cs.md
@@ -0,0 +1 @@
+# Add a layout from C#
diff --git a/Packages/com.unity.inputsystem/Documentation~/add-layout-from-json.md b/Packages/com.unity.inputsystem/Documentation~/add-layout-from-json.md
new file mode 100644
index 0000000000..be3b2a02ba
--- /dev/null
+++ b/Packages/com.unity.inputsystem/Documentation~/add-layout-from-json.md
@@ -0,0 +1 @@
+# Add a layout from JSON
diff --git a/Packages/com.unity.inputsystem/Documentation~/add-layout-using-layout-builder.md b/Packages/com.unity.inputsystem/Documentation~/add-layout-using-layout-builder.md
new file mode 100644
index 0000000000..6f4a10207d
--- /dev/null
+++ b/Packages/com.unity.inputsystem/Documentation~/add-layout-using-layout-builder.md
@@ -0,0 +1 @@
+# Add a layout using Layout Builder
diff --git a/Packages/com.unity.inputsystem/Documentation~/ambienttemperaturesensor.md b/Packages/com.unity.inputsystem/Documentation~/ambienttemperaturesensor.md
new file mode 100644
index 0000000000..c0d515b95c
--- /dev/null
+++ b/Packages/com.unity.inputsystem/Documentation~/ambienttemperaturesensor.md
@@ -0,0 +1 @@
+# AmbientTemperatureSensor
diff --git a/Packages/com.unity.inputsystem/Documentation~/api-overview.md b/Packages/com.unity.inputsystem/Documentation~/api-overview.md
new file mode 100644
index 0000000000..b1521e1721
--- /dev/null
+++ b/Packages/com.unity.inputsystem/Documentation~/api-overview.md
@@ -0,0 +1,15 @@
+
+## API Overview
+
+When scripting with Actions in the Input System, there are number of important API you can use, which are described here:
+
+|API name|Description|
+|-----|-----------|
+|[`InputSystem.actions`](../api/UnityEngine.InputSystem.InputSystem.html)|A reference to the set of actions assigned as the [project-wide Actions](./about-project-wide-actions.md).|
+|[`InputActionMap`](../api/UnityEngine.InputSystem.InputActionMap.html)|A named collection of Actions. The API equivalent to an entry in the "Action Maps" column of the [Input Actions editor](ActionsEditor.md).|
+|[`InputAction`](../api/UnityEngine.InputSystem.InputAction.html)|A named Action that can return the current value of the controls that it is bound to, or can trigger callbacks in response to input. The API equivalent to an entry in the "Actions" column of the [Input Actions editor](ActionsEditor.md).|
+|[`InputBinding`](../api/UnityEngine.InputSystem.InputBinding.html)|The relationship between an Action and the specific device controls for which it receives input. For more information about Bindings and how to use them, see [Action Bindings](ActionBindings.md).|
+
+Each Action has a name ([`InputAction.name`](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_name)), which must be unique within the Action Map that the Action belongs to, if any (see [`InputAction.actionMap`](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_actionMap)). Each Action also has a unique ID ([`InputAction.id`](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_id)), which you can use to reference the Action. The ID remains the same even if you rename the Action.
+
+Each Action Map has a name ([`InputActionMap.name`](../api/UnityEngine.InputSystem.InputActionMap.html#UnityEngine_InputSystem_InputActionMap_name)), which must also be unique with respect to the other Action Maps present, if any. Each Action Map also has a unique ID ([`InputActionMap.id`](../api/UnityEngine.InputSystem.InputActionMap.html#UnityEngine_InputSystem_InputActionMap_id)), which you can use to reference the Action Map. The ID remains the same even if you rename the Action Map.
diff --git a/Packages/com.unity.inputsystem/Documentation~/apply-binding-overrides.md b/Packages/com.unity.inputsystem/Documentation~/apply-binding-overrides.md
new file mode 100644
index 0000000000..fd07739c61
--- /dev/null
+++ b/Packages/com.unity.inputsystem/Documentation~/apply-binding-overrides.md
@@ -0,0 +1,30 @@
+
+### Apply binding overrides
+
+You can override aspects of any Binding at run-time non-destructively. Specific properties of [`InputBinding`](../api/UnityEngine.InputSystem.InputBinding.html) have an `override` variant that, if set, will take precedent over the property that they shadow. All `override` properties are of type `String`.
+
+|Property|Override|Description|
+|--------|--------|-----------|
+|[`path`](../api/UnityEngine.InputSystem.InputBinding.html#UnityEngine_InputSystem_InputBinding_path)|[`overridePath`](../api/UnityEngine.InputSystem.InputBinding.html#UnityEngine_InputSystem_InputBinding_overridePath)|Replaces the [Control path](./Controls.md#control-paths) that determines which Control(s) are referenced in the binding. If [`overridePath`](../api/UnityEngine.InputSystem.InputBinding.html#UnityEngine_InputSystem_InputBinding_overridePath) is set to an empty string, the binding is effectively disabled./leftStick"`|
+|[`processors`](../api/UnityEngine.InputSystem.InputBinding.html#UnityEngine_InputSystem_InputBinding_processors)|[`overrideProcessors`](../api/UnityEngine.InputSystem.InputBinding.html#UnityEngine_InputSystem_InputBinding_overrideProcessors)|Replaces the [processors](./Processors.md) applied to the binding./leftTrigger");
+```
+
+In most cases, it is best to locate specific bindings using APIs such as [`GetBindingIndexForControl`](../api/UnityEngine.InputSystem.InputActionRebindingExtensions.html#UnityEngine_InputSystem_InputActionRebindingExtensions_GetBindingIndexForControl_) and to then apply the override to that specific binding.
+
+```CSharp
+// Find the "Jump" binding for the space key.
+var jumpAction = playerInput.actions["Jump"];
+var bindingIndex = jumpAction.GetBindingIndexForControl(Keyboard.current.spaceKey);
+
+// And change it to the enter key.
+jumpAction.ApplyBindingOverride(bindingIndex, "/enter");
+```
diff --git a/Packages/com.unity.inputsystem/Documentation~/assign-project-wide-actions.md b/Packages/com.unity.inputsystem/Documentation~/assign-project-wide-actions.md
new file mode 100644
index 0000000000..4ec645903a
--- /dev/null
+++ b/Packages/com.unity.inputsystem/Documentation~/assign-project-wide-actions.md
@@ -0,0 +1,17 @@
+# Assign project-wide actions
+
+To assign an existing Actions Asset as project-wide, do one of the following:
+
+1. Go to **Edit** > **Project Settings** > **Input System Package**
+2. Drag the asset from your Project window into the **Project-wide Actions** field.
+
+
+*The Input System Package Project Settings with no project-wide actions assigned*
+
+or:
+
+1. Select the Asset in your Project window
+2. In the Inspector window, select **Assign as the Project-wide Input Actions**.
+
+
+Only one Actions Asset can be assigned as project-wide. If a different asset was previously assigned as project-wide, it becomes unassigned.
\ No newline at end of file
diff --git a/Packages/com.unity.inputsystem/Documentation~/attitudesensor.md b/Packages/com.unity.inputsystem/Documentation~/attitudesensor.md
new file mode 100644
index 0000000000..b244f36cb3
--- /dev/null
+++ b/Packages/com.unity.inputsystem/Documentation~/attitudesensor.md
@@ -0,0 +1 @@
+# AttitudeSensor
diff --git a/Packages/com.unity.inputsystem/Documentation~/auto-generated-layouts.md b/Packages/com.unity.inputsystem/Documentation~/auto-generated-layouts.md
new file mode 100644
index 0000000000..eec9162c06
--- /dev/null
+++ b/Packages/com.unity.inputsystem/Documentation~/auto-generated-layouts.md
@@ -0,0 +1 @@
+# Auto-generated Layouts
diff --git a/Packages/com.unity.inputsystem/Documentation~/background-behavior.md b/Packages/com.unity.inputsystem/Documentation~/background-behavior.md
new file mode 100644
index 0000000000..4a7328a888
--- /dev/null
+++ b/Packages/com.unity.inputsystem/Documentation~/background-behavior.md
@@ -0,0 +1 @@
+# Background behavior
diff --git a/Packages/com.unity.inputsystem/Documentation~/binding-initial-state-checks.md b/Packages/com.unity.inputsystem/Documentation~/binding-initial-state-checks.md
new file mode 100644
index 0000000000..11c6e64966
--- /dev/null
+++ b/Packages/com.unity.inputsystem/Documentation~/binding-initial-state-checks.md
@@ -0,0 +1,13 @@
+# Binding initial state checks
+
+After an Action is [enabled](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_enabled), it will start reacting to input as it comes in. However, at the time the Action is enabled, one or more of the Controls that are [bound](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_controls) to an action may already have a non-default state at that point.
+x
+Using what is referred to as an "initial state check", an Action can be made to respond to such a non-default state as if the state change happened *after* the Action was enabled. The way this works is that in the first input [update](../api/UnityEngine.InputSystem.InputSystem.html#UnityEngine_InputSystem_InputSystem_Update_) after the Action was enabled, all its bound controls are checked in turn. If any of them has a non-default state, the Action responds right away.
+
+This check is implicitly enabled for [Value](RespondingToActions.md#value) actions. If, for example, you have a `Move` Action bound to the left stick on the gamepad and the stick is already pushed in a direction when `Move` is enabled, the character will immediately start walking.
+
+By default, [Button](RespondingToActions.md#button) and [Pass-Through](RespondingToActions.md#pass-through) type Actions, do not perform this check. A button that is pressed when its respective Action is enabled first needs to be released and then pressed again for it to trigger the Action.
+
+However, you can manually enable initial state checks on these types of Actions using the checkbox in the editor:
+
+
diff --git a/Packages/com.unity.inputsystem/Documentation~/binding-overrides.md b/Packages/com.unity.inputsystem/Documentation~/binding-overrides.md
new file mode 100644
index 0000000000..55a9e08440
--- /dev/null
+++ b/Packages/com.unity.inputsystem/Documentation~/binding-overrides.md
@@ -0,0 +1 @@
+# Binding overrides
diff --git a/Packages/com.unity.inputsystem/Documentation~/binding-properties-panel.md b/Packages/com.unity.inputsystem/Documentation~/binding-properties-panel.md
new file mode 100644
index 0000000000..2d5c73154f
--- /dev/null
+++ b/Packages/com.unity.inputsystem/Documentation~/binding-properties-panel.md
@@ -0,0 +1,2 @@
+# Binding properties panel
+
diff --git a/Packages/com.unity.inputsystem/Documentation~/binding-resolution.md b/Packages/com.unity.inputsystem/Documentation~/binding-resolution.md
new file mode 100644
index 0000000000..fe3eb00c2f
--- /dev/null
+++ b/Packages/com.unity.inputsystem/Documentation~/binding-resolution.md
@@ -0,0 +1,43 @@
+
+# Binding resolution
+
+When the Input System accesses the [Controls](Controls.md) bound to an Action for the first time, the Action resolves its Bindings to match them to existing Controls on existing Devices. In this process, the Action calls [`InputSystem.FindControls<>()`](../api/UnityEngine.InputSystem.InputSystem.html#UnityEngine_InputSystem_InputSystem_FindControls__1_System_String_UnityEngine_InputSystem_InputControlList___0___) (filtering for devices assigned to the InputActionMap, if there are any) for the Binding path of each of the Action's bindings. This creates a list of resolved Controls that are now bound to the Action.
+
+Note that a single [Binding path](Controls.md#control-paths) can match multiple Controls:
+
+* A specific Device path such as `/buttonEast` matches the "Circle" button on a [PlayStation controller](Gamepad.md#playstation-controllers). If you have multiple PlayStation controllers connected, it resolves to the "Circle" button on each of these controllers.
+
+* An abstract Device path such as `/buttonEast` matches the right action button on any connected gamepad. If you have a PlayStation controller and an [Xbox controller](Gamepad.md#xbox-controllers) connected, it resolves to the "Circle" button on the PlayStation controller, and to the "B" button on the Xbox controller.
+
+* A Binding path can also contain wildcards, such as `/button*`. This matches any Control on any gamepad with a name starting with "button", which matches all the four action buttons on any connected gamepad. A different example: `*/{Submit}` matches any Control tagged with the "Submit" [usage](Controls.md#control-usages) on any Device.
+
+If there are multiple Bindings on the same Action that all reference the same Control(s), the Control will effectively feed into the Action multiple times. This is to allow, for example, a single Control to produce different input on the same Action by virtue of being bound in a different fashion (composites, processors, interactions, etc). However, regardless of how many times a Control is bound on any given action, it will only be mentioned once in the Action's [array of `controls`](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_controls).
+
+To query the Controls that an Action resolves to, you can use [`InputAction.controls`](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_controls). You can also run this query if the Action is disabled.
+
+To be notified when binding resolution happens, you can listen to [`InputSystem.onActionChange`](../api/UnityEngine.InputSystem.InputSystem.html#UnityEngine_InputSystem_InputSystem_onActionChange) which triggers [`InputActionChange.BoundControlsAboutToChange`](../api/UnityEngine.InputSystem.InputActionChange.html#UnityEngine_InputSystem_InputActionChange_BoundControlsAboutToChange) before modifying Control lists and triggers [`InputActionChange.BoundControlsChanged`](../api/UnityEngine.InputSystem.InputActionChange.html#UnityEngine_InputSystem_InputActionChange_BoundControlsChanged) after having updated them.
+
+## Binding resolution while Actions are enabled
+
+In certain situations, the [Controls](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_controls) bound to an Action have to be updated more than once. For example, if a new [Device](Devices.md) becomes usable with an Action, the Action may now pick up input from additional controls. Also, if Bindings are added, removed, or modified, Control lists will need to be updated.
+
+This updating of Controls usually happens transparently in the background. However, when an Action is [enabled](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_enabled) and especially when it is [in progress](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_IsInProgress_), there may be a noticeable effect on the Action.
+
+Adding or removing a device – either [globally](../api/UnityEngine.InputSystem.InputSystem.html#UnityEngine_InputSystem_InputSystem_devices) or to/from the [device list](../api/UnityEngine.InputSystem.InputActionAsset.html#UnityEngine_InputSystem_InputActionAsset_devices) of an Action – will remain transparent __except__ if an Action is in progress and it is the device of its [active Control](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_activeControl) that is being removed. In this case, the Action will automatically be [cancelled](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_canceled).
+
+Modifying the [binding mask](../api/UnityEngine.InputSystem.InputActionAsset.html#UnityEngine_InputSystem_InputActionAsset_bindingMask) or modifying any of the Bindings (such as through [rebinding](#interactive-rebinding) or by adding or removing bindings) will, however, lead to all enabled Actions being temporarily disabled and then re-enabled and resumed.
+
+## Choosing which Devices to use
+
+>__Note__: [`InputUser`](UserManagement.md) and [`PlayerInput`](player-input-component.md) make use of this facility automatically. They set [`InputActionMap.devices`](../api/UnityEngine.InputSystem.InputActionMap.html#UnityEngine_InputSystem_InputActionMap_devices) automatically based on the Devices that are paired to the user.
+
+By default, Actions resolve their Bindings against all Devices present in the Input System (that is, [`InputSystem.devices`](../api/UnityEngine.InputSystem.InputSystem.html#UnityEngine_InputSystem_InputSystem_devices)). For example, if there are two gamepads present in the system, a Binding to `/buttonSouth` picks up both gamepads and allows the Action to be used from either.
+
+You can override this behavior by restricting [`InputActionAssets`](../api/UnityEngine.InputSystem.InputActionAsset.html) or individual [`InputActionMaps`](../api/UnityEngine.InputSystem.InputActionMap.html) to a specific set of Devices. If you do this, Binding resolution only takes the Controls of the given Devices into account.
+
+```
+ var actionMap = new InputActionMap();
+
+ // Restrict the action map to just the first gamepad.
+ actionMap.devices = new[] { Gamepad.all[0] };
+```
diff --git a/Packages/com.unity.inputsystem/Documentation~/bindings.md b/Packages/com.unity.inputsystem/Documentation~/bindings.md
new file mode 100644
index 0000000000..34594229e8
--- /dev/null
+++ b/Packages/com.unity.inputsystem/Documentation~/bindings.md
@@ -0,0 +1,3 @@
+# Bindings
+
+(landing page)
\ No newline at end of file
diff --git a/Packages/com.unity.inputsystem/Documentation~/changing-bindings.md b/Packages/com.unity.inputsystem/Documentation~/changing-bindings.md
new file mode 100644
index 0000000000..09832ad02e
--- /dev/null
+++ b/Packages/com.unity.inputsystem/Documentation~/changing-bindings.md
@@ -0,0 +1,43 @@
+
+## Changing Bindings
+
+In general, you can change existing bindings via the [`InputActionSetupExtensions.ChangeBinding`](../api/UnityEngine.InputSystem.InputActionSetupExtensions.html#UnityEngine_InputSystem_InputActionSetupExtensions_ChangeBinding_UnityEngine_InputSystem_InputAction_System_Int32_) method. This returns an accessor that can be used to modify the properties of the targeted [`InputBinding`](../api/UnityEngine.InputSystem.InputBinding.html). Note that most of the write operations of the accessor are destructive. For non-destructive changes to bindings, see [Applying Overrides](#applying-overrides).
+
+```CSharp
+// Get write access to the second binding of the 'fire' action.
+var accessor = playerInput.actions['fire'].ChangeBinding(1);
+
+// You can also gain access through the InputActionMap. Each
+// map contains an array of all its bindings (see InputActionMap.bindings).
+// Here we gain access to the third binding in the map.
+accessor = playerInput.actions.FindActionMap("gameplay").ChangeBinding(2);
+```
+
+You can use the resulting accessor to modify properties through methods such as [`WithPath`](../api/UnityEngine.InputSystem.InputActionSetupExtensions.BindingSyntax.html#UnityEngine_InputSystem_InputActionSetupExtensions_BindingSyntax_WithPath_) or [`WithProcessors`](../api/UnityEngine.InputSystem.InputActionSetupExtensions.BindingSyntax.html#UnityEngine_InputSystem_InputActionSetupExtensions_BindingSyntax_WithProcessors_).
+
+```CSharp
+playerInput.actions["fire"].ChangeBinding(1)
+ // Change path to space key.
+ .WithPath("/space");
+```
+
+You can also use the accessor to iterate through bindings using [`PreviousBinding`](../api/UnityEngine.InputSystem.InputActionSetupExtensions.BindingSyntax.html#UnityEngine_InputSystem_InputActionSetupExtensions_BindingSyntax_PreviousBinding_) and [`NextBinding`](../api/UnityEngine.InputSystem.InputActionSetupExtensions.BindingSyntax.html#UnityEngine_InputSystem_InputActionSetupExtensions_BindingSyntax_NextBinding_).
+
+```CSharp
+// Move accessor to previous binding.
+accessor = accessor.PreviousBinding();
+
+// Move accessor to next binding.
+accessor = accessor.NextBinding();
+```
+
+If the given binding is a [composite](../api/UnityEngine.InputSystem.InputBinding.html#UnityEngine_InputSystem_InputBinding_isComposite), you can address it by its name rather than by index.
+
+```CSharp
+// Change the 2DVector composite of the "move" action.
+playerInput.actions["move"].ChangeCompositeBinding("2DVector")
+
+
+//
+playerInput.actions["move"].ChangeBinding("WASD")
+```
diff --git a/Packages/com.unity.inputsystem/Documentation~/compatibility.md b/Packages/com.unity.inputsystem/Documentation~/compatibility.md
new file mode 100644
index 0000000000..6176c80a70
--- /dev/null
+++ b/Packages/com.unity.inputsystem/Documentation~/compatibility.md
@@ -0,0 +1 @@
+# Compatibility
diff --git a/Packages/com.unity.inputsystem/Documentation~/compensate-orientation.md b/Packages/com.unity.inputsystem/Documentation~/compensate-orientation.md
new file mode 100644
index 0000000000..5ec62d91c9
--- /dev/null
+++ b/Packages/com.unity.inputsystem/Documentation~/compensate-orientation.md
@@ -0,0 +1 @@
+# Compensate orientation
diff --git a/Packages/com.unity.inputsystem/Documentation~/composite-bindings.md b/Packages/com.unity.inputsystem/Documentation~/composite-bindings.md
new file mode 100644
index 0000000000..b3fa71f768
--- /dev/null
+++ b/Packages/com.unity.inputsystem/Documentation~/composite-bindings.md
@@ -0,0 +1,319 @@
+# Composite Bindings
+
+Sometimes, you might want to have several Controls act in unison to mimic a different type of Control. The most common example of this is using the W, A, S, and D keys on the keyboard to form a 2D vector Control equivalent to mouse deltas or gamepad sticks. Another example is to use two keys to form a 1D axis equivalent to a mouse scroll axis.
+
+This is difficult to implement with normal Bindings. You can bind a [`ButtonControl`](../api/UnityEngine.InputSystem.Controls.ButtonControl.html) to an action expecting a `Vector2`, but doing so results in an exception at runtime when the Input System tries to read a `Vector2` from a Control that can deliver only a `float`.
+
+Composite Bindings (that is, Bindings that are made up of other Bindings) solve this problem. Composites themselves don't bind directly to Controls; instead, they source values from other Bindings that do, and then synthesize input on the fly from those values.
+
+To see how to create Composites in the editor UI, see documentation on [editing Composite Bindings](ActionsEditor.md#editing-composite-bindings).
+
+To create composites in code, you can use the [`AddCompositeBinding`](../api/UnityEngine.InputSystem.InputActionSetupExtensions.html#UnityEngine_InputSystem_InputActionSetupExtensions_AddCompositeBinding_UnityEngine_InputSystem_InputAction_System_String_System_String_System_String_) syntax.
+
+```CSharp
+myAction.AddCompositeBinding("Axis")
+ .With("Positive", "/rightTrigger")
+ .With("Negative", "/leftTrigger");
+```
+
+Each Composite consists of one Binding that has [`InputBinding.isComposite`](../api/UnityEngine.InputSystem.InputBinding.html#UnityEngine_InputSystem_InputBinding_isComposite) set to true, followed by one or more Bindings that have [`InputBinding.isPartOfComposiste`](../api/UnityEngine.InputSystem.InputBinding.html#UnityEngine_InputSystem_InputBinding_isPartOfComposite) set to true. In other words, several consecutive entries in [`InputActionMap.bindings`](../api/UnityEngine.InputSystem.InputActionMap.html#UnityEngine_InputSystem_InputActionMap_bindings) or [`InputAction.bindings`](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_bindings) together form a Composite.
+
+Note that each composite part can be bound arbitrary many times.
+
+```CSharp
+// Make both shoulders and triggers pull on the axis.
+myAction.AddCompositeBinding("Axis")
+ .With("Positive", "/rightTrigger")
+ .With("Positive", "/rightShoulder")
+ .With("Negative", "/leftTrigger");
+ .With("Negative", "/leftShoulder");
+```
+
+Composites can have parameters, just like [Interactions](Interactions.md) and [Processors](Processors.md).
+
+```CSharp
+myAction.AddCompositeBinding("Axis(whichSideWins=1)");
+```
+
+There are currently five Composite types that come with the system out of the box: [1D-Axis](#1d-axis), [2D-Vector](#2d-vector), [3D-Vector](#3d-vector), [One Modifier](#one-modifier) and [Two Modifiers](#two-modifiers). Additionally, you can [add your own](#writing-custom-composites) types of Composites.
+
+### 1D axis
+
+
+
+
+
+A Composite made of two buttons: one that pulls a 1D axis in its negative direction, and another that pulls it in its positive direction. Implemented in the [`AxisComposite`](../api/UnityEngine.InputSystem.Composites.AxisComposite.html) class. The result is a `float`.
+
+```CSharp
+myAction.AddCompositeBinding("1DAxis") // Or just "Axis"
+ .With("Positive", "/rightTrigger")
+ .With("Negative", "/leftTrigger");
+```
+
+The axis Composite has two part bindings.
+
+|Part|Type|Description|
+|----|----|-----------|
+|[`positive`](../api/UnityEngine.InputSystem.Composites.AxisComposite.html#UnityEngine_InputSystem_Composites_AxisComposite_positive)|`Button`|Controls pulling in the positive direction (towards [`maxValue`](../api/UnityEngine.InputSystem.Composites.AxisComposite.html#UnityEngine_InputSystem_Composites_AxisComposite_maxValue)).|
+|[`negative`](../api/UnityEngine.InputSystem.Composites.AxisComposite.html#UnityEngine_InputSystem_Composites_AxisComposite_negative)|`Button`|Controls pulling in the negative direction, (towards [`minValue`](../api/UnityEngine.InputSystem.Composites.AxisComposite.html#UnityEngine_InputSystem_Composites_AxisComposite_minValue)).|
+
+You can set the following parameters on an axis Composite:
+
+|Parameter|Description|
+|---------|-----------|
+|[`whichSideWins`](../api/UnityEngine.InputSystem.Composites.AxisComposite.html#UnityEngine_InputSystem_Composites_AxisComposite_whichSideWins)|What happens if both [`positive`](../api/UnityEngine.InputSystem.Composites.AxisComposite.html#UnityEngine_InputSystem_Composites_AxisComposite_positive) and [`negative`](../api/UnityEngine.InputSystem.Composites.AxisComposite.html#UnityEngine_InputSystem_Composites_AxisComposite_negative) are actuated. See table below.|
+|[`minValue`](../api/UnityEngine.InputSystem.Composites.AxisComposite.html#UnityEngine_InputSystem_Composites_AxisComposite_minValue)|The value returned if the [`negative`](../api/UnityEngine.InputSystem.Composites.AxisComposite.html#UnityEngine_InputSystem_Composites_AxisComposite_negative) side is actuated. Default is -1.|
+|[`maxValue`](../api/UnityEngine.InputSystem.Composites.AxisComposite.html#UnityEngine_InputSystem_Composites_AxisComposite_maxValue)|The value returned if the [`positive`](../api/UnityEngine.InputSystem.Composites.AxisComposite.html#UnityEngine_InputSystem_Composites_AxisComposite_positive) side is actuated. Default is 1.|
+
+If Controls from both the `positive` and the `negative` side are actuated, then the resulting value of the axis Composite depends on the `whichSideWin` parameter setting.
+
+|[`WhichSideWins`](../api/UnityEngine.InputSystem.Composites.AxisComposite.WhichSideWins.html)|Description|
+|---------------|-----------|
+|(0) `Neither`|Neither side has precedence. The Composite returns the midpoint between `minValue` and `maxValue` as a result. At their default settings, this is 0./w")
+ .With("Down", "/s")
+ .With("Left", "/a")
+ .With("Right", "/d");
+
+// To set mode (2=analog, 1=digital, 0=digitalNormalized):
+myAction.AddCompositeBinding("2DVector(mode=2)")
+ .With("Up", "/leftStick/up")
+ .With("Down", "/leftStick/down")
+ .With("Left", "/leftStick/left")
+ .With("Right", "/leftStick/right");
+```
+
+The 2D vector Composite has four part Bindings.
+
+|Part|Type|Description|
+|----|----|-----------|
+|[`up`](../api/UnityEngine.InputSystem.Composites.Vector2Composite.html#UnityEngine_InputSystem_Composites_Vector2Composite_up)|`Button`|Controls representing `(0,1)` (+Y).|
+|[`down`](../api/UnityEngine.InputSystem.Composites.Vector2Composite.html#UnityEngine_InputSystem_Composites_Vector2Composite_down)|`Button`|Controls representing `(0,-1)` (-Y).|
+|[`left`](../api/UnityEngine.InputSystem.Composites.Vector2Composite.html#UnityEngine_InputSystem_Composites_Vector2Composite_left)|`Button`|Controls representing `(-1,0)` (-X).|
+|[`right`](../api/UnityEngine.InputSystem.Composites.Vector2Composite.html#UnityEngine_InputSystem_Composites_Vector2Composite_right)|`Button`|Controls representing `(1,0)` (+X).|
+
+In addition, you can set the following parameters on a 2D vector Composite:
+
+|Parameter|Description|
+|---------|-----------|
+|[`mode`](../api/UnityEngine.InputSystem.Composites.Vector2Composite.html#UnityEngine_InputSystem_Composites_Vector2Composite_mode)|Whether to treat the inputs as digital or as analog controls./w")
+ .With("Down", "/s")
+ .With("Left", "/a")
+ .With("Right", "/d");
+
+// To set mode (2=analog, 1=digital, 0=digitalNormalized):
+myAction.AddCompositeBinding("3DVector(mode=2)")
+ .With("Up", "/leftStick/up")
+ .With("Down", "/leftStick/down")
+ .With("Left", "/leftStick/left")
+ .With("Right", "/leftStick/right");
+```
+
+The 3D vector Composite has four part Bindings.
+
+|Part|Type|Description|
+|----|----|-----------|
+|[`up`](../api/UnityEngine.InputSystem.Composites.Vector3Composite.html#UnityEngine_InputSystem_Composites_Vector3Composite_up)|`Button`|Controls representing `(0,1,0)` (+Y).|
+|[`down`](../api/UnityEngine.InputSystem.Composites.Vector3Composite.html#UnityEngine_InputSystem_Composites_Vector3Composite_down)|`Button`|Controls representing `(0,-1,0)` (-Y).|
+|[`left`](../api/UnityEngine.InputSystem.Composites.Vector3Composite.html#UnityEngine_InputSystem_Composites_Vector3Composite_left)|`Button`|Controls representing `(-1,0,0)` (-X).|
+|[`right`](../api/UnityEngine.InputSystem.Composites.Vector3Composite.html#UnityEngine_InputSystem_Composites_Vector3Composite_right)|`Button`|Controls representing `(1,0,0)` (+X).|
+|[`forward`](../api/UnityEngine.InputSystem.Composites.Vector3Composite.html#UnityEngine_InputSystem_Composites_Vector3Composite_forward)|`Button`|Controls representing `(0,0,1)` (+Z).|
+|[`backward`](../api/UnityEngine.InputSystem.Composites.Vector3Composite.html#UnityEngine_InputSystem_Composites_Vector3Composite_backward)|`Button`|Controls representing `(0,0,-1)` (-Z).|
+
+In addition, you can set the following parameters on a 3D vector Composite:
+
+|Parameter|Description|
+|---------|-----------|
+|[`mode`](../api/UnityEngine.InputSystem.Composites.Vector3Composite.html#UnityEngine_InputSystem_Composites_Vector3Composite_mode)|Whether to treat the inputs as digital or as analog controls./1")
+ .With("Modifier", "/ctrl")
+
+// Add binding to mouse delta such that it only takes effect
+// while the ALT key is down.
+myAction.AddCompositeBinding("OneModifier")
+ .With("Binding", "/delta")
+ .With("Modifier", "/alt");
+```
+
+The button with one modifier Composite has two part Bindings.
+
+|Part|Type|Description|
+|----|----|-----------|
+|[`modifier`](../api/UnityEngine.InputSystem.Composites.OneModifierComposite.html#UnityEngine_InputSystem_Composites_OneModifierComposite_modifier)|`Button`|Modifier that has to be held for `binding` to come through. If the user holds any of the buttons bound to the `modifier` at the same time as the button that triggers the action, the Composite assumes the value of the `modifier` Binding. If the user does not press any button bound to the `modifier`, the Composite remains at default value.|
+|[`binding`](../api/UnityEngine.InputSystem.Composites.OneModifierComposite.html#UnityEngine_InputSystem_Composites_OneModifierComposite_binding)|Any|The control(s) whose value the Composite assumes while the user holds down the `modifier` button.|
+
+This Composite has no parameters.
+
+### Two Modifiers
+
+
+
+
+
+A Composite that requires the user to hold down two "modifier" buttons in addition to another control from which the actual value of the Binding is determined. This can be used, for example, for Bindings such as "SHIFT+CTRL+1". Implemented in the [`TwoModifiersComposite`](../api/UnityEngine.InputSystem.Composites.TwoModifiersComposite.html) class. The buttons can be on any Device, and can be toggle buttons or full-range buttons such as gamepad triggers.
+
+The result is a value of the same type as the controls bound to the [`binding`](../api/UnityEngine.InputSystem.Composites.TwoModifiersComposite.html#UnityEngine_InputSystem_Composites_TwoModifiersComposite_binding) part.
+
+```CSharp
+myAction.AddCompositeBinding("TwoModifiers")
+ .With("Button", "/1")
+ .With("Modifier1", "/leftCtrl")
+ .With("Modifier1", "/rightCtrl")
+ .With("Modifier2", "/leftShift")
+ .With("Modifier2", "/rightShift");
+```
+
+The button with two modifiers Composite has three part Bindings.
+
+|Part|Type|Description|
+|----|----|-----------|
+|[`modifier1`](../api/UnityEngine.InputSystem.Composites.TwoModifiersComposite.html#UnityEngine_InputSystem_Composites_TwoModifiersComposite_modifier1)|`Button`|The first modifier the user must hold alongside `modifier2`, for `binding` to come through. If the user does not press any button bound to the `modifier1`, the Composite remains at default value.|
+|[`modifier2`](../api/UnityEngine.InputSystem.Composites.TwoModifiersComposite.html#UnityEngine_InputSystem_Composites_TwoModifiersComposite_modifier2)|`Button`|The second modifier the user must hold alongside `modifier1`, for `binding` to come through. If the user does not press any button bound to the `modifier2`, the Composite remains at default value.|
+|[`binding`](../api/UnityEngine.InputSystem.Composites.TwoModifiersComposite.html#UnityEngine_InputSystem_Composites_TwoModifiersComposite_binding)|Any|The control(s) whose value the Composite assumes while the user presses both `modifier1` and `modifier2` at the same time.|
+
+This Composite has no parameters.
+
+### Writing custom Composites
+
+You can define new types of Composites, and register them with the API. Unity treats these the same as predefined types, which the Input System internally defines and registers in the same way.
+
+To define a new type of Composite, create a class based on [`InputBindingComposite`](../api/UnityEngine.InputSystem.InputBindingComposite-1.html).
+
+> __IMPORTANT__: Composites must be __stateless__. This means that you cannot store local state that changes depending on the input being processed. For __stateful__ processing on Bindings, see [interactions](./Interactions.md#writing-custom-interactions).
+
+```CSharp
+// Use InputBindingComposite as a base class for a composite that returns
+// values of type TValue.
+// NOTE: It is possible to define a composite that returns different kinds of values
+// but doing so requires deriving directly from InputBindingComposite.
+#if UNITY_EDITOR
+[InitializeOnLoad] // Automatically register in editor.
+#endif
+// Determine how GetBindingDisplayString() formats the composite by applying
+// the DisplayStringFormat attribute.
+[DisplayStringFormat("{firstPart}+{secondPart}")]
+public class CustomComposite : InputBindingComposite
+{
+ // Each part binding is represented as a field of type int and annotated with
+ // InputControlAttribute. Setting "layout" restricts the controls that
+ // are made available for picking in the UI.
+ //
+ // On creation, the int value is set to an integer identifier for the binding
+ // part. This identifier can read values from InputBindingCompositeContext.
+ // See ReadValue() below.
+ [InputControl(layout = "Button")]
+ public int firstPart;
+
+ [InputControl(layout = "Button")]
+ public int secondPart;
+
+ // Any public field that is not annotated with InputControlAttribute is considered
+ // a parameter of the composite. This can be set graphically in the UI and also
+ // in the data (e.g. "custom(floatParameter=2.0)").
+ public float floatParameter;
+ public bool boolParameter;
+
+ // This method computes the resulting input value of the composite based
+ // on the input from its part bindings.
+ public override float ReadValue(ref InputBindingCompositeContext context)
+ {
+ var firstPartValue = context.ReadValue(firstPart);
+ var secondPartValue = context.ReadValue(secondPart);
+
+ //... do some processing and return value
+ }
+
+ // This method computes the current actuation of the binding as a whole.
+ public override float EvaluateMagnitude(ref InputBindingCompositeContext context)
+ {
+ // Compute normalized [0..1] magnitude value for current actuation level.
+ }
+
+ static CustomComposite()
+ {
+ // Can give custom name or use default (type name with "Composite" clipped off).
+ // Same composite can be registered multiple times with different names to introduce
+ // aliases.
+ //
+ // NOTE: Registering from the static constructor using InitializeOnLoad and
+ // RuntimeInitializeOnLoadMethod is only one way. You can register the
+ // composite from wherever it works best for you. Note, however, that
+ // the registration has to take place before the composite is first used
+ // in a binding. Also, for the composite to show in the editor, it has
+ // to be registered from code that runs in edit mode.
+ InputSystem.RegisterBindingComposite();
+ }
+
+ [RuntimeInitializeOnLoadMethod(RuntimeInitializeLoadType.BeforeSceneLoad)]
+ static void Init() {} // Trigger static constructor.
+}
+```
+
+The Composite should now appear in the editor UI when you add a Binding, and you can now use it in scripts.
+
+```CSharp
+ myAction.AddCompositeBinding("custom(floatParameter=2.0)")
+ .With("firstpart", "/buttonSouth")
+ .With("secondpart", "/buttonNorth");
+```
+
+To define a custom parameter editor for the Composite, you can derive from [`InputParameterEditor`](../api/UnityEngine.InputSystem.Editor.InputParameterEditor-1.html).
+
+```CSharp
+#if UNITY_EDITOR
+public class CustomParameterEditor : InputParameterEditor
+{
+ public override void OnGUI()
+ {
+ EditorGUILayout.Label("Custom stuff");
+ target.floatParameter = EditorGUILayout.FloatField("Some Parameter", target.floatParameter);
+ }
+}
+#endif
+```
\ No newline at end of file
diff --git a/Packages/com.unity.inputsystem/Documentation~/configure-action-type.md b/Packages/com.unity.inputsystem/Documentation~/configure-action-type.md
new file mode 100644
index 0000000000..55b6fb5430
--- /dev/null
+++ b/Packages/com.unity.inputsystem/Documentation~/configure-action-type.md
@@ -0,0 +1,2 @@
+# Configure Action Type
+
diff --git a/Packages/com.unity.inputsystem/Documentation~/configure-actions.md b/Packages/com.unity.inputsystem/Documentation~/configure-actions.md
new file mode 100644
index 0000000000..c05550e2db
--- /dev/null
+++ b/Packages/com.unity.inputsystem/Documentation~/configure-actions.md
@@ -0,0 +1,17 @@
+# Configure actions
+
+Configuring an action covers all the ways an action can be set up, the controls it is bound to, and the ways it responds to signals from those controls.
+
+An action's configuration includes its types, bindings, controls, control schemes, and interactions, described in this section.
+
+| **Topic** | **Description** |
+| :------------------------------ | :------------------------------- |
+| **[Action and control types](action-and-control-types.md)** | Summary |
+| **[Bindings](bindings.md)** | Summary |
+| **[Controls](controls.md)** | Summary |
+| **[Control Schemes](control-schemes.md)** | Summary |
+| **[Interactions](interactions.md)** | Summary |
+
+## Additional resources
+
+- [Actions Editor window reference](actions-editor.md)
diff --git a/Packages/com.unity.inputsystem/Documentation~/configure-bindings-from-code.md b/Packages/com.unity.inputsystem/Documentation~/configure-bindings-from-code.md
new file mode 100644
index 0000000000..e69de29bb2
diff --git a/Packages/com.unity.inputsystem/Documentation~/configure-control-type.md b/Packages/com.unity.inputsystem/Documentation~/configure-control-type.md
new file mode 100644
index 0000000000..1fb82cfb5b
--- /dev/null
+++ b/Packages/com.unity.inputsystem/Documentation~/configure-control-type.md
@@ -0,0 +1 @@
+# Configure Control Type
diff --git a/Packages/com.unity.inputsystem/Documentation~/configure-controls-from-code.md b/Packages/com.unity.inputsystem/Documentation~/configure-controls-from-code.md
new file mode 100644
index 0000000000..b78bb7236b
--- /dev/null
+++ b/Packages/com.unity.inputsystem/Documentation~/configure-controls-from-code.md
@@ -0,0 +1,2 @@
+# Configure controls from code
+
diff --git a/Packages/com.unity.inputsystem/Documentation~/configure-input-directly-from-code.md b/Packages/com.unity.inputsystem/Documentation~/configure-input-directly-from-code.md
new file mode 100644
index 0000000000..747c4f48ff
--- /dev/null
+++ b/Packages/com.unity.inputsystem/Documentation~/configure-input-directly-from-code.md
@@ -0,0 +1 @@
+# Configure input directly from code
\ No newline at end of file
diff --git a/Packages/com.unity.inputsystem/Documentation~/configure-input-from-code.md b/Packages/com.unity.inputsystem/Documentation~/configure-input-from-code.md
new file mode 100644
index 0000000000..2490e5f49c
--- /dev/null
+++ b/Packages/com.unity.inputsystem/Documentation~/configure-input-from-code.md
@@ -0,0 +1,2 @@
+# Configure input from code
+
diff --git a/Packages/com.unity.inputsystem/Documentation~/configure-input-from-json.md b/Packages/com.unity.inputsystem/Documentation~/configure-input-from-json.md
new file mode 100644
index 0000000000..6565ceb25d
--- /dev/null
+++ b/Packages/com.unity.inputsystem/Documentation~/configure-input-from-json.md
@@ -0,0 +1,2 @@
+# Configure input from JSON
+
diff --git a/Packages/com.unity.inputsystem/Documentation~/configure-interactions-from-code.md b/Packages/com.unity.inputsystem/Documentation~/configure-interactions-from-code.md
new file mode 100644
index 0000000000..c585527656
--- /dev/null
+++ b/Packages/com.unity.inputsystem/Documentation~/configure-interactions-from-code.md
@@ -0,0 +1,2 @@
+# Configure interactions from code
+
diff --git a/Packages/com.unity.inputsystem/Documentation~/configure-player-input-manager-component.md b/Packages/com.unity.inputsystem/Documentation~/configure-player-input-manager-component.md
new file mode 100644
index 0000000000..40eb8680d7
--- /dev/null
+++ b/Packages/com.unity.inputsystem/Documentation~/configure-player-input-manager-component.md
@@ -0,0 +1,2 @@
+# Configure the Player Input Manager component
+
diff --git a/Packages/com.unity.inputsystem/Documentation~/configure-processors-from-code.md b/Packages/com.unity.inputsystem/Documentation~/configure-processors-from-code.md
new file mode 100644
index 0000000000..2d509fdc75
--- /dev/null
+++ b/Packages/com.unity.inputsystem/Documentation~/configure-processors-from-code.md
@@ -0,0 +1,2 @@
+# Configure processors from code
+
diff --git a/Packages/com.unity.inputsystem/Documentation~/configure-unity-events.md b/Packages/com.unity.inputsystem/Documentation~/configure-unity-events.md
new file mode 100644
index 0000000000..c09e50b4ce
--- /dev/null
+++ b/Packages/com.unity.inputsystem/Documentation~/configure-unity-events.md
@@ -0,0 +1,2 @@
+# Configure Unity events
+
diff --git a/Packages/com.unity.inputsystem/Documentation~/control-actuation.md b/Packages/com.unity.inputsystem/Documentation~/control-actuation.md
new file mode 100644
index 0000000000..9823f14bc8
--- /dev/null
+++ b/Packages/com.unity.inputsystem/Documentation~/control-actuation.md
@@ -0,0 +1,26 @@
+# Control actuation
+
+A Control is considered actuated when it has moved away from its default state in such a way that it affects the actual value of the Control. You can query whether a Control is currently actuated using [`IsActuated`](../api/UnityEngine.InputSystem.InputControlExtensions.html#UnityEngine_InputSystem_InputControlExtensions_IsActuated_UnityEngine_InputSystem_InputControl_System_Single_).
+
+```CSharp
+// Check if leftStick is currently actuated.
+if (Gamepad.current.leftStick.IsActuated())
+ Debug.Log("Left Stick is actuated");
+```
+
+It can be useful to determine not just whether a Control is actuated at all, but also the amount by which it is actuated (that is, its magnitude). For example, for a [`Vector2Control`](../api/UnityEngine.InputSystem.Controls.Vector2Control.html) this would be the length of the vector, whereas for a button it is the raw, absolute floating-point value.
+
+In general, the current magnitude of a Control is always >= 0. However, a Control might not have a meaningful magnitude, in which case it returns -1. Any negative value should be considered an invalid magnitude.
+
+You can query the current amount of actuation using [`EvaluateMagnitude`](../api/UnityEngine.InputSystem.InputControl.html#UnityEngine_InputSystem_InputControl_EvaluateMagnitude).
+
+```CSharp
+// Check if left stick is actuated more than a quarter of its motion range.
+if (Gamepad.current.leftStick.EvaluateMagnitude() > 0.25f)
+ Debug.Log("Left Stick actuated past 25%");
+```
+
+There are two mechanisms that most notably make use of Control actuation:
+
+- [Interactive rebinding](ActionBindings.md#interactive-rebinding) (`InputActionRebindingExceptions.RebindOperation`) uses it to select between multiple suitable Controls to find the one that is actuated the most.
+- [Conflict resolution](ActionBindings.md#conflicting-inputs) between multiple Controls that are bound to the same action uses it to decide which Control gets to drive the action.
\ No newline at end of file
diff --git a/Packages/com.unity.inputsystem/Documentation~/control-haptics.md b/Packages/com.unity.inputsystem/Documentation~/control-haptics.md
new file mode 100644
index 0000000000..9e10cd31a4
--- /dev/null
+++ b/Packages/com.unity.inputsystem/Documentation~/control-haptics.md
@@ -0,0 +1 @@
+# Control haptics
diff --git a/Packages/com.unity.inputsystem/Documentation~/control-hierarchies.md b/Packages/com.unity.inputsystem/Documentation~/control-hierarchies.md
new file mode 100644
index 0000000000..0bccb24729
--- /dev/null
+++ b/Packages/com.unity.inputsystem/Documentation~/control-hierarchies.md
@@ -0,0 +1,7 @@
+# Control hierarchies
+
+Controls can form hierarchies. The root of a Control hierarchy is always a [Device](Devices.md).
+
+The setup of hierarchies is exclusively controlled through [layouts](layouts.md).
+
+You can access the parent of a Control using [`InputControl.parent`](../api/UnityEngine.InputSystem.InputControl.html#UnityEngine_InputSystem_InputControl_parent), and its children using [`InputControl.children`](../api/UnityEngine.InputSystem.InputControl.html#UnityEngine_InputSystem_InputControl_children). To access the flattened hierarchy of all Controls on a Device, use [`InputDevice.allControls`](../api/UnityEngine.InputSystem.InputDevice.html#UnityEngine_InputSystem_InputDevice_allControls).
\ No newline at end of file
diff --git a/Packages/com.unity.inputsystem/Documentation~/control-items.md b/Packages/com.unity.inputsystem/Documentation~/control-items.md
new file mode 100644
index 0000000000..cd0fe61697
--- /dev/null
+++ b/Packages/com.unity.inputsystem/Documentation~/control-items.md
@@ -0,0 +1 @@
+# Control items
diff --git a/Packages/com.unity.inputsystem/Documentation~/control-paths.md b/Packages/com.unity.inputsystem/Documentation~/control-paths.md
new file mode 100644
index 0000000000..83a6ea6ead
--- /dev/null
+++ b/Packages/com.unity.inputsystem/Documentation~/control-paths.md
@@ -0,0 +1,44 @@
+# Control paths
+
+>Example: `/leftStick/x` means "X Control on left stick of gamepad".
+
+The Input System can look up Controls using textual paths. [Bindings](ActionBindings.md) on Input Actions rely on this feature to identify the Control(s) they read input from. However, you can also use them for lookup directly on Controls and Devices, or to let the Input System search for Controls among all devices using [`InputSystem.FindControls`](../api/UnityEngine.InputSystem.InputSystem.html#UnityEngine_InputSystem_InputSystem_FindControls_System_String_).
+
+```CSharp
+var gamepad = Gamepad.all[0];
+var leftStickX = gamepad["leftStick/x"];
+var submitButton = gamepad["{Submit}"];
+var allSubmitButtons = InputSystem.FindControls("*/{Submit}");
+```
+
+Control paths resemble file system paths. Each path consists of one or more components separated by a forward slash:
+
+ component/component...
+
+Each component uses a similar syntax made up of multiple fields. Each field is optional, but at least one field must be present. All fields are case-insensitive.
+
+ {usageName}controlName#(displayName)
+
+The following table explains the use of each field:
+
+|Field|Description|Example|
+|-----|-----------|-------|
+|``|Requires the Control at the current level to be based on the given layout. The actual layout of the Control may be the same or a layout *based* on the given layout.|`/buttonSouth`|
+|`{usageName}`|Works differently for Controls and Devices.{LeftHand}/trigger`/{Submit}`|
+|`controlName`|Requires the Control at the current level to have the given name. Takes both "proper" names ([`InputControl.name`](../api/UnityEngine.InputSystem.InputControl.html#UnityEngine_InputSystem_InputControl_name)) and aliases ([`InputControl.aliases`](../api/UnityEngine.InputSystem.InputControl.html#UnityEngine_InputSystem_InputControl_aliases)) into account./#(a)` (matches the key that generates the "a" character, if any, according to the current keyboard layout)./#(Cross)`|
+
+You can access the literal path of a given control via its [`InputControl.path`](../api/UnityEngine.InputSystem.InputControl.html#UnityEngine_InputSystem_InputControl_path) property.
+
+If needed, you can manually parse a control path into its components using the [`InputControlPath.Parse(path)`](../api/UnityEngine.InputSystem.InputControlPath.html#UnityEngine_InputSystem_InputControlPath_Parse_System_String_) API.
+
+```CSharp
+var parsed = InputControlPath.Parse("{LeftHand}/trigger").ToArray();
+
+Debug.Log(parsed.Length); // Prints 2.
+Debug.Log(parsed[0].layout); // Prints "XRController".
+Debug.Log(parsed[0].name); // Prints an empty string.
+Debug.Log(parsed[0].usages.First()); // Prints "LeftHand".
+Debug.Log(parsed[1].layout); // Prints null.
+Debug.Log(parsed[1].name); // Prints "trigger".
+```
diff --git a/Packages/com.unity.inputsystem/Documentation~/control-schemes.md b/Packages/com.unity.inputsystem/Documentation~/control-schemes.md
new file mode 100644
index 0000000000..c5990b75e3
--- /dev/null
+++ b/Packages/com.unity.inputsystem/Documentation~/control-schemes.md
@@ -0,0 +1,9 @@
+# Editing Control Schemes
+
+Input Action Assets can have multiple [Control Schemes](ActionBindings.md#control-schemes), which let you enable or disable different sets of Bindings for your Actions for different types of Devices.
+
+
+
+To see the Control Schemes in the Input Action Asset editor window, open the Control Scheme drop-down list in the top left of the window. This menu lets you add or remove Control Schemes to your Actions Asset. If the Actions Asset contains any Control Schemes, you can select a Control Scheme, and then the window only shows bindings that are associated with that Scheme. If you select a binding, you can now pick the Control Schemes for which this binding should be active in the __Properties__ view to the left of the window.
+
+When you add a new Control Scheme, or select an existing Control Scheme, and then select __Edit Control Scheme__, you can edit the name of the Control Scheme and which devices the Scheme should be active for. When you add a new Control Scheme, the "Device Type" list is empty by default (as shown above). You must add at least one type of device to this list for the Control Scheme to be functional.
diff --git a/Packages/com.unity.inputsystem/Documentation~/control-state.md b/Packages/com.unity.inputsystem/Documentation~/control-state.md
new file mode 100644
index 0000000000..efa48ac663
--- /dev/null
+++ b/Packages/com.unity.inputsystem/Documentation~/control-state.md
@@ -0,0 +1,18 @@
+## Control state
+
+Each Control is connected to a block of memory that is considered the Control's "state". You can query the size, format, and location of this block of memory from a Control through the [`InputControl.stateBlock`](../api/UnityEngine.InputSystem.InputControl.html#UnityEngine_InputSystem_InputControl_stateBlock) property.
+
+The state of Controls is stored in unmanaged memory that the Input System handles internally. All Devices added to the system share one block of unmanaged memory that contains the state of all the Controls on the Devices.
+
+A Control's state might not be stored in the natural format for that Control. For example, the system often represents buttons as bitfields, and axis controls as 8-bit or 16-bit integer values. This format is determined by the combination of platform, hardware, and drivers. Each Control knows the format of its storage and how to translate the values as needed. The Input System uses [layouts](layouts.md) to understand this representation.
+
+You can access the current state of a Control through its [`ReadValue`](../api/UnityEngine.InputSystem.InputControl-1.html#UnityEngine_InputSystem_InputControl_1_ReadValue) method.
+
+```CSharp
+Gamepad.current.leftStick.x.ReadValue();
+```
+
+Each type of Control has a specific type of values that it returns, regardless of how many different types of formats it supports for its state. You can access this value type through the [`InputControl.valueType`](../api/UnityEngine.InputSystem.InputControl.html#UnityEngine_InputSystem_InputControl_valueType) property.
+
+Reading a value from a Control might apply one or more value Processors. See documentation on [Processors](Processors.md) for more information.
+
diff --git a/Packages/com.unity.inputsystem/Documentation~/control-types.md b/Packages/com.unity.inputsystem/Documentation~/control-types.md
new file mode 100644
index 0000000000..21649411f9
--- /dev/null
+++ b/Packages/com.unity.inputsystem/Documentation~/control-types.md
@@ -0,0 +1,20 @@
+# Control types
+
+All controls are based on the [`InputControl`](../api/UnityEngine.InputSystem.InputControl.html) base class. Most concrete implementations are based on [`InputControl`](../api/UnityEngine.InputSystem.InputControl-1.html).
+
+The Input System provides the following types of controls out of the box:
+
+|Control Type|Description|Example|
+|------------|-----------|-------|
+|[`AxisControl`](../api/UnityEngine.InputSystem.Controls.AxisControl.html)|A 1D floating-point axis.|[`Gamepad.leftStick.x`](../api/UnityEngine.InputSystem.Controls.Vector2Control.html#UnityEngine_InputSystem_Controls_Vector2Control_x)|
+|[`ButtonControl`](../api/UnityEngine.InputSystem.Controls.ButtonControl.html)|A button expressed as a floating-point value. Whether the button can have a value other than 0 or 1 depends on the underlying representation. For example, gamepad trigger buttons can have values other than 0 and 1, but gamepad face buttons generally can't.|[`Mouse.leftButton`](../api/UnityEngine.InputSystem.Mouse.html#UnityEngine_InputSystem_Mouse_leftButton)|
+|[`KeyControl`](../api/UnityEngine.InputSystem.Controls.KeyControl.html)|A specialized button that represents a key on a [`Keyboard`](../api/UnityEngine.InputSystem.Keyboard.html). Keys have an associated [`keyCode`](../api/UnityEngine.InputSystem.Controls.KeyControl.html#UnityEngine_InputSystem_Controls_KeyControl_keyCode) and, unlike other types of Controls, change their display name in accordance to the currently active system-wide keyboard layout. See the [Keyboard](Keyboard.md) documentation for details.|[`Keyboard.aKey`](../api/UnityEngine.InputSystem.Keyboard.html#UnityEngine_InputSystem_Keyboard_aKey)|
+|[`Vector2Control`](../api/UnityEngine.InputSystem.Controls.Vector2Control.html)|A 2D floating-point vector.|[`Pointer.position`](../api/UnityEngine.InputSystem.Pointer.html#UnityEngine_InputSystem_Pointer_position)|
+|[`Vector3Control`](../api/UnityEngine.InputSystem.Controls.Vector3Control.html)|A 3D floating-point vector.|[`Accelerometer.acceleration`](../api/UnityEngine.InputSystem.Accelerometer.html#UnityEngine_InputSystem_Accelerometer_acceleration)|
+|[`QuaternionControl`](../api/UnityEngine.InputSystem.Controls.QuaternionControl.html)|A 3D rotation.|[`AttitudeSensor.attitude`](../api/UnityEngine.InputSystem.AttitudeSensor.html#UnityEngine_InputSystem_AttitudeSensor_attitude)|
+|[`IntegerControl`](../api/UnityEngine.InputSystem.Controls.IntegerControl.html)|An integer value.|[`Touchscreen.primaryTouch.touchId`](../api/UnityEngine.InputSystem.Controls.TouchControl.html#UnityEngine_InputSystem_Controls_TouchControl_touchId)|
+|[`StickControl`](../api/UnityEngine.InputSystem.Controls.StickControl.html)|A 2D stick control like the thumbsticks on gamepads or the stick control of a joystick.|[`Gamepad.rightStick`](../api/UnityEngine.InputSystem.Gamepad.html#UnityEngine_InputSystem_Gamepad_rightStick)|
+|[`DpadControl`](../api/UnityEngine.InputSystem.Controls.DpadControl.html)|A 4-way button control like the D-pad on gamepads or hatswitches on joysticks.|[`Gamepad.dpad`](../api/UnityEngine.InputSystem.Gamepad.html#UnityEngine_InputSystem_Gamepad_dpad)|
+|[`TouchControl`](../api/UnityEngine.InputSystem.Controls.TouchControl.html)|A control that represents all the properties of a touch on a [touch screen](Touch.md).|[`Touchscreen.primaryTouch`](../api/UnityEngine.InputSystem.Touchscreen.html#UnityEngine_InputSystem_Touchscreen_primaryTouch)|
+
+You can browse the set of all registered control layouts in the [input debugger](Debugging.md#debugging-layouts).
diff --git a/Packages/com.unity.inputsystem/Documentation~/control-usages.md b/Packages/com.unity.inputsystem/Documentation~/control-usages.md
new file mode 100644
index 0000000000..95d1b3674f
--- /dev/null
+++ b/Packages/com.unity.inputsystem/Documentation~/control-usages.md
@@ -0,0 +1,8 @@
+
+## Control usages
+
+A Control can have one or more associated usages. A usage is a string that denotes the Control's intended use. An example of a Control usage is `Submit`, which labels a Control that is commonly used to confirm a selection in the UI. On a gamepad, this usage is commonly found on the `buttonSouth` Control.
+
+You can access a Control's usages using the [`InputControl.usages`](../api/UnityEngine.InputSystem.InputControl.html#UnityEngine_InputSystem_InputControl_usages) property.
+
+Usages can be arbitrary strings. However, a certain set of usages is very commonly used and comes predefined in the API in the form of the [`CommonUsages`](../api/UnityEngine.InputSystem.CommonUsages.html) static class. Check out the [`CommonUsages` scripting API page](../api/UnityEngine.InputSystem.CommonUsages.html) for an overview.
diff --git a/Packages/com.unity.inputsystem/Documentation~/corresponding-old-new-api.md b/Packages/com.unity.inputsystem/Documentation~/corresponding-old-new-api.md
new file mode 100644
index 0000000000..196b0728de
--- /dev/null
+++ b/Packages/com.unity.inputsystem/Documentation~/corresponding-old-new-api.md
@@ -0,0 +1 @@
+# Corresponding old and new API
diff --git a/Packages/com.unity.inputsystem/Documentation~/create-actions-in-code.md b/Packages/com.unity.inputsystem/Documentation~/create-actions-in-code.md
new file mode 100644
index 0000000000..61f7cd505a
--- /dev/null
+++ b/Packages/com.unity.inputsystem/Documentation~/create-actions-in-code.md
@@ -0,0 +1,29 @@
+# Creating Actions in code
+
+You can manually create and configure Actions entirely in code, including assigning the bindings. This also works at runtime in the Player. For example:
+
+```CSharp
+// Create free-standing Actions.
+var lookAction = new InputAction("look", binding: "/leftStick");
+var moveAction = new InputAction("move", binding: "/rightStick");
+
+lookAction.AddBinding("/delta");
+moveAction.AddCompositeBinding("Dpad")
+ .With("Up", "/w")
+ .With("Down", "/s")
+ .With("Left", "/a")
+ .With("Right", "/d");
+
+// Create an Action Map with Actions.
+var map = new InputActionMap("Gameplay");
+var lookAction = map.AddAction("look");
+lookAction.AddBinding("/leftStick");
+
+// Create an Action Asset.
+var asset = ScriptableObject.CreateInstance();
+var gameplayMap = new InputActionMap("gameplay");
+asset.AddActionMap(gameplayMap);
+var lookAction = gameplayMap.AddAction("look", "/leftStick");
+```
+
+Any action that you create in this way during Play mode do not persist in the Input Action Asset after you exit Play mode. This means you can test your application in a realistic manner in the Editor without having to worry about inadvertently modifying the asset.
diff --git a/Packages/com.unity.inputsystem/Documentation~/create-custom-device-layout.md b/Packages/com.unity.inputsystem/Documentation~/create-custom-device-layout.md
new file mode 100644
index 0000000000..08d7725b2a
--- /dev/null
+++ b/Packages/com.unity.inputsystem/Documentation~/create-custom-device-layout.md
@@ -0,0 +1 @@
+# Create a custom device layout
diff --git a/Packages/com.unity.inputsystem/Documentation~/create-custom-device.md b/Packages/com.unity.inputsystem/Documentation~/create-custom-device.md
new file mode 100644
index 0000000000..8f97a11a3f
--- /dev/null
+++ b/Packages/com.unity.inputsystem/Documentation~/create-custom-device.md
@@ -0,0 +1 @@
+# Create a custom device
diff --git a/Packages/com.unity.inputsystem/Documentation~/create-custom-on-screen-control.md b/Packages/com.unity.inputsystem/Documentation~/create-custom-on-screen-control.md
new file mode 100644
index 0000000000..0abaa297a8
--- /dev/null
+++ b/Packages/com.unity.inputsystem/Documentation~/create-custom-on-screen-control.md
@@ -0,0 +1 @@
+# Create a custom on-screen control
diff --git a/Packages/com.unity.inputsystem/Documentation~/create-device.md b/Packages/com.unity.inputsystem/Documentation~/create-device.md
new file mode 100644
index 0000000000..71e36a506b
--- /dev/null
+++ b/Packages/com.unity.inputsystem/Documentation~/create-device.md
@@ -0,0 +1 @@
+# Create a device
diff --git a/Packages/com.unity.inputsystem/Documentation~/create-edit-delete-action-maps.md b/Packages/com.unity.inputsystem/Documentation~/create-edit-delete-action-maps.md
new file mode 100644
index 0000000000..42f8be7a52
--- /dev/null
+++ b/Packages/com.unity.inputsystem/Documentation~/create-edit-delete-action-maps.md
@@ -0,0 +1,12 @@
+# Create, Edit and Delete Action Maps
+
+Action maps provide a way to group collections of Actions that represent different input scenarios in your project (such as UI navigation, gameplay, etc.)
+
+Actions must belong to an Action Map, therefore if you are starting with an empty Actions Asset, you must create an action map before you can create any actions.
+
+The Action Maps section on the left side of the [Actions Editor window](./actions-editor.md) allows you to create, rename, delete, and duplicate Action Maps.
+
+* To add a new Action Map, select the Add (+) icon in the header of the Action Map panel.
+* To rename an existing Action Map, either long-click the name, or right-click the Action Map and select __Rename__ from the context menu. Note that Action Map names can't contain slashes (`/`).
+* To delete an existing Action Map, right-click it and select __Delete__ from the context menu.
+* To duplicate an existing Action Map, right-click it and select __Duplicate__ from the context menu.
diff --git a/Packages/com.unity.inputsystem/Documentation~/create-edit-delete-actions.md b/Packages/com.unity.inputsystem/Documentation~/create-edit-delete-actions.md
new file mode 100644
index 0000000000..a036a3cb9d
--- /dev/null
+++ b/Packages/com.unity.inputsystem/Documentation~/create-edit-delete-actions.md
@@ -0,0 +1,45 @@
+
+# Create, Edit and Delete Actions
+
+The simplest way to create, edit or delete actions is to use the [Input Actions editor](ActionsEditor.md) in the Project Settings window. This is the primary recommended workflow and suitable for most scenarios.
+
+However there are many other ways to work with actions which might suit less common scenarios. For example, by [loading actions from JSON data](load-actions-from-json.md), or [creating actions entirely in code](configure-input-directly-from-code.md).
+
+## Create Actions using the Action editor
+
+For information on how to create and edit Input Actions in the editor, see the [Input Actions editor](ActionsEditor.md). This is the recommended workflow if you want to organise all your input actions and bindings in one place, which applies across the whole of your project. This often the case for most types of game or app.
+
+
+*The Input Actions Editor in the Project Settings window*
+
+
+### Add, rename, duplicate or delete actions
+
+* To add a new Action, select the Add (+) icon in the header of the Action column.
+* To rename an existing Action, either long-click the name, or right-click the Action and select __Rename__ from the context menu.
+* To delete an existing Action, either right-click it and select __Delete__ from the context menu.
+* To duplicate an existing Action, either right-click it and select __Duplicate__ from the context menu.
+
+
+If you’d like to delete all the actions so that you can start from an empty configuration, you don’t need to delete the individual actions one-by-one. You can delete the each Action Map, which deletes all the Actions contained in the maps in one go.
+
+You can also delete all action maps, or reset all the actions back to the default values from the **more** (â‹®) menu at the top right of the Input Actions section of the settings window, below the Project Settings window search field.
+
+
+
+> **Note:** this **more** (â‹®) menu is only available when the Actions Editor is viewed within the Project Settings window. It isn't available when the Actions Editor is open in a separate window.
+
+
+## Other ways to create Actions
+
+The simplest way to create actions is to use the [Input Actions editor](ActionsEditor.md) to configure a set of actions in an asset, as described above. However, because the Input System package API is open and flexible, you can create actions using alternative techniques. These alternatives might be more suitable if you want to customize your project beyond the standard workflow.
+
+See:
+
+- [Stand-alone actions](stand-alone-actions.md)
+- [Loading actions from JSON](load-actions-from-json.md)
+- [Creating actions in code](./create-actions-in-code.md)
+
+
+
+
diff --git a/Packages/com.unity.inputsystem/Documentation~/create-empty-action-asset.md b/Packages/com.unity.inputsystem/Documentation~/create-empty-action-asset.md
new file mode 100644
index 0000000000..2ce9ba887a
--- /dev/null
+++ b/Packages/com.unity.inputsystem/Documentation~/create-empty-action-asset.md
@@ -0,0 +1,15 @@
+# Create an empty action asset
+
+Usually you only need one Action Asset, assigned as the project-wide actions. The input package provides a convenient way to [create a set of useful default actions and assign them as project-wide](assign-project-wide-actions.md) which is the most common and recommended workflow. In other cases, you might want to start with an empty actions asset, or create more than one actions asset.
+
+To do this:
+
+1. Go to __Assets > Create > Input Actions__ from Unity's main menu/
+
+(or)
+
+1. Click the project window's **Add (+)** button.
+2. Select **Input Actions** from the menu.
+
+When you create an action asset this way, the new action asset is empty, containing no actions, action maps, or control schemes. You must [add](./create-edit-delete-actions.md) and [configure](./configure-actions.md) new actions to use it. The new action asset is also not assigned as [project-wide](./assign-project-wide-actions.md).
+
diff --git a/Packages/com.unity.inputsystem/Documentation~/create-events.md b/Packages/com.unity.inputsystem/Documentation~/create-events.md
new file mode 100644
index 0000000000..ce6798ecaa
--- /dev/null
+++ b/Packages/com.unity.inputsystem/Documentation~/create-events.md
@@ -0,0 +1 @@
+# Create events
diff --git a/Packages/com.unity.inputsystem/Documentation~/create-on-screen-button.md b/Packages/com.unity.inputsystem/Documentation~/create-on-screen-button.md
new file mode 100644
index 0000000000..514b837c85
--- /dev/null
+++ b/Packages/com.unity.inputsystem/Documentation~/create-on-screen-button.md
@@ -0,0 +1 @@
+# Create an on-screen button
diff --git a/Packages/com.unity.inputsystem/Documentation~/create-on-screen-stick.md b/Packages/com.unity.inputsystem/Documentation~/create-on-screen-stick.md
new file mode 100644
index 0000000000..3844e2cb1e
--- /dev/null
+++ b/Packages/com.unity.inputsystem/Documentation~/create-on-screen-stick.md
@@ -0,0 +1 @@
+# Create an on-screen stick
diff --git a/Packages/com.unity.inputsystem/Documentation~/create-precompiled-layout.md b/Packages/com.unity.inputsystem/Documentation~/create-precompiled-layout.md
new file mode 100644
index 0000000000..a8b70dc0e3
--- /dev/null
+++ b/Packages/com.unity.inputsystem/Documentation~/create-precompiled-layout.md
@@ -0,0 +1 @@
+# Create a precompiled layout
diff --git a/Packages/com.unity.inputsystem/Documentation~/create-project-wide-actions.md b/Packages/com.unity.inputsystem/Documentation~/create-project-wide-actions.md
new file mode 100644
index 0000000000..60b6985f9a
--- /dev/null
+++ b/Packages/com.unity.inputsystem/Documentation~/create-project-wide-actions.md
@@ -0,0 +1,28 @@
+# Create and assign a default project-wide actions asset
+
+Follow these steps to create an actions asset that contains the built-in [default actions](./TheDefaultActions.md), and assign them as project-wide.
+
+Open the Input System Package panel in Project Settings, by going to **Edit** > **Project Settings** > **Input System Package**.
+
+If you don't yet have an Action Asset assigned as project-wide in your project, the Input System Package settings window displays an empty field for you to assign your action asset, and a button allowing you to create and assign one.
+
+
+*The Input System Package Project Settings with no project-wide actions assigned*
+
+> **Note:** If you already have an Action Asset assigned, this button is not displayed, and instead the Actions Editor is displayed, allowing you to edit the currently assigned project-wide actions.
+
+Click **"Create a new project-wide Action Asset"**.
+
+The asset is created in your project, and automatically assigned as the **project-wide actions**.
+
+The Action Asset appears in your Project view, and is named "InputSystem_Actions". This is where your new configuration of actions is saved, including any changes you make to it.
+
+/*Trigger");
+var passThroughAction = new InputAction(type: InputActionType.PassThrough,
+ binding: "/*Trigger");
+
+buttonAction.performed += c => Debug.Log("${c.control.name} pressed (Button)");
+passThroughAction.performed += c => Debug.Log("${c.control.name} changed (Pass-Through)");
+
+buttonAction.Enable();
+passThroughAction.Enable();
+
+// Press the left trigger all the way down.
+// This will trigger both buttonAction and passThroughAction. Both will
+// see leftTrigger becoming the activeControl.
+Set(gamepad.leftTrigger, 1f);
+
+// Will log
+// "leftTrigger pressed (Button)" and
+// "leftTrigger changed (Pass-Through)"
+
+// Press the right trigger halfway down.
+// This will *not* trigger or otherwise change buttonAction as the right trigger
+// is actuated *less* than the left one that is already driving action.
+// However, passThrough action is not performing such tracking and will thus respond
+// directly to the value change. It will perform and make rightTrigger its activeControl.
+Set(gamepad.rightTrigger, 0.5f);
+
+// Will log
+// "rightTrigger changed (Pass-Through)"
+
+// Release the left trigger.
+// For buttonAction, this will mean that now all controls feeding into the action have
+// been released and thus the button releases. activeControl will go back to null.
+// For passThrough action, this is just another value change. So, the action performs
+// and its active control changes to leftTrigger.
+Set(gamepad.leftTrigger, 0f);
+
+// Will log
+// "leftTrigger changed (Pass-Through)"
+```
+
+For [composite bindings](#composite-bindings), magnitudes of the composite as a whole rather than for individual Controls are tracked. However, [`activeControl`](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_activeControl) will stick track individual Controls from the composite.
+
+##### Disabling Conflict Resolution
+
+Conflict resolution is always applied to [Button](RespondingToActions.md#button) and [Value](RespondingToActions.md#value) type Actions. However, it can be undesirable in situations when an Action is simply used to gather any and all inputs from bound Controls. For example, the following Action would monitor the A button of all available gamepads:
+
+```CSharp
+var action = new InputAction(type: InputActionType.PassThrough, binding: "/buttonSouth");
+action.Enable();
+```
+
+By using the [Pass-Through](RespondingToActions.md#pass-through) Action type, conflict resolution is bypassed and thus, pressing the A button on one gamepad will not result in a press on a different gamepad being ignored.
+
+#### Multiple input sequences (such as keyboard shortcuts)
+
+>__Note__: The mechanism described here only applies to Actions that are part of the same [`InputActionMap`](../api/UnityEngine.InputSystem.InputActionMap.html) or [`InputActionAsset`](../api/UnityEngine.InputSystem.InputActionAsset.html).
+
+Inputs that are used in combinations with other inputs may also lead to ambiguities. If, for example, the `b` key on the Keyboard is bound both on its own as well as in combination with the `shift` key, then if you first press `shift` and then `b`, the latter key press would be a valid input for either of the Actions.
+
+The way this is handled is that Bindings will be processed in the order of decreasing "complexity". This metric is derived automatically from the Binding:
+
+* A binding that is *not* part of a [composite](#composite-bindings) is assigned a complexity of 1.
+* A binding that *is* part of a [composite](#composite-bindings) is assigned a complexity equal to the number of part bindings in the composite.
+
+In our example, this means that a [`OneModifier`](#one-modifier) composite Binding to `Shift+B` has a higher "complexity" than a Binding to `B` and thus is processed first.
+
+Additionally, the first Binding that results in the Action changing [phase](RespondingToActions.md#action-callbacks) will "consume" the input. This consuming will result in other Bindings to the same input not being processed. So in our example, when `Shift+B` "consumes" the `B` input, the Binding to `B` will be skipped.
+
+The following example illustrates how this works at the API level.
+
+```CSharp
+// Create two actions in the same map.
+var map = new InputActionMap();
+var bAction = map.AddAction("B");
+var shiftbAction = map.AddAction("ShiftB");
+
+// Bind one of the actions to 'B' and the other to 'SHIFT+B'.
+bAction.AddBinding("/b");
+shiftbAction.AddCompositeBinding("OneModifier")
+ .With("Modifier", "/shift")
+ .With("Binding", "/b");
+
+// Print something to the console when the actions are triggered.
+bAction.performed += _ => Debug.Log("B action performed");
+shiftbAction.performed += _ => Debug.Log("SHIFT+B action performed");
+
+// Start listening to input.
+map.Enable();
+
+// Now, let's assume the left shift key on the keyboard is pressed (here, we manually
+// press it with the InputTestFixture API).
+Press(Keyboard.current.leftShiftKey);
+
+// And then the B is pressed. This is a valid input for both
+// bAction as well as shiftbAction.
+//
+// What will happen now is that shiftbAction will do its processing first. In response,
+// it will *perform* the action (i.e. we see the `performed` callback being invoked) and
+// thus "consume" the input. bAction will stay silent as it will in turn be skipped over.
+Press(keyboard.bKey);
+```
\ No newline at end of file
diff --git a/Packages/com.unity.inputsystem/Documentation~/debug-action.md b/Packages/com.unity.inputsystem/Documentation~/debug-action.md
new file mode 100644
index 0000000000..bf20a65503
--- /dev/null
+++ b/Packages/com.unity.inputsystem/Documentation~/debug-action.md
@@ -0,0 +1 @@
+# Debug an action
diff --git a/Packages/com.unity.inputsystem/Documentation~/debug-device.md b/Packages/com.unity.inputsystem/Documentation~/debug-device.md
new file mode 100644
index 0000000000..a13e8cffd0
--- /dev/null
+++ b/Packages/com.unity.inputsystem/Documentation~/debug-device.md
@@ -0,0 +1 @@
+# Debug a device
diff --git a/Packages/com.unity.inputsystem/Documentation~/debug-layouts.md b/Packages/com.unity.inputsystem/Documentation~/debug-layouts.md
new file mode 100644
index 0000000000..039925673c
--- /dev/null
+++ b/Packages/com.unity.inputsystem/Documentation~/debug-layouts.md
@@ -0,0 +1 @@
+# Debug layouts
diff --git a/Packages/com.unity.inputsystem/Documentation~/debug-player-input-component.md b/Packages/com.unity.inputsystem/Documentation~/debug-player-input-component.md
new file mode 100644
index 0000000000..f4fc795989
--- /dev/null
+++ b/Packages/com.unity.inputsystem/Documentation~/debug-player-input-component.md
@@ -0,0 +1,2 @@
+# Debug the Player Input component
+
diff --git a/Packages/com.unity.inputsystem/Documentation~/debug-users-playerinput.md b/Packages/com.unity.inputsystem/Documentation~/debug-users-playerinput.md
new file mode 100644
index 0000000000..54bcf052b7
--- /dev/null
+++ b/Packages/com.unity.inputsystem/Documentation~/debug-users-playerinput.md
@@ -0,0 +1 @@
+# Debug users and PlayerInput
diff --git a/Packages/com.unity.inputsystem/Documentation~/debugging-(Old Content).md b/Packages/com.unity.inputsystem/Documentation~/debugging-(Old Content).md
new file mode 100644
index 0000000000..e085705734
--- /dev/null
+++ b/Packages/com.unity.inputsystem/Documentation~/debugging-(Old Content).md
@@ -0,0 +1,175 @@
+---
+uid: input-system-debugging
+---
+# Debugging
+
+- [Input Debugger](#input-debugger)
+ - [Debugging Devices](#debugging-devices)
+ - [Debugging Actions](#debugging-actions)
+ - [Debugging users and PlayerInput](#debugging-users-and-playerinput)
+ - [Debugging layouts](#debugging-layouts)
+ - [Debugging remotely](#debugging-remotely)
+- [Input visualizers](#input-visualizers)
+ - [`InputControlVisualizer`](#inputcontrolvisualizer)
+ - [`InputActionVisualizer`](#inputactionvisualizer)
+- [Device Simulator](#device-simulator)
+- [Unity Remote](#unity-remote)
+- [Other tips:](#other-tips)
+
+When something isn't working as expected, the quickest way to troubleshoot what's wrong is the Input Debugger in the Unity Editor. The Input Debugger provides access to the activity of the Input System in both the Editor and the connected Players.
+
+To open the Input Debugger, go to __Window > Analysis > Input Debugger__ from Unity's main menu.
+
+## Input Debugger
+
+
+
+The Input Debugger displays a tree breakdown of the state of the Input System.
+
+|Item|Description|
+|----|-----------|
+|Devices|A list of all [Input Devices](Devices.md) that are currently in the system, and a list of unsupported/unrecognized Devices.|
+|Layouts|A list of all registered Control and Device layouts. This is the database of supported hardware, and information on how to represent a given piece of input hardware.|
+|Actions|Only visible in Play mode, and only if at least one [Action](actions.md) is enabled.(
+ matches: new InputDeviceMatcher()
+ .WithInterface("HID")
+ .WithProduct("MyDevice.*")
+ .WithManufacturer("MyBrand");
+
+// Register an alternate matcher for an already registered layout.
+InputSystem.RegisterLayoutMatcher(
+ new InputDeviceMatcher()
+ .WithInterface("HID")
+
+```
+
+If multiple matchers are matching the same [`InputDeviceDescription`](../api/UnityEngine.InputSystem.Layouts.InputDeviceDescription.html), the Input System chooses the matcher that has the larger number of properties to match against.
+
+#### Hijacking the matching process
+
+You can overrule the internal matching process from outside to select a different layout for a Device than the system would normally choose. This also makes it possible to quickly build new layouts. To do this, add a custom handler to the [`InputSystem.onFindControlLayoutForDevice`](../api/UnityEngine.InputSystem.InputSystem.html#UnityEngine_InputSystem_InputSystem_onFindLayoutForDevice) event. If your handler returns a non-null layout string, then the Input System uses this layout.
+
+### Device lifecycle
+
+#### Device creation
+
+Once the system has chosen a [layout](layouts.md) for a device, it instantiates an [`InputDevice`](../api/UnityEngine.InputSystem.InputDevice.html) and populates it with [`InputControls`](../api/UnityEngine.InputSystem.InputControl.html) as the layout dictates. This process is internal and happens automatically.
+
+>__Note__: You can't create valid [`InputDevices`](../api/UnityEngine.InputSystem.InputDevice.html) and [`InputControls`](../api/UnityEngine.InputSystem.InputControl.html) by manually instantiating them with `new`. To guide the creation process, you must use [layouts](layouts.md).
+
+After the Input System assembles the [`InputDevice`](../api/UnityEngine.InputSystem.InputDevice.html), it calls [`FinishSetup`](../api/UnityEngine.InputSystem.InputControl.html#UnityEngine_InputSystem_InputControl_FinishSetup_) on each control of the device and on the device itself. Use this to finalize the setup of the Controls.
+
+After an [`InputDevice`](../api/UnityEngine.InputSystem.InputDevice.html) is fully assembled, the Input System adds it to the system. As part of this process, the Input System calls [`MakeCurrent`](../api/UnityEngine.InputSystem.InputDevice.html#UnityEngine_InputSystem_InputDevice_MakeCurrent_) on the Device, and signals [`InputDeviceChange.Added`](../api/UnityEngine.InputSystem.InputDeviceChange.html#UnityEngine_InputSystem_InputDeviceChange_Added) on [`InputSystem.onDeviceChange`](../api/UnityEngine.InputSystem.InputSystem.html#UnityEngine_InputSystem_InputSystem_onDeviceChange). The Input System also calls [`InputDevice.OnAdded`](../api/UnityEngine.InputSystem.InputDevice.html#UnityEngine_InputSystem_InputDevice_OnAdded_).
+
+Once added, the [`InputDevice.added`](../api/UnityEngine.InputSystem.InputDevice.html#UnityEngine_InputSystem_InputDevice_added) flag is set to true.
+
+To add devices manually, you can call one of the `InputSystem.AddDevice` methods such as [`InputSystem.AddDevice(layout)`](../api/UnityEngine.InputSystem.InputSystem.html#UnityEngine_InputSystem_InputSystem_AddDevice_System_String_System_String_System_String_).
+
+```CSharp
+// Add a gamepad. This bypasses the matching process and creates a device directly
+// with the Gamepad layout.
+InputSystem.AddDevice();
+
+// Add a device such that the matching process is employed:
+InputSystem.AddDevice(new InputDeviceDescription
+{
+ interfaceName = "XInput",
+ product = "Xbox Controller",
+});
+```
+
+When a device is added, the Input System automatically issues a [sync request](../api/UnityEngine.InputSystem.LowLevel.RequestSyncCommand.html) on the device. This instructs the device to send an event representing its current state. Whether this request succeeds depends on the whether the given device supports the sync command.
+
+#### Device removal
+
+When a Device is disconnected, it is removed from the system. A notification appears for [`InputDeviceChange.Removed`](../api/UnityEngine.InputSystem.InputDeviceChange.html) (sent via [`InputSystem.onDeviceChange`](../api/UnityEngine.InputSystem.InputSystem.html#UnityEngine_InputSystem_InputSystem_onDeviceChange)) and the Devices are removed from the [`devices`](../api/UnityEngine.InputSystem.InputSystem.html#UnityEngine_InputSystem_InputSystem_onDeviceChange) list. The system also calls [`InputDevice.OnRemoved`](../api/UnityEngine.InputSystem.InputDevice.html#UnityEngine_InputSystem_InputDevice_OnRemoved_).
+
+The [`InputDevice.added`](../api/UnityEngine.InputSystem.InputDevice.html#UnityEngine_InputSystem_InputDevice_added) flag is reset to false in the process.
+
+Note that Devices are not destroyed when removed. Device instances remain valid and you can still access them in code. However, trying to read values from the controls of these Devices leads to exceptions.
+
+#### Device resets
+
+Resetting a Device resets its Controls to their default state. You can do this manually using [`InputSystem.ResetDevice`](../api/UnityEngine.InputSystem.InputSystem.html#UnityEngine_InputSystem_InputSystem_ResetDevice_UnityEngine_InputSystem_InputDevice_System_Boolean_):
+
+```CSharp
+ InputSystem.ResetDevice(Gamepad.current);
+```
+
+There are two types of resets as determined by the second parameter to [`InputSystem.ResetDevice`](../api/UnityEngine.InputSystem.InputSystem.html#UnityEngine_InputSystem_InputSystem_ResetDevice_UnityEngine_InputSystem_InputDevice_System_Boolean_):
+
+|Type|Description|
+|----|-----------|
+|"Soft" Resets|This is the default. With this type, only controls that are *not* marked as [`dontReset`](layouts.md#control-items) are reset to their default value. This excludes controls such as [`Pointer.position`](../api/UnityEngine.InputSystem.Pointer.html#UnityEngine_InputSystem_Pointer_position) from resets and thus prevents mouse positions resetting to `(0,0)`.|
+|"Hard" Resets|In this type, *all* controls are reset to their default value regardless of whether they have [`dontReset`](layouts.md#control-items) set or not.|
+
+Resetting Controls this way is visible on [Actions](actions.md). If you reset a Device that is currently driving one or more Action, the Actions are cancelled. This cancellation is different from sending an event with default state. Whereas the latter may inadvertently [perform](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_performed) Actions (e.g. a button that was pressed would not appear to have been released), a reset will force clean cancellation.
+
+Resets may be triggered automatically by the Input System depending on [application focus](#background-and-focus-change-behavior).
+
+#### Device syncs
+
+A Device may be requested to send an event with its current state through [`RequestSyncCommand`](../api/UnityEngine.InputSystem.LowLevel.RequestSyncCommand.html). It depends on the platform and type of Device whether this is supported or not.
+
+A synchronization request can be explicitly sent using [`InputSystem.TrySyncDevice`](../api/UnityEngine.InputSystem.InputSystem.html#UnityEngine_InputSystem_InputSystem_TrySyncDevice_UnityEngine_InputSystem_InputDevice_). If the device supports sync requests, the method returns true and an [`InputEvent`](../api/UnityEngine.InputSystem.LowLevel.InputEvent.html) will have been queued on the device for processing in the next [update](../api/UnityEngine.InputSystem.InputSystem.html#UnityEngine_InputSystem_InputSystem_Update_).
+
+Synchronization requests are also automatically sent by the Input System in certain situations. See [Background and focus change behavior](#background-and-focus-change-behavior) for more details.
+
+#### Device enabling and disabling
+
+When a Device is added, the Input System sends it an initial [`QueryEnabledStateCommand`](../api/UnityEngine.InputSystem.LowLevel.QueryEnabledStateCommand.html) to find out whether the device is currently enabled or not. The result of this is reflected in the [`InputDevice.enabled`](../api/UnityEngine.InputSystem.InputDevice.html#UnityEngine_InputSystem_InputDevice_enabled) property.
+
+When disabled, no events other than removal ([`DeviceRemoveEvent`](../api/UnityEngine.InputSystem.LowLevel.DeviceRemoveEvent.html)) and configuration change ([`DeviceConfigurationEvent`](../api/UnityEngine.InputSystem.LowLevel.DeviceConfigurationEvent.html)) events are processed for a Device, even if they are sent.
+
+A Device can be manually disabled and re-enabled via [`InputSystem.DisableDevice`](../api/UnityEngine.InputSystem.InputSystem.html#UnityEngine_InputSystem_InputSystem_DisableDevice_) and [`InputSystem.EnableDevice`](../api/UnityEngine.InputSystem.InputSystem.html#UnityEngine_InputSystem_InputSystem_EnableDevice_) respectively.
+
+Note that [sensors](Sensors.md) start in a disabled state by default, and you need to enable them in order for them to generate events.
+
+The Input System may automatically disable and re-enable Devices in certain situations, as detailed in the [next section](#background-and-focus-change-behavior).
+
+#### Background and focus change behavior
+
+In general, input is tied to [application focus](https://docs.unity3d.com/ScriptReference/Application-isFocused.html). This means that Devices do not receive input while the application is not in the foreground and thus no [Actions](actions.md) will receive input either. When the application comes back into focus, all devices will receive a [sync](#device-syncs) request to have them send their current state (which may have changed while the application was in the background) to the application. Devices that do not support sync requests will see a [soft reset](#device-resets) that resets all Controls not marked as [`dontReset`](layouts.md#control-items) to their default state.
+
+On platforms such as iOS and Android, that do not support running Unity applications in the background, this is the only supported behavior.
+
+If the application is configured to run while in the background (that is, not having focus), input behavior can be selected from several options. This is supported in two scenarios:
+
+* In Unity's [Player Settings](https://docs.unity3d.com/Manual/class-PlayerSettings.html) you can explicity enable `Run In Background` for specific players that support it (such as Windows or Mac standalone players). Note that in these players this setting is always enabled automatically in *development* players.
+* In the editor, application focus is tied to focus on the Game View. If no Game View is focused, the application is considered to be running in the background. However, while in play mode, the editor will *always* keep running the player loop regardless of focus on the Game View window. This means that in the editor, `Run In Background` is considered to always be enabled.
+
+If the application is configured this way to keep running while in the background, the player loop and thus the Input System, too, will keep running even when the application does not have focus. What happens with respect to input then depends on two factors:
+
+1. On the ability of individual devices to receive input while the application is not running in the foreground. This is only supported by a small subset of devices and platforms. VR devices ([`TrackedDevice`](../api/UnityEngine.InputSystem.TrackedDevice.html)) such as HMDs and VR controllers generally support this.`](../api/UnityEngine.InputSystem.InputDevice.html#UnityEngine_InputSystem_InputDevice_ExecuteCommand__1___0__). To monitor Device commands, use [`InputSystem.onDeviceCommand`](../api/UnityEngine.InputSystem.InputSystem.html#UnityEngine_InputSystem_InputSystem_onDeviceCommand).
+
+Each Device command implements the [`IInputDeviceCommandInfo`](../api/UnityEngine.InputSystem.LowLevel.IInputDeviceCommandInfo.html) interface, which only requires the [`typeStatic`](../api/UnityEngine.InputSystem.LowLevel.IInputDeviceCommandInfo.html#UnityEngine_InputSystem_LowLevel_IInputDeviceCommandInfo_typeStatic) property to identify the type of the command. The native implementation of the Device should then understand how to handle that command. One common case is the `"HIDO"` command type which is used to send [HID output reports](HID.md#hid-output) to HIDs.
+
+### Adding custom device Commands
+
+To create custom Device commands (for example, to support some functionality for a specific HID), create a `struct` that contains all the data to be sent to the Device, and add a [`typeStatic`](../api/UnityEngine.InputSystem.LowLevel.IInputDeviceCommandInfo.html#UnityEngine_InputSystem_LowLevel_IInputDeviceCommandInfo_typeStatic) property to make that struct implement the [`IInputDeviceCommandInfo`](../api/UnityEngine.InputSystem.LowLevel.IInputDeviceCommandInfo.html) interface. To send data to a HID, this property should return `"HIDO"`.
+
+You can then create an instance of this struct and populate all its fields, then use [`InputDevice.ExecuteCommand`](../api/UnityEngine.InputSystem.InputDevice.html#UnityEngine_InputSystem_InputDevice_ExecuteCommand__1___0__) to send it to the Device. The data layout of the struct must match the native representation of the data as the device interprets it.
+
+## Device state
+
+Like any other type of [Control](Controls.md#control-state), each Device has a block of memory allocated to it which stores the state of all the Controls associated with the Device.
+
+### State changes
+
+State changes are usually initiated through [state events](Events.md#state-events) from the native backend, but you can use [`InputControl<>.WriteValueIntoState()`](../api/UnityEngine.InputSystem.InputControl-1.html#UnityEngine_InputSystem_InputControl_1_WriteValueIntoState__0_System_Void__) to manually overwrite the state of any Control.
+
+#### Monitoring state changes
+
+You can use [`InputState.AddChangeMonitor()`](../api/UnityEngine.InputSystem.LowLevel.InputState.html#UnityEngine_InputSystem_LowLevel_InputState_AddChangeMonitor_UnityEngine_InputSystem_InputControl_System_Action_UnityEngine_InputSystem_InputControl_System_Double_UnityEngine_InputSystem_LowLevel_InputEventPtr_System_Int64__System_Int32_System_Action_UnityEngine_InputSystem_InputControl_System_Double_System_Int64_System_Int32__) to register a callback to be called whenever the state of a Control changes. The Input System uses the same mechanism to implement [input Actions](actions.md).
+
+#### Synthesizing state
+
+The Input System can synthesize a new state from an existing state. An example of such a synthesized state is the [`press`](../api/UnityEngine.InputSystem.Pointer.html#UnityEngine_InputSystem_Pointer_press) button Control that [`Touchscreen`](../api/UnityEngine.InputSystem.Touchscreen.html) inherits from [`Pointer`](../api/UnityEngine.InputSystem.Pointer.html). Unlike a mouse, which has a physical button, for [`Touchscreen`](../api/UnityEngine.InputSystem.Touchscreen.html) this is a [synthetic Control](Controls.md#synthetic-controls) that doesn't correspond to actual data coming in from the Device backend. Instead, the Input System considers the button to be pressed if any touch is currently ongoing, and released otherwise.
+
+To do this, the Input System uses [`InputState.Change`](../api/UnityEngine.InputSystem.LowLevel.InputState.html#UnityEngine_InputSystem_LowLevel_InputState_Change__1_UnityEngine_InputSystem_InputControl___0_UnityEngine_InputSystem_LowLevel_InputUpdateType_UnityEngine_InputSystem_LowLevel_InputEventPtr_), which allows feeding arbitrary state changes into the system without having to run them through the input event queue. The Input System incorporates state changes directly and synchronously. State change [monitors](#monitoring-state-changes) still trigger as expected.
+
+## Working with Devices
+
+### Monitoring Devices
+
+To be notified when new Devices are added or existing Devices are removed, use [`InputSystem.onDeviceChange`](../api/UnityEngine.InputSystem.InputSystem.html#UnityEngine_InputSystem_InputSystem_onDeviceChange).
+
+```CSharp
+InputSystem.onDeviceChange +=
+ (device, change) =>
+ {
+ switch (change)
+ {
+ case InputDeviceChange.Added:
+ // New Device.
+ break;
+ case InputDeviceChange.Disconnected:
+ // Device got unplugged.
+ break;
+ case InputDeviceChange.Connected:
+ // Plugged back in.
+ break;
+ case InputDeviceChange.Removed:
+ // Remove from Input System entirely; by default, Devices stay in the system once discovered.
+ break;
+ default:
+ // See InputDeviceChange reference for other event types.
+ break;
+ }
+ }
+```
+
+[`InputSystem.onDeviceChange`](../api/UnityEngine.InputSystem.InputSystem.html#UnityEngine_InputSystem_InputSystem_onDeviceChange) delivers notifications for other device-related changes as well. See the [`InputDeviceChange` enum](../api/UnityEngine.InputSystem.InputDeviceChange.html) for more information.
+
+### Adding and removing Devices
+
+To manually add and remove Devices through the API, use [`InputSystem.AddDevice()`](../api/UnityEngine.InputSystem.InputSystem.html#UnityEngine_InputSystem_InputSystem_AddDevice_UnityEngine_InputSystem_InputDevice_) and [`InputSystem.RemoveDevice()`](../api/UnityEngine.InputSystem.InputSystem.html#UnityEngine_InputSystem_InputSystem_RemoveDevice_UnityEngine_InputSystem_InputDevice_).
+
+This allows you to create your own Devices, which can be useful for testing purposes, or for creating virtual Input Devices which synthesize input from other events. As an example, see the [on-screen Controls](OnScreen.md) that the Input System provides. The Input Devices used for on-screen Controls are created entirely in code and have no [native representation](#native-devices).
+
+### Creating custom Devices
+
+>__Note__: This example deals only with Devices that have fixed layouts (that is, you know the specific model or models that you want to implement). This is different from an interface such as HID, where Devices can describe themselves through the interface and take on a wide variety of forms. A fixed Device layout can't cover self-describing Devices, so you need to use a [layout builder](layouts.md#generated-layouts) to build Device layouts from information you obtain at runtime.
+
+There are two main situations in which you might need to create a custom Device:
+
+1. You have an existing API that generates input, and which you want to reflect into the Input System.
+2. You have an HID that the Input System ignores, or that the Input system auto-generates a layout for that doesn't work well enough for your needs.
+
+For the second scenario, see [Overriding the HID Fallback](HID.md#creating-a-custom-device-layout).
+
+The steps below deal with the first scenario, where you want to create a new Input Device entirely from scratch and provide input to it from a third-party API.
+
+#### Step 1: The state struct
+
+The first step is to create a C# `struct` that represents the form in which the system receives and stores input, and also describes the `InputControl` instances that the Input System must create for the Device in order to retrieve its state.
+
+```CSharp
+// A "state struct" describes the memory format that a Device uses. Each Device can
+// receive and store memory in its custom format. InputControls then connect to
+// the individual pieces of memory and read out values from them.
+//
+// If it's important for the memory format to match 1:1 at the binary level
+// to an external representation, it's generally advisable to use
+// LayoutLind.Explicit.
+[StructLayout(LayoutKind.Explicit, Size = 32)]
+public struct MyDeviceState : IInputStateTypeInfo
+{
+ // You must tag every state with a FourCC code for type
+ // checking. The characters can be anything. Choose something that allows
+ // you to easily recognize memory that belongs to your own Device.
+ public FourCC format => new FourCC('M', 'Y', 'D', 'V');
+
+ // InputControlAttributes on fields tell the Input System to create Controls
+ // for the public fields found in the struct.
+
+ // Assume a 16bit field of buttons. Create one button that is tied to
+ // bit #3 (zero-based). Note that buttons don't need to be stored as bits.
+ // They can also be stored as floats or shorts, for example. The
+ // InputControlAttribute.format property determines which format the
+ // data is stored in. If omitted, the system generally infers it from the value
+ // type of the field.
+ [InputControl(name = "button", layout = "Button", bit = 3)]
+ public ushort buttons;
+
+ // Create a floating-point axis. If a name is not supplied, it is taken
+ // from the field.
+ [InputControl(layout = "Axis")]
+ public short axis;
+}
+```
+
+The Input System's layout mechanism uses [`InputControlAttribute`](../api/UnityEngine.InputSystem.Layouts.InputControlAttribute.html) annotations to add Controls to the layout of your Device. For details, see the [layout system](layouts.md) documentation.
+
+With the state struct in place, you now have a way to send input data to the Input System and store it there. The next thing you need is an [`InputDevice`](../api/UnityEngine.InputSystem.InputDevice.html) that uses your custom state struct and represents your custom Device.
+
+#### Step 2: The Device class
+
+Next, you need a class derived from one of the [`InputDevice`](../api/UnityEngine.InputSystem.InputDevice.html) base classes. You can either base your Device directly on [`InputDevice`](../api/UnityEngine.InputSystem.InputDevice.html), or you can pick a more specific Device type, like [`Gamepad`](../api/UnityEngine.InputSystem.Gamepad.html).
+
+This example assumes that your Device doesn't fit into any of the existing Device classes, so it derives directly from [`InputDevice`](../api/UnityEngine.InputSystem.InputDevice.html).
+
+```CSharp
+// InputControlLayoutAttribute attribute is only necessary if you want
+// to override the default behavior that occurs when you register your Device
+// as a layout.
+// The most common use of InputControlLayoutAttribute is to direct the system
+// to a custom "state struct" through the `stateType` property. See below for details.
+[InputControlLayout(displayName = "My Device", stateType = typeof(MyDeviceState))]
+public class MyDevice : InputDevice
+{
+ // In the state struct, you added two Controls that you now want to
+ // surface on the Device, for convenience. The Controls
+ // get added to the Device either way. When you expose them as properties,
+ // it is easier to get to the Controls in code.
+
+ public ButtonControl button { get; private set; }
+ public AxisControl axis { get; private set; }
+
+ // The Input System calls this method after it constructs the Device,
+ // but before it adds the device to the system. Do any last-minute setup
+ // here.
+ protected override void FinishSetup()
+ {
+ base.FinishSetup();
+
+ // NOTE: The Input System creates the Controls automatically.
+ // This is why don't do `new` here but rather just look
+ // the Controls up.
+ button = GetChildControl("button");
+ axis = GetChildControl("axis");
+ }
+}
+```
+
+#### Step 3: The Update method
+
+You now have a Device in place along with its associated state format. You can call the following method to create a fully set-up Device with your two Controls on it:
+
+```CSharp
+InputSystem.AddDevice();
+```
+
+However, this Device doesn't receive input yet, because you haven't added any code that generates input. To do that, you can use [`InputSystem.QueueStateEvent`](../api/UnityEngine.InputSystem.InputSystem.html#UnityEngine_InputSystem_InputSystem_QueueStateEvent__1_UnityEngine_InputSystem_InputDevice___0_System_Double_) or [`InputSystem.QueueDeltaStateEvent`](../api/UnityEngine.InputSystem.InputSystem.html#UnityEngine_InputSystem_InputSystem_QueueDeltaStateEvent__1_UnityEngine_InputSystem_InputControl___0_System_Double_) from anywhere, including from a thread. The following example uses [`IInputUpdateCallbackReceiver`](../api/UnityEngine.InputSystem.LowLevel.IInputUpdateCallbackReceiver.html), which, when implemented by any [`InputDevice`](../api/UnityEngine.InputSystem.InputDevice.html), adds an [`OnUpdate()`](../api/UnityEngine.InputSystem.LowLevel.IInputUpdateCallbackReceiver.html#UnityEngine_InputSystem_LowLevel_IInputUpdateCallbackReceiver_OnUpdate) method that automatically gets called during [`InputSystem.onBeforeUpdate`](../api/UnityEngine.InputSystem.InputSystem.html#UnityEngine_InputSystem_InputSystem_onBeforeUpdate) and provides input events to the current input update.
+
+>__Note__: If you already have a place where input for your device becomes available, you can skip this step and queue input events from there instead of using [`IInputUpdateCallbackReceiver`](../api/UnityEngine.InputSystem.LowLevel.IInputUpdateCallbackReceiver.html).
+
+```CSharp
+public class MyDevice : InputDevice, IInputUpdateCallbackReceiver
+{
+ //...
+
+ public void OnUpdate()
+ {
+ // In practice, this would read out data from an external
+ // API. This example uses some empty input.
+ var state = new MyDeviceState();
+ InputSystem.QueueStateEvent(this, state);
+ }
+}
+```
+
+#### Step 4: Device registration and creation
+
+You now have a functioning device, but you haven't registered it (added it to the system) yet. This means you can't see the device when, for example, you create bindings in the [Action editor](ActionAssets.md#editing-input-action-assets).
+
+You can register your device type with the system from within the code that runs automatically as part of Unity's startup. To do so, modify the definition of `MyDevice` like so:
+
+```CSharp
+// Add the InitializeOnLoad attribute to automatically run the static
+// constructor of the class after each C# domain load.
+#if UNITY_EDITOR
+[InitializeOnLoad]
+#endif
+public class MyDevice : InputDevice, IInputUpdateCallbackReceiver
+{
+ //...
+
+ static MyDevice()
+ {
+ // RegisterLayout() adds a "Control layout" to the system.
+ // These can be layouts for individual Controls (like sticks)
+ // or layouts for entire Devices (which are themselves
+ // Controls) like in our case.
+ InputSystem.RegisterLayout();
+ }
+
+ // You still need a way to trigger execution of the static constructor
+ // in the Player. To do this, you can add the RuntimeInitializeOnLoadMethod
+ // to an empty method.
+ [RuntimeInitializeOnLoadMethod(RuntimeInitializeLoadType.BeforeSceneLoad)]
+ private static void InitializeInPlayer() {}
+}
+```
+
+This registers the Device type with the system and makes it available in the Control picker. However, you still need a way to add an instance of the Device when it is connected.
+
+In theory, you could call [`InputSystem.AddDevice()`](../api/UnityEngine.InputSystem.InputSystem.html#UnityEngine_InputSystem_InputSystem_AddDevice__1_System_String_) somewhere, but in a real-world setup you likely have to correlate the Input Devices you create with their identities in the third-party API.
+
+It might be tempting to do something like this:
+
+```CSharp
+public class MyDevice : InputDevice, IInputUpdateCallbackReceiver
+{
+ //...
+
+ // This does NOT work correctly.
+ public ThirdPartyAPI.DeviceId externalId { get; set; }
+}
+```
+
+and then set that on the Device after calling [`AddDevice`](../api/UnityEngine.InputSystem.InputSystem.html#UnityEngine_InputSystem_InputSystem_AddDevice__1_System_String_). However, this doesn't work as expected in the Editor, because the Input System requires Devices to be created solely from their [`InputDeviceDescription`](../api/UnityEngine.InputSystem.Layouts.InputDeviceDescription.html) in combination with the chosen layout (and layout variant). In addition, the system supports a fixed set of mutable per-device properties such as device usages (that is, [`InputSystem.SetDeviceUsage()`](../api/UnityEngine.InputSystem.InputSystem.html#UnityEngine_InputSystem_InputSystem_SetDeviceUsage_UnityEngine_InputSystem_InputDevice_System_String_) and related methods). This allows the system to easily recreate Devices after domain reloads in the Editor, as well as to create replicas of remote Devices when connecting to a Player. To comply with this requirement, you must cast that information provided by the third-party API into an [`InputDeviceDescription`](../api/UnityEngine.InputSystem.Layouts.InputDeviceDescription.html) and then use an [`InputDeviceMatcher`](../api/UnityEngine.InputSystem.Layouts.InputDeviceMatcher.html) to match the description to our custom `MyDevice` layout.
+
+This example assumes that the third-party API has two callbacks, like this:
+
+```CSharp
+public static ThirdPartyAPI
+{
+ // This example assumes that the argument is a string that
+ // contains the name of the Device, and that no two Devices
+ // have the same name in the external API.
+ public static Action deviceAdded;
+ public static Action deviceRemoved;
+}
+```
+
+You can hook into those callbacks and create and destroy devices in response.
+
+```CSharp
+// This example uses a MonoBehaviour with [ExecuteInEditMode]
+// on it to run the setup code. You can do this many other ways.
+[ExecuteInEditMode]
+public class MyDeviceSupport : MonoBehaviour
+{
+ protected void OnEnable()
+ {
+ ThirdPartyAPI.deviceAdded += OnDeviceAdded;
+ ThirdPartyAPI.deviceRemoved += OnDeviceRemoved;
+ }
+
+ protected void OnDisable()
+ {
+ ThirdPartyAPI.deviceAdded -= OnDeviceAdded;
+ ThirdPartyAPI.deviceRemoved -= OnDeviceRemoved;
+ }
+
+ private void OnDeviceAdded(string name)
+ {
+ // Feed a description of the Device into the system. In response, the
+ // system matches it to the layouts it has and creates a Device.
+ InputSystem.AddDevice(
+ new InputDeviceDescription
+ {
+ interfaceName = "ThirdPartyAPI",
+ product = name
+ });
+ }
+
+ private void OnDeviceRemoved(string name)
+ {
+ var device = InputSystem.devices.FirstOrDefault(
+ x => x.description == new InputDeviceDescription
+ {
+ interfaceName = "ThirdPartyAPI",
+ product = name,
+ });
+
+ if (device != null)
+ InputSystem.RemoveDevice(device);
+ }
+
+ // Move the registration of MyDevice from the
+ // static constructor to here, and change the
+ // registration to also supply a matcher.
+ protected void Awake()
+ {
+ // Add a match that catches any Input Device that reports its
+ // interface as "ThirdPartyAPI".
+ InputSystem.RegisterLayout(
+ matches: new InputDeviceMatcher()
+ .WithInterface("ThirdPartyAPI"));
+ }
+}
+```
+
+#### Step 5: `current` and `all` (optional)
+
+For convenience, you can quickly access the last used device of a given type, or list all devices of a specific type. To do this, add support for a `current` and for an `all` getter to the API of `MyDevice`.
+
+```CSharp
+public class MyDevice : InputDevice, IInputCallbackReceiver
+{
+ //...
+
+ public static MyDevice current { get; private set; }
+
+ public static IReadOnlyList all => s_AllMyDevices;
+ private static List s_AllMyDevices = new List();
+
+ public override void MakeCurrent()
+ {
+ base.MakeCurrent();
+ current = this;
+ }
+
+ protected override void OnAdded()
+ {
+ base.OnAdded();
+ s_AllMyDevices.Add(this);
+ }
+
+ protected override void OnRemoved()
+ {
+ base.OnRemoved();
+ s_AllMyDevices.Remove(this);
+ }
+}
+```
+
+#### Step 6: Device Commands (Optional)
+
+A final, but optional, step is to add support for Device commands. A "device command" is that opposite of input. In other words, it consists of data traveling __to__ the input device, which might also return data as part of the operation (much like a function call). You can use this to communicate with the backend of the device in order to query configuration, or to initiate effects such as haptics. At the moment there isn't a proper interface available for this, however there are still some scenarios that can be solved with the current interfaces.
+
+E.g. the following shows, when implementing a non-hardware-backed device (simulated device), how to simulate hardware reporting that the device can be run in the background and supports sync commands. This is useful to prevent the device from cancelling Actions when application focus is lost and restored. For more info see [Device syncs](#device-syncs)
+
+```CSharp
+public class MyDevice : InputDevice, IInputCallbackReceiver
+{
+ //...
+
+ protected override unsafe long ExecuteCommand(InputDeviceCommand* commandPtr)
+ {
+ var type = commandPtr->type;
+ if (type == RequestSyncCommand.Type)
+ {
+ // Report that the device supports the sync command and has handled it.
+ // This will prevent device reset during focus changes.
+ result = InputDeviceCommand.GenericSuccess;
+ return true;
+ }
+
+ if (type == QueryCanRunInBackground.Type)
+ {
+ // Notify that the device supports running in the background.
+ ((QueryCanRunInBackground*)commandPtr)->canRunInBackground = true;
+ result = InputDeviceCommand.GenericSuccess;
+ return true;
+ }
+
+ result = default;
+ return false;
+ }
+}
+```
diff --git a/Packages/com.unity.inputsystem/Documentation~/devices-domain-reloads.md b/Packages/com.unity.inputsystem/Documentation~/devices-domain-reloads.md
new file mode 100644
index 0000000000..e6d337f8aa
--- /dev/null
+++ b/Packages/com.unity.inputsystem/Documentation~/devices-domain-reloads.md
@@ -0,0 +1 @@
+# Devices and domain reloads
diff --git a/Packages/com.unity.inputsystem/Documentation~/devices-scripting.md b/Packages/com.unity.inputsystem/Documentation~/devices-scripting.md
new file mode 100644
index 0000000000..5e82de610b
--- /dev/null
+++ b/Packages/com.unity.inputsystem/Documentation~/devices-scripting.md
@@ -0,0 +1 @@
+# Devices (scripting)
diff --git a/Packages/com.unity.inputsystem/Documentation~/display-bindings.md b/Packages/com.unity.inputsystem/Documentation~/display-bindings.md
new file mode 100644
index 0000000000..530627415f
--- /dev/null
+++ b/Packages/com.unity.inputsystem/Documentation~/display-bindings.md
@@ -0,0 +1,65 @@
+### Displaying Bindings
+
+It can be useful for the user to know what an Action is currently bound to (taking any potentially active rebindings into account) while rebinding UIs, and for on-screen hints while the app is running. You can use [`InputBinding.effectivePath`](../api/UnityEngine.InputSystem.InputBinding.html#UnityEngine_InputSystem_InputBinding_effectivePath) to get the currently active path for a Binding (which returns [`overridePath`](../api/UnityEngine.InputSystem.InputBinding.html#UnityEngine_InputSystem_InputBinding_overridePath) if set, or otherwise returns [`path`](../api/UnityEngine.InputSystem.InputBinding.html#UnityEngine_InputSystem_InputBinding_path)).
+
+The easiest way to retrieve a display string for an action is to call [`InputActionRebindingExtensions.GetBindingDisplayString`](../api/UnityEngine.InputSystem.InputActionRebindingExtensions.html#UnityEngine_InputSystem_InputActionRebindingExtensions_GetBindingDisplayString_) which is an extension method for [`InputAction`](../api/UnityEngine.InputSystem.InputAction.html).
+
+```CSharp
+ // Get a binding string for the action as a whole. This takes into account which
+ // bindings are currently active and the actual controls bound to the action.
+ m_RebindButton.GetComponentInChildren().text = action.GetBindingDisplayString();
+
+ // Get a binding string for a specific binding on an action by index.
+ m_RebindButton.GetComponentInChildren