# Mock Runtime 0.0.2

OpenXR Runtime that allows for testing without a device.

## Paths

The `XrPath` handles generated by the Mock Runtime are a combination of two identifiers with the high 32-bits being the component path and the low 32-bits being the user path.  This allows for quick comparisons of portions of the path and isolates the parsing of the path to the `xrStringToPath` method.  The `GetUserPath` and `GetComponentPath` methods can be used to extract the individual parts of the `XrPath`.

## Interaction Profiles

The list of all interaction profiles supported by the mock runtime can be found in `mock_runtime_interaction_profiles.cpp`.  This list is 1.0 conformant and will be used to create a list of `MockInteractionProfile` instances in the Mock Runtime as well as generate the list of all [Input State](#input-state) instances.

## Action Sets

Action sets within the Mock Runtime are stored in a list within the runtime state.  The `XrActionSet` handle returned from `CreateActionSet` contains the index of the action set into the action set list. To convert a `XrActionSet` handle into a `MockActionSet` use the `GetMockActionSet` method within the runtime.

## Actions

The Mock Runtime implements conformant action support.  Since the Mock Runtime does not have any actual controllers it will instead mimic the first interaction profile it receives through suggested bindings.  This means that no actions will have bindings until bindings are suggested and that `xrGetCurrentInteractionProfile` will return the first interaction profile encountered by `xrSuggestInteractionProfileBindings`. When `xrSuggestInteractionProfileBindings` is called the actions are bound to known [Input State](#input-state) which allows those values to be directly controlled via the conformance automation extension.

The `XrAction` handle generated by `CreateAction` is a combination of the action set index (low 32-bits) that the action belongs to and the action index within the parent action set (high 32-bits).  Since actions are stored as children of an action set this handle format allows an action to be found quickly without any indirect lookups.  The methods `GetMockActionSet` and `GetMockAction` will convert an `XrAction` handle in to an `MockActionSet` and `MockAction` respectively.

## Input State

The MockRuntime manages a list of input states, one for each combination of interaction profile, user path, and input source path.  These input states have an `XrActionType` to define the type of data they represent, which is defined by their interaction profile.  This allows the Mock Runtime to allow binding to any input source on any known interaction profile.  However this does mean that there may be multiple instances of a input source (ex. `/input/grip` may exist multiple times, for each interaction profile).  The side effect of this design is that if you bind multiple interaction profiles to the same action then there will be two sources of data for that action and the [OpenXR Specification](https://www.khronos.org/registry/OpenXR/specs/1.0/html/xrspec.html#multiple_inputs) on how to resolve which to use will be applied.

## Conformance Automation Extension

The MockRuntime implements the conformance automation extension and allows [Input State](#input-state) values to be set.  When a value is set via Conformance Automation it is temporarly stored in the extension itself rather than directly settings the equivalent value in Mock Runtime.  The values stored in the extension will then be read by the MockRuntime during `xrSyncActions` and copied into the runtime state where they will persist.