// Copyright (c) 2016-2024, The Khronos Group Inc.
//
// SPDX-License-Identifier: CC-BY-4.0
[[semantic-paths]]
== Path Tree and Semantic Paths

OpenXR incorporates an internal _semantic path tree_ model, also known as
the _path tree_, with entities associated with nodes organized in a logical
tree and referenced by path name strings structured like a filesystem path
or URL.
The path tree unifies a number of concepts used in this specification and a
runtime may: add additional nodes as implementation details.
As a general design principle, the most application-facing paths should:
have semantic and hierarchical meaning in their name.
Thus, these paths are often referred to as _semantic paths_.
However, path names in the path tree model may: not all have the same level
or kind of semantic meaning.

In regular use in an application, path name strings are converted to
instance-specific basetype:XrPath values which are used in place of path
strings.
The mapping between basetype:XrPath values and their corresponding path name
strings may: be considered to be tracked by the runtime in a one-to-one
mapping in addition to the natural tree structure of the referenced
entities.
Runtimes may: use any internal implementation that satisfies the
requirements.

Formally, the runtime maintains an instance-specific bijective mapping
between well-formed path name strings and valid basetype:XrPath
(code:uint64_t) values.
These basetype:XrPath values are only valid within a single
slink:XrInstance, and applications must: not share these values between
instances.
Applications must: instead use the string representation of a path in their
code and configuration, and obtain the correct corresponding basetype:XrPath
at runtime in each slink:XrInstance.
The term _path_ or _semantic path_ may: refer interchangeably to either the
path name string or its associated basetype:XrPath value within an instance
when context makes it clear which type is being discussed.

Given that path trees are a unifying model in this specification, the
entities referenced by paths can: be of diverse types.
For example, they may: be used to represent physical device or sensor
_components_, which may: be of various _component types_.
They may: also be used to represent frames of reference that are understood
by the application and the runtime, as defined by an slink:XrSpace.
Additionally, to permit runtime re-configuration and support
hardware-independent development, any syntactically-valid path string may:
be used to retrieve a corresponding basetype:XrPath without error given
sufficient resources, _even if_ no logical or hardware entity currently
corresponds to that path at the time of the call.
Later retrieval of the associated path string of such an basetype:XrPath
using flink:xrPathToString should: succeed if the other requirements of that
call are met.
However, using such an basetype:XrPath in a later call to any other API
function may: result in an error if no entity of the type required by the
call is available at the path at that later time.
A runtime should: permit the entity referenced by a path to vary over time
to naturally reflect varying system configuration and hardware availability.

[[semantic-paths-path-atom-type]]
=== Path Atom Type

[open,refpage='XrPath',desc='A semantic path',type='basetypes',xrefs='XR_NULL_PATH']
--
include::{generated}/api/basetypes/XrPath.adoc[]

The basetype:XrPath is an atom that connects an application with a single
path, within the context of a single instance.
There is a bijective mapping between well-formed path strings and atoms in
use.
This atom is used -- in place of the path name string it corresponds to --
to retrieve state and perform other operations.

As an basetype:XrPath is only shorthand for a well-formed path string, they
have no explicit life cycle.

Lifetime is implicitly managed by the slink:XrInstance.
An basetype:XrPath must: not be used unless it is received at execution time
from the runtime in the context of a particular slink:XrInstance.
Therefore, with the exception of dlink:XR_NULL_PATH, basetype:XrPath values
must: not be specified as constant values in applications: the corresponding
path string should: be used instead.
During the lifetime of a given slink:XrInstance, the basetype:XrPath
associated with that instance with any given well-formed path must: not
vary, and similarly the well-formed path string that corresponds to a given
basetype:XrPath in that instance must: not vary.
An basetype:XrPath that is received from one slink:XrInstance may: not be
used with another.
Such an invalid use may: be detected and result in an error being returned,
or it may: result in undefined behavior.
--

Well-written applications should: typically use a small, bounded set of
paths in practice.
However, the runtime should: support looking up the basetype:XrPath for a
large number of path strings for maximum compatibility.
Runtime implementers should: keep in mind that applications supporting
diverse systems may: look up path strings in a quantity exceeding the number
of non-empty entities predicted or provided by any one runtime's own path
tree model, and this is not inherently an error.
However, system resources are finite and thus runtimes may: signal
exhaustion of resources dedicated to these associations under certain
conditions.

When discussing the behavior of runtimes at these limits, a _new_
basetype:XrPath refers to an basetype:XrPath value that, as of some point in
time, has neither been received by the application nor tracked internally by
the runtime.
In this case, since an application has not yet received the value of such an
basetype:XrPath, the runtime has not yet made any assertions about its
association with any path string.
In this context, _new_ only refers to the fact that the mapping has not
necessarily been made constant for a given value/path string pair for the
remaining life of the associated instance by being revealed to the
application.
It does not necessarily imply creation of the entity, if any, referred to by
such a path.
Similarly, it does not imply the absence of such an entity prior to that
point.
Entities in the path tree have varied lifetime that is independent from the
duration of the mapping from path string to basetype:XrPath.

For flexibility, the runtime may: internally track or otherwise make
constant, in instance or larger scope, any mapping of a path string to an
basetype:XrPath value even before an application would otherwise receive
that value, thus making it no longer _new_ by the above definition.

When the runtime's resources to track the path string-basetype:XrPath
mapping are exhausted, and the application makes an API call that would have
otherwise retrieved a _new_ basetype:XrPath as defined above, the runtime
must: return ename:XR_ERROR_PATH_COUNT_EXCEEDED.
This includes both explicit calls to flink:xrStringToPath as well as other
calls that retrieve an basetype:XrPath in any other way.

The runtime should: support creating as many paths as memory will allow and
must: return ename:XR_ERROR_PATH_COUNT_EXCEEDED from relevant functions when
no more can be created.

[open,refpage='XR_NULL_PATH',desc='A NULL semantic path',type='defines',xrefs='XrPath']
--
include::{generated}/api/defines/XR_NULL_PATH.adoc[]

The only basetype:XrPath value defined to be constant across all instances
is the invalid path dlink:XR_NULL_PATH.
No well-formed path string is associated with dlink:XR_NULL_PATH.
Unless explicitly permitted, it should: not be passed to API calls or used
as a structure attribute when a valid basetype:XrPath is required.
--

[[semantic-paths-well-formed]]
=== Well-Formed Path Strings

Even though they look similar, semantic paths are not file paths.
To avoid confusion with file path directory traversal conventions, many file
path conventions are explicitly disallowed from well-formed path name
strings.

A well-formed path name string must: conform to the following rules:

* Path name strings must: be constructed entirely from characters on the
  following list.
** Lower case ASCII letters: a-z
** Numeric digits: 0-9
** Dash: -
** Underscore: _
** Period: .
** Forward Slash: /
* Path name strings must: start with a single forward slash character.
* Path name strings must: not end with a forward slash character.
* Path name strings must: not contain two or more adjacent forward slash
  characters.
* Path name strings must: not contain two forward slash characters that are
  separated by only period characters.
* Path name strings must: not contain only period characters following the
  final forward slash character in the string.
* The maximum string length for a path name string, including the
  terminating `\0` character, is defined by ename:XR_MAX_PATH_LENGTH.

==== xrStringToPath
[open,refpage='xrStringToPath',desc='Converts a string to a semantic path',type='protos',xrefs='XrPath xrPathToString']
--
The flink:xrStringToPath function is defined as:

include::{generated}/api/protos/xrStringToPath.adoc[]

.Parameter Descriptions
****
* pname:instance is an instance previously created.
* pname:pathString is the path name string to retrieve the associated
  basetype:XrPath for.
* pname:path is the output parameter, which must: point to an
  basetype:XrPath.
  Given a well-formed path name string, this will be populated with an
  opaque value that is constant for that path string during the lifetime of
  that instance.
****

flink:xrStringToPath retrieves the basetype:XrPath value for a well-formed
path string.
If such a value had not yet been assigned by the runtime to the provided
path string in this slink:XrInstance, one must: be assigned at this point.
All calls to this function with the same slink:XrInstance and path string
must: retrieve the same basetype:XrPath value.
Upon failure, flink:xrStringToPath must: return an appropriate
elink:XrResult, and may: set the output parameter to dlink:XR_NULL_PATH.
See <<semantic-paths-path-atom-type>> for the conditions under which an
error may: be returned when this function is given a valid slink:XrInstance
and a well-formed path string.

If the runtime's resources are exhausted and it cannot create the path, a
return value of ename:XR_ERROR_PATH_COUNT_EXCEEDED must: be returned.
If the application specifies a string that is not a well-formed path string,
ename:XR_ERROR_PATH_FORMAT_INVALID must: be returned.

NOTE: A return value of ename:XR_SUCCESS from flink:xrStringToPath may: not
necessarily imply that the runtime has a component or other source of data
that will be accessible through that semantic path.
It only means that the path string supplied was well-formed and that the
retrieved basetype:XrPath maps to the given path string within and during
the lifetime of the slink:XrInstance given.


include::{generated}/validity/protos/xrStringToPath.adoc[]
--
==== xrPathToString

[open,refpage='xrPathToString',desc='Converts a semantic path to a string',type='protos',xrefs='XrPath xrStringToPath']
--
include::{generated}/api/protos/xrPathToString.adoc[]

.Parameter Descriptions
****
* pname:instance is an instance previously created.
* pname:path is the valid basetype:XrPath value to retrieve the path string
  for.
* pname:bufferCapacityInput is the capacity of the buffer, or 0 to indicate
  a request to retrieve the required capacity.
* pname:bufferCountOutput is a pointer to the count of characters written to
  pname:buffer (including the terminating '\0'), or a pointer to the
  required capacity in the case that pname:bufferCapacityInput is
  insufficient.
* pname:buffer is a pointer to an application-allocated buffer that will be
  filled with the semantic path string.
  It can: be code:NULL if pname:bufferCapacityInput is 0.
* See the <<fundamentals-buffer-size-parameters>> section for a detailed
  description of retrieving the required pname:buffer size.
****

flink:xrPathToString retrieves the path name string associated with an
basetype:XrPath, in the context of a given slink:XrInstance, in the form of
a code:NULL terminated string placed into a _caller-allocated_ buffer.
Since the mapping between a well-formed path name string and an
basetype:XrPath is bijective, there will always be exactly one string for
each valid basetype:XrPath value.
This can be useful if the calling application receives an basetype:XrPath
value that they had not previously retrieved via flink:xrStringToPath.
During the lifetime of the given slink:XrInstance, the path name string
retrieved by this function for a given valid basetype:XrPath will not
change.
For invalid paths, including dlink:XR_NULL_PATH, ename:XR_ERROR_PATH_INVALID
must: be returned.


include::{generated}/validity/protos/xrPathToString.adoc[]
--


[[semantic-paths-reserved]]
=== Reserved Paths

In order for some uses of semantic paths to work consistently across
runtimes, it is necessary to standardize several paths and require each
runtime to use the same paths or patterns of paths for certain classes of
usage.
Those paths are as follows.


[[semantic-paths-user]]
==== /user paths

Some paths are used to refer to entities that are filling semantic roles in
the system.
These paths are all under the pathname:/user subtree.

The reserved user paths are:

.Reserved Semantic Paths
****
* pathname:/user/hand/left represents the user's left hand.
  It might be tracked using a controller or other device in the user's left
  hand, or tracked without the user holding anything, e.g. using computer
  vision.
* pathname:/user/hand/right represents the user's right hand in analog to
  the left hand.
* pathname:/user/head represents inputs on the user's head, often from a
  device such as a head-mounted display.
  To reason about the user's head, see the <<spaces-reference-spaces,
  ename:XR_REFERENCE_SPACE_TYPE_VIEW>> reference space.
* pathname:/user/gamepad is a two-handed gamepad device held by the user.
* pathname:/user/treadmill is a treadmill or other locomotion-targeted input
  device.
****

Runtimes are not required to provide interaction at all of these paths.
For instance, in a system with no hand tracking, only pathname:/user/head
would be active for interaction.
In a system with only one controller, the runtime may: provide access to
that controller via either pathname:/user/hand/left or
pathname:/user/hand/right as it deems appropriate.

The runtime may: change the devices referred to by pathname:/user/hand/left
and pathname:/user/hand/right at any time.

If more than two hand-held controllers or devices are active, the runtime
must: determine which two are accessible as pathname:/user/hand/left and
pathname:/user/hand/right.

[[semantic-paths-input]]
==== Input subpaths

Devices on the source side of the input system need to define paths for each
component that can be bound to an action.
This section describes the naming conventions for those input components.
Runtimes must: ignore input source paths that use identifiers and component
names that do not appear in this specification or otherwise do not follow
the pattern specified below.

Each input source path must: match the following pattern:

* subpathname:/input/<identifier>[_<location>][/<component>]

Identifiers are often the label on the component or related to the type and
location of the component.

When specifying a suggested binding there are several cases where the
component part of the path can be determined automatically.
See <<input-suggested-bindings, Suggested Bindings>> for more details.

See <<semantic-paths-interaction-profiles, Interaction Profiles>> for
examples of input subpaths.

[[semantic-paths-standard-identifiers]]
===== Standard identifiers

* trackpad - A 2D input source that usually includes click and touch
  component.
* thumbstick - A small 2D joystick that is meant to be used with the user's
  thumb.
  These sometimes include click and/or touch components.
* joystick - A 2D joystick that is meant to be used with the user's entire
  hand, such as a flight stick.
  These generally do not have click component, but might have touch
  components.
* trigger - A 1D analog input component that returns to a rest state when
  the user stops interacting with it.
  These sometime include touch and/or click components.
* throttle - A 1D analog input component that remains in position when the
  user stops interacting with it.
* trackball - A 2D relative input source.
  These sometimes include click components.
* pedal - A 1D analog input component that is similar to a trigger but meant
  to be operated by a foot
* system - A button with the specialised meaning that it enables the user to
  access system-level functions and UI.
  Input data from system buttons is generally used internally by runtimes
  and may: not be available to applications.
* dpad_up, dpad_down, dpad_left, and dpad_right - A set of buttons arranged
  in a plus shape.
* diamond_up, diamond_down, diamond_left, and diamond_right - Gamepads often
  have a set of four buttons arranged in a diamond shape.
  The labels on those buttons vary from gamepad to gamepad, but their
  arrangement is consistent.
  These names are used for the A/B/X/Y buttons on a Xbox controller, and the
  square/cross/circle/triangle button on a PlayStation controller.
* a, b, x, y, start, home, end, select - Standalone buttons are named for
  their physical labels.
  These are the standard identifiers for such buttons.
  Extensions may: add new identifiers as detailed in the next section.
  Groups of four buttons in a diamond shape should: use the diamond-prefix
  names above instead of using the labels on the buttons themselves.
* volume_up, volume_down, mute_mic, play_pause, menu, view, back - Some
  other standard controls are often identified by icons.
  These are their standard names.
* thumbrest - Some controllers have a place for the user to rest their
  thumb.
* shoulder - A button that is usually pressed with the index finger and is
  often positioned above a trigger.
* squeeze - An input source that indicates that the user is squeezing their
  fist closed.
  This could be a simple button or act more like a trigger.
  Sources with this identifier should: either follow button or trigger
  conventions for their components.
* wheel - A steering wheel.
* thumb_resting_surfaces - Any surfaces that a thumb may naturally rest on.
  This may include, but is not limited to, face buttons, thumbstick, and
  thumbrest (Provided by `XR_VERSION_1_1`)
* stylus - Tip that can be used for writing or drawing.
  May be able to detect various pressure levels (Provided by
  `XR_VERSION_1_1`)
* trigger_curl - This sensor detects how pointed or curled the user's finger
  is on the trigger: 0 = fully pointed, 1 = finger flat on surface (Provided
  by `XR_VERSION_1_1`)
* trigger_slide - This sensor represents how far the user is sliding their
  index finger along the surface of the trigger: 0 = finger flat on the
  surface, 1 = finger fully drawn back (Provided by `XR_VERSION_1_1`)

[[semantic-paths-standard-pose-identifiers]]
===== Standard pose identifiers

Input sources whose orientation and/or position are tracked also expose pose
identifiers.

Standard pose identifiers for tracked hands or motion controllers as
represented by pathname:/user/hand/left and pathname:/user/hand/right are:

image::images/grip_axes_diagram.png[align="center", title="Example grip and aim poses for generic motion controllers"]

[[semantic-paths-grip-pose]]
* grip - A pose that allows applications to reliably render a virtual object
  held in the user's hand, whether it is tracked directly or by a motion
  controller.
  The grip pose is defined as follows:
** The grip position:
*** For tracked hands: The user's palm centroid when closing the fist, at
    the surface of the palm.
*** For handheld motion controllers: A fixed position within the controller
    that generally lines up with the palm centroid when held by a hand in a
    neutral position.
    This position should be adjusted left or right to center the position
    within the controller's grip.
** The grip orientation's +X axis: When you completely open your hand to
   form a flat 5-finger pose, the ray that is normal to the user's palm
   (away from the palm in the left hand, into the palm in the right hand).
** The grip orientation's -Z axis: When you close your hand partially (as if
   holding the controller), the ray that goes through the center of the tube
   formed by your non-thumb fingers, in the direction of little finger to
   thumb.
** The grip orientation's +Y axis: orthogonal to +Z and +X using the
   right-hand rule.

[[semantic-paths-aim-pose]]
* aim - A pose that allows applications to point in the world using the
  input source, according to the platform's conventions for aiming with that
  kind of source.
  The aim pose is defined as follows:
** For tracked hands: The ray that follows platform conventions for how the
   user aims at objects in the world with their entire hand, with +Y up, +X
   to the right, and -Z forward.
   The ray chosen will be runtime-dependent, often a ray emerging from the
   hand at a target pointed by moving the forearm.
** For handheld motion controllers: The ray that follows platform
   conventions for how the user targets objects in the world with the motion
   controller, with +Y up, +X to the right, and -Z forward.
   This is usually for applications that are rendering a model matching the
   physical controller, as an application rendering a virtual object in the
   user's hand likely prefers to point based on the geometry of that virtual
   object.
   The ray chosen will be runtime-dependent, although this will often emerge
   from the frontmost tip of a motion controller.

[[semantic-paths-grip_surface-pose]]
* grip_surface - (Provided by `XR_VERSION_1_1`) A pose that allows
  applications to reliably anchor visual content relative to the user's
  physical hand, whether the user's hand is tracked directly or its position
  and orientation is inferred by a physical controller.
  The grip_surface pose is defined as follows:

** The grip_surface position: The user's physical palm centroid, at the
   surface of the palm.
   For the avoidance of doubt, the palm does not include fingers.
** The grip_surface orientation's +X axis: When a user is holding the
   controller and straightens their index fingers pointing forward, the ray
   that is normal (perpendicular) to the user's palm (away from the palm in
   the left hand, into the palm in the right hand).
** The grip_surface orientation's -Z axis: When a user is holding the
   controller and straightens their index finger, the ray that is parallel
   to their finger's pointing direction.
** The grip_surface orientation's +Y axis: orthogonal to +Z and +X using the
   right-hand rule.

image::images/palm_pose.png[align="center", title="Example grip_surface pose for (from left to right) a generic motion controller, tracked hand, and a digital hand avatar. The X axis is depicted in red. The Y axis is depicted in green. The Z axis is depicted in blue."]

// Linking to the palm pose extension here is a special exception due to its
// effect on existing interaction profiles and its anticipated widespread
// availability. Do not add even conditional links to extensions in this
// chapter normally. If many extensions start to add identifiers,
// we may consider a generated list here from registry markup.
ifdef::XR_EXT_palm_pose[]
[NOTE]
.Note
====
When the apiext:XR_EXT_palm_pose extension is available and enabled, an
additional "palm_ext" standard pose identifier is available, and a path is
added to all interaction profiles valid for pathname:/user/hand/left or
pathname:/user/hand/right.
This includes interaction profiles defined in the core spec and in
extensions.
====
endif::XR_EXT_palm_pose[]

ifdef::XR_EXT_hand_interaction[]
[NOTE]
.Note
====
When the apiext:XR_EXT_hand_interaction extension is available and enabled,
additional "pinch_ext" and "poke_ext" standard pose identifiers are
available, and a path is added to all interaction profiles valid for
pathname:/user/hand/left or pathname:/user/hand/right.
This includes interaction profiles defined in the core spec and in
extensions.
====
endif::XR_EXT_hand_interaction[]

[[semantic-paths-standard-locations]]
===== Standard locations

When a single device contains multiple input sources that use the same
identifier, a location suffix is added to create a unique identifier for
that input source.

Standard locations are:

* left
* right
* left_upper
* left_lower
* right_upper
* right_lower
* upper
* lower

[[semantic-paths-standard-components]]
===== Standard components

Components are named for the specific boolean, scalar, or other value of the
input source.
Standard components are:

* click - A physical switch has been pressed by the user.
  This is valid for all buttons, and is common for trackpads, thumbsticks,
  triggers, and dpads.
  "click" components are always boolean.
* touch - The user has touched the input source.
  This is valid for all trackpads, and may: be present for any other kind of
  input source if the device includes the necessary sensor.
  "touch" components are always boolean.
* force - A 1D scalar value that represents the user applying force to the
  input.
  It varies from 0 to 1, with 0 being the rest state.
  This is present for any input source with a force sensor.
* value - A 1D scalar value that varies from 0 to 1, with 0 being the rest
  state.
  This is present for triggers, throttles, and pedals.
  It may: also be present for squeeze or other components.
* x, y - scalar components of 2D values.
  These vary in value from -1 to 1.
  These represent the 2D position of the input source with 0 being the rest
  state on each axis.
  -1 means all the way left for x axis or all the way down for y axis.
  +1 means all the way right for x axis or all the way up for y axis.
  x and y components are present for trackpads, thumbsticks, and joysticks.
* twist - Some sources, such as flight sticks, have a sensor that allows the
  user to twist the input left or right.
  For this component -1 means all the way left and 1 means all the way
  right.
* pose - The orientation and/or position of this input source.
  This component may: exist for dedicated pose identifiers like grip and
  aim, or may: be defined on other identifiers such as trackpad to let
  applications reason about the surface of that part.
* proximity - The user is in physical proximity of input source.
  This may: be present for any kind of input source representing a physical
  component, such as a button, if the device includes the necessary sensor.
  The state of a "proximity" component must: be ename:XR_TRUE if the same
  input source is returning ename:XR_TRUE for either a "touch" or any other
  component that implies physical contact.
  The runtime may: return ename:XR_TRUE for "proximity" when "touch" returns
  ename:XR_FALSE which would indicate that the user is hovering just above,
  but not touching the input source in question.
  "proximity" components are always boolean.
  (Provided by `XR_VERSION_1_1`)

[[semantic-paths-output-paths]]
===== Output paths

Many devices also have subpaths for output features such as haptics.
The runtime must: ignore output component paths that do not follow the
pattern:

* subpathname:/output/<output_identifier>[_<location>]

Standard output identifiers are:

* haptic - A haptic element like an LRA (Linear Resonant Actuator) or
  vibration motor
* haptic_trigger - A haptic element located in the trigger (Provided by
  `XR_VERSION_1_1`)
* haptic_thumb - A haptic element located in the resting place of the thumb,
  like under the touchpad (Provided by `XR_VERSION_1_1`)

Devices which contain multiple haptic elements with the same output
identifier must use a location suffix as specified above.


==== Adding input sources via extensions

Extensions may: enable input source path identifiers, output source path
identifiers, and component names that are not included in the core
specification, subject to the following conditions:

* EXT extensions must: include the _ext suffix on any identifier or
  component name.
  E.g. subpathname:/input/newidentifier_ext/newcomponent_ext
* Vendor extensions must: include the vendor's tag as a suffix on any
  identifier or component name.
  E.g. subpathname:/input/newidentifier_vendor/newcomponent_vendor (where
  "vendor" is replaced with the vendor's actual extension tag.)
* Khronos (KHR) extensions may: add undecorated identifier or component
  names.

These rules are in place to prevent extensions from adding first class
undecorated names that become defacto standards.
Runtimes must: ignore input source paths that do not follow the restrictions
above.

Extensions may: also add new location suffixes, and may: do so by adding a
new identifier and location combination using the appropriate suffix.
E.g. subpathname:/input/newidentifier_newlocation_ext


[[semantic-paths-interaction-profiles]]
=== Interaction Profile Paths

An interaction profile path identifies a collection of buttons and other
input sources in a physical arrangement to allow applications and runtimes
to coordinate action bindings.

Interaction profile paths are of the form:

* pathname:/interaction_profiles/<vendor_name>/<type_name>

// Linking to the palm pose extension here is a special exception due to its
// effect on existing interaction profiles and its anticipated widespread
// availability. Do not add even conditional links to extensions in this
// chapter normally. We may consider including a generated list of links once
// interaction profiles are in the XML registry.
ifdef::XR_EXT_palm_pose[]
[NOTE]
.Note
====
When the apiext:XR_EXT_palm_pose extension is available and enabled, an
additional input component path is added to all core interaction profiles
valid for pathname:/user/hand/left or pathname:/user/hand/right.
See the extension for more details.
====
endif::XR_EXT_palm_pose[]

==== Khronos Simple Controller Profile

Path: pathname:/interaction_profiles/khr/simple_controller

Valid for user paths:

* pathname:/user/hand/left
* pathname:/user/hand/right

This interaction profile provides basic pose, button, and haptic support for
applications with simple input needs.
There is no hardware associated with the profile, and runtimes which support
this profile should: map the input paths provided to whatever the
appropriate paths are on the actual hardware.

Supported component paths:

* subpathname:/input/select/click
* subpathname:/input/menu/click
* subpathname:/input/grip/pose
* subpathname:/input/aim/pose
* subpathname:/output/haptic

include::{config}/grip_surface_notice.adoc[]
include::{config}/ext_palm_pose_notice.adoc[]
include::{config}/ext_hand_interaction_notice.adoc[]

==== Bytedance PICO Neo 3 controller Profile
(Provided by `XR_VERSION_1_1`)

Path: pathname:/interaction_profiles/bytedance/pico_neo3_controller

Valid for user paths:

* pathname:/user/hand/left
* pathname:/user/hand/right

This interaction profile represents the input sources and haptics on the
Bytedance PICO Neo3 Controller.

* On /user/hand/left only:
** subpathname:/input/x/click
** subpathname:/input/x/touch
** subpathname:/input/y/click
** subpathname:/input/y/touch
* On /user/hand/right only:
** subpathname:/input/a/click
** subpathname:/input/a/touch
** subpathname:/input/b/click
** subpathname:/input/b/touch
* subpathname:/input/menu/click
* subpathname:/input/system/click (may: not be available for application
  use)
* subpathname:/input/trigger/click
* subpathname:/input/trigger/value
* subpathname:/input/trigger/touch
* subpathname:/input/thumbstick/y
* subpathname:/input/thumbstick/x
* subpathname:/input/thumbstick/click
* subpathname:/input/thumbstick/touch
* subpathname:/input/squeeze/click
* subpathname:/input/squeeze/value
* subpathname:/input/grip/pose
* subpathname:/input/aim/pose
* subpathname:/output/haptic

include::{config}/grip_surface_notice.adoc[]
include::{config}/ext_palm_pose_notice.adoc[]
include::{config}/ext_hand_interaction_notice.adoc[]

==== Bytedance PICO 4 controller Profile
(Provided by `XR_VERSION_1_1`)

Path: pathname:/interaction_profiles/bytedance/pico4_controller

Valid for user paths:

* pathname:/user/hand/left
* pathname:/user/hand/right

This interaction profile represents the input sources and haptics on the
Bytedance PICO 4 Controller.

* On /user/hand/left only:
** subpathname:/input/x/click
** subpathname:/input/x/touch
** subpathname:/input/y/click
** subpathname:/input/y/touch
** subpathname:/input/menu/click
* On /user/hand/right only:
** subpathname:/input/a/click
** subpathname:/input/a/touch
** subpathname:/input/b/click
** subpathname:/input/b/touch
* subpathname:/input/system/click (may: not be available for application
use)
* subpathname:/input/trigger/click
* subpathname:/input/trigger/value
* subpathname:/input/trigger/touch
* subpathname:/input/thumbstick/y
* subpathname:/input/thumbstick/x
* subpathname:/input/thumbstick/click
* subpathname:/input/thumbstick/touch
* subpathname:/input/squeeze/click
* subpathname:/input/squeeze/value
* subpathname:/input/grip/pose
* subpathname:/input/aim/pose
* subpathname:/output/haptic

include::{config}/grip_surface_notice.adoc[]
include::{config}/ext_palm_pose_notice.adoc[]
include::{config}/ext_hand_interaction_notice.adoc[]

==== Bytedance PICO G3 controller Profile
(Provided by `XR_VERSION_1_1`)

Path: pathname:/interaction_profiles/bytedance/pico_g3_controller

Valid for user paths:

* pathname:/user/hand/left
* pathname:/user/hand/right

This interaction profile represents the input sources and haptics on the
Bytedance PICO G3 Controller.

* subpathname:/input/trigger/click
* subpathname:/input/trigger/value
* subpathname:/input/menu/click
* subpathname:/input/grip/pose
* subpathname:/input/aim/pose
* subpathname:/input/thumbstick
* subpathname:/input/thumbstick/click

include::{config}/grip_surface_notice.adoc[]
include::{config}/ext_palm_pose_notice.adoc[]
include::{config}/ext_hand_interaction_notice.adoc[]

[NOTE]
.Note
====
When designing suggested bindings for this interaction profile, you may:
suggest bindings for both pathname:/user/hand/left and
pathname:/user/hand/right.
However, only one of them will be active at a given time, so do not design
interactions that require simultaneous use of both hands.
====

==== Google Daydream Controller Profile

Path: pathname:/interaction_profiles/google/daydream_controller

Valid for user paths:

* pathname:/user/hand/left
* pathname:/user/hand/right

This interaction profile represents the input sources on the Google Daydream
Controller.

Supported component paths:

* subpathname:/input/select/click
* subpathname:/input/trackpad/x
* subpathname:/input/trackpad/y
* subpathname:/input/trackpad/click
* subpathname:/input/trackpad/touch
* subpathname:/input/grip/pose
* subpathname:/input/aim/pose

include::{config}/grip_surface_notice.adoc[]
include::{config}/ext_palm_pose_notice.adoc[]
include::{config}/ext_hand_interaction_notice.adoc[]

==== HP Mixed Reality Motion Controller Profile
(Provided by `XR_VERSION_1_1`)

Path: pathname:/interaction_profiles/hp/mixed_reality_controller

Valid for user paths:

* pathname:/user/hand/left
* pathname:/user/hand/right

This interaction profile represents the input sources and haptics on the HP
Mixed Reality Motion Controller.

* On pathname:/user/hand/left only:
** subpathname:/input/x/click
** subpathname:/input/y/click
* On pathname:/user/hand/right only:
** subpathname:/input/a/click
** subpathname:/input/b/click
* subpathname:/input/menu/click
* subpathname:/input/squeeze/value
* subpathname:/input/trigger/value
* subpathname:/input/thumbstick/x
* subpathname:/input/thumbstick/y
* subpathname:/input/thumbstick/click
* subpathname:/input/grip/pose
* subpathname:/input/aim/pose
* subpathname:/output/haptic

include::{config}/grip_surface_notice.adoc[]
include::{config}/ext_palm_pose_notice.adoc[]
include::{config}/ext_hand_interaction_notice.adoc[]

==== HTC Vive Controller Profile

Path: pathname:/interaction_profiles/htc/vive_controller

Valid for user paths:

* pathname:/user/hand/left
* pathname:/user/hand/right

This interaction profile represents the input sources and haptics on the
Vive Controller.

Supported component paths:

* subpathname:/input/system/click (may: not be available for application
  use)
* subpathname:/input/squeeze/click
* subpathname:/input/menu/click
* subpathname:/input/trigger/click
* subpathname:/input/trigger/value
* subpathname:/input/trackpad/x
* subpathname:/input/trackpad/y
* subpathname:/input/trackpad/click
* subpathname:/input/trackpad/touch
* subpathname:/input/grip/pose
* subpathname:/input/aim/pose
* subpathname:/output/haptic

include::{config}/grip_surface_notice.adoc[]
include::{config}/ext_palm_pose_notice.adoc[]
include::{config}/ext_hand_interaction_notice.adoc[]

==== HTC Vive Cosmos Controller Profile
(Provided by `XR_VERSION_1_1`)

Path: pathname:/interaction_profiles/htc/vive_cosmos_controller

Valid for user paths:

* pathname:/user/hand/left
* pathname:/user/hand/right

This interaction profile represents the input sources and haptics on the
Vive Cosmos Controller.

Supported component paths:

* On pathname:/user/hand/left only:
** subpathname:/input/x/click
** subpathname:/input/y/click
** subpathname:/input/menu/click
* On pathname:/user/hand/right only:
** subpathname:/input/a/click
** subpathname:/input/b/click
** subpathname:/input/system/click (may: not be available for application
   use)
* subpathname:/input/shoulder/click
* subpathname:/input/squeeze/click
* subpathname:/input/trigger/click
* subpathname:/input/trigger/value
* subpathname:/input/thumbstick/x
* subpathname:/input/thumbstick/y
* subpathname:/input/thumbstick/click
* subpathname:/input/thumbstick/touch
* subpathname:/input/grip/pose
* subpathname:/input/aim/pose
* subpathname:/output/haptic

include::{config}/grip_surface_notice.adoc[]
include::{config}/ext_palm_pose_notice.adoc[]
include::{config}/ext_hand_interaction_notice.adoc[]

==== HTC Vive Focus 3 Controller Profile
(Provided by `XR_VERSION_1_1`)

Path: pathname:/interaction_profiles/htc/vive_focus3_controller

Valid for user paths:

* pathname:/user/hand/left
* pathname:/user/hand/right

This interaction profile represents the input sources and haptics on the
Vive Focus 3 Controller.

* On pathname:/user/hand/left only:
** subpathname:/input/x/click
** subpathname:/input/y/click
** subpathname:/input/menu/click
* On pathname:/user/hand/right only:
** subpathname:/input/a/click
** subpathname:/input/b/click
** subpathname:/input/system/click (may: not be available for application
   use)
* subpathname:/input/squeeze/click
* subpathname:/input/squeeze/touch
* subpathname:/input/squeeze/value
* subpathname:/input/trigger/click
* subpathname:/input/trigger/touch
* subpathname:/input/trigger/value
* subpathname:/input/thumbstick/x
* subpathname:/input/thumbstick/y
* subpathname:/input/thumbstick/click
* subpathname:/input/thumbstick/touch
* subpathname:/input/thumbrest/touch
* subpathname:/input/grip/pose
* subpathname:/input/aim/pose
* subpathname:/output/haptic

include::{config}/grip_surface_notice.adoc[]
include::{config}/ext_palm_pose_notice.adoc[]
include::{config}/ext_hand_interaction_notice.adoc[]

==== HTC Vive Pro Profile

Path: pathname:/interaction_profiles/htc/vive_pro

Valid for user paths:

* pathname:/user/head

This interaction profile represents the input sources on the Vive Pro
headset.

Supported component paths:

* subpathname:/input/system/click (may: not be available for application
  use)
* subpathname:/input/volume_up/click
* subpathname:/input/volume_down/click
* subpathname:/input/mute_mic/click

==== Magic Leap 2 Controller Profile
(Provided by `XR_VERSION_1_1`)

Path: pathname:/interaction_profiles/ml/ml2_controller

Valid for user paths:

* pathname:/user/hand/left
* pathname:/user/hand/right

This interaction profile represents the input sources and haptics on the
Magic Leap 2 controller.

Supported component paths:

* subpathname:/input/menu/click
* subpathname:/input/home/click (may: not be available for application use)
* subpathname:/input/trigger/click
* subpathname:/input/trigger/value
* subpathname:/input/trackpad/y
* subpathname:/input/trackpad/x
* subpathname:/input/trackpad/click
* subpathname:/input/trackpad/force
* subpathname:/input/trackpad/touch
* subpathname:/input/aim/pose
* subpathname:/input/grip/pose
* subpathname:/input/shoulder/click
* subpathname:/output/haptic

include::{config}/grip_surface_notice.adoc[]
include::{config}/ext_palm_pose_notice.adoc[]
include::{config}/ext_hand_interaction_notice.adoc[]

==== Microsoft Mixed Reality Motion Controller Profile

Path: pathname:/interaction_profiles/microsoft/motion_controller

Valid for user paths:

* pathname:/user/hand/left
* pathname:/user/hand/right

This interaction profile represents the input sources and haptics on the
Microsoft Mixed Reality Controller.

Supported component paths:

* subpathname:/input/menu/click
* subpathname:/input/squeeze/click
* subpathname:/input/trigger/value
* subpathname:/input/thumbstick/x
* subpathname:/input/thumbstick/y
* subpathname:/input/thumbstick/click
* subpathname:/input/trackpad/x
* subpathname:/input/trackpad/y
* subpathname:/input/trackpad/click
* subpathname:/input/trackpad/touch
* subpathname:/input/grip/pose
* subpathname:/input/aim/pose
* subpathname:/output/haptic

include::{config}/grip_surface_notice.adoc[]
include::{config}/ext_palm_pose_notice.adoc[]
include::{config}/ext_hand_interaction_notice.adoc[]

==== Microsoft Xbox Controller Profile

Path: pathname:/interaction_profiles/microsoft/xbox_controller

Valid for user paths:

* pathname:/user/gamepad

This interaction profile represents the input sources and haptics on the
Microsoft Xbox Controller.

Supported component paths:

* subpathname:/input/menu/click
* subpathname:/input/view/click
* subpathname:/input/a/click
* subpathname:/input/b/click
* subpathname:/input/x/click
* subpathname:/input/y/click
* subpathname:/input/dpad_down/click
* subpathname:/input/dpad_right/click
* subpathname:/input/dpad_up/click
* subpathname:/input/dpad_left/click
* subpathname:/input/shoulder_left/click
* subpathname:/input/shoulder_right/click
* subpathname:/input/thumbstick_left/click
* subpathname:/input/thumbstick_right/click
* subpathname:/input/trigger_left/value
* subpathname:/input/trigger_right/value
* subpathname:/input/thumbstick_left/x
* subpathname:/input/thumbstick_left/y
* subpathname:/input/thumbstick_right/x
* subpathname:/input/thumbstick_right/y
* subpathname:/output/haptic_left
* subpathname:/output/haptic_right
* subpathname:/output/haptic_left_trigger
* subpathname:/output/haptic_right_trigger

==== Oculus Go Controller Profile

Path: pathname:/interaction_profiles/oculus/go_controller

Valid for user paths:

* pathname:/user/hand/left
* pathname:/user/hand/right

This interaction profile represents the input sources on the Oculus Go
controller.

Supported component paths:

* subpathname:/input/system/click (may: not be available for application
  use)
* subpathname:/input/trigger/click
* subpathname:/input/back/click
* subpathname:/input/trackpad/x
* subpathname:/input/trackpad/y
* subpathname:/input/trackpad/click
* subpathname:/input/trackpad/touch
* subpathname:/input/grip/pose
* subpathname:/input/aim/pose

include::{config}/grip_surface_notice.adoc[]
include::{config}/ext_palm_pose_notice.adoc[]
include::{config}/ext_hand_interaction_notice.adoc[]

[[semantic-paths-oculus-touch-controller-profile]]
==== Oculus Touch Controller Profile

Path: pathname:/interaction_profiles/oculus/touch_controller

Valid for user paths:

* pathname:/user/hand/left
* pathname:/user/hand/right

This interaction profile represents the input sources and haptics on the
Oculus Touch controller.

Supported component paths:

* On pathname:/user/hand/left only:
** subpathname:/input/x/click
** subpathname:/input/x/touch
** subpathname:/input/y/click
** subpathname:/input/y/touch
** subpathname:/input/menu/click
* On pathname:/user/hand/right only:
** subpathname:/input/a/click
** subpathname:/input/a/touch
** subpathname:/input/b/click
** subpathname:/input/b/touch
** subpathname:/input/system/click (may: not be available for application
   use)
* subpathname:/input/squeeze/value
* subpathname:/input/trigger/value
* subpathname:/input/trigger/touch
* subpathname:/input/trigger/proximity (Provided by `XR_VERSION_1_1`)
* subpathname:/input/thumb_resting_surfaces/proximity (Provided by
  `XR_VERSION_1_1`)
* subpathname:/input/thumbstick/x
* subpathname:/input/thumbstick/y
* subpathname:/input/thumbstick/click
* subpathname:/input/thumbstick/touch
* subpathname:/input/thumbrest/touch
* subpathname:/input/grip/pose
* subpathname:/input/aim/pose
* subpathname:/output/haptic

include::{config}/grip_surface_notice.adoc[]
include::{config}/ext_palm_pose_notice.adoc[]
include::{config}/ext_hand_interaction_notice.adoc[]

==== Meta Touch Pro Controller Profile
(Provided by `XR_VERSION_1_1`)

Path: pathname:/interaction_profiles/meta/touch_pro_controller

Valid for user paths:

* pathname:/user/hand/left
* pathname:/user/hand/right

This interaction profile represents the input sources and haptics on the
Meta Touch Pro controller.

Supported component paths:

* On pathname:/user/hand/left only:
** subpathname:/input/x/click
** subpathname:/input/x/touch
** subpathname:/input/y/click
** subpathname:/input/y/touch
** subpathname:/input/menu/click
* On pathname:/user/hand/right only:
** subpathname:/input/a/click
** subpathname:/input/a/touch
** subpathname:/input/b/click
** subpathname:/input/b/touch
** subpathname:/input/system/click (may: not be available for application
   use)
* subpathname:/input/squeeze/value
* subpathname:/input/trigger/value
* subpathname:/input/trigger/touch
* subpathname:/input/trigger/proximity
* subpathname:/input/trigger_curl/value
* subpathname:/input/trigger_slide/value
* subpathname:/input/thumb_resting_surfaces/proximity
* subpathname:/input/thumbstick/x
* subpathname:/input/thumbstick/y
* subpathname:/input/thumbstick/click
* subpathname:/input/thumbstick/touch
* subpathname:/input/thumbrest/touch
* subpathname:/input/thumbrest/force
* subpathname:/input/stylus/force
* subpathname:/input/grip/pose
* subpathname:/input/aim/pose
* subpathname:/output/haptic
* subpathname:/output/haptic_trigger
* subpathname:/output/haptic_thumb

include::{config}/grip_surface_notice.adoc[]
include::{config}/ext_palm_pose_notice.adoc[]
include::{config}/ext_hand_interaction_notice.adoc[]

==== Meta Touch Plus Controller Profile

(Provided by `XR_VERSION_1_1`)

Path: pathname:/interaction_profiles/meta/touch_plus_controller

Valid for user paths:

* pathname:/user/hand/left
* pathname:/user/hand/right

This interaction profile represents the input sources and haptics on the
Meta Touch Plus controller.

Supported component paths:

* On pathname:/user/hand/left only:
** subpathname:/input/x/click
** subpathname:/input/x/touch
** subpathname:/input/y/click
** subpathname:/input/y/touch
** subpathname:/input/menu/click
* On pathname:/user/hand/right only:
** subpathname:/input/a/click
** subpathname:/input/a/touch
** subpathname:/input/b/click
** subpathname:/input/b/touch
** subpathname:/input/system/click (may: not be available for application
   use)
* subpathname:/input/squeeze/value
* subpathname:/input/trigger/value
* subpathname:/input/trigger/touch
* subpathname:/input/trigger/force
* subpathname:/input/trigger/proximity
* subpathname:/input/trigger_curl/value
* subpathname:/input/trigger_slide/value
* subpathname:/input/thumb_resting_surfaces/proximity
* subpathname:/input/thumbstick/x
* subpathname:/input/thumbstick/y
* subpathname:/input/thumbstick/click
* subpathname:/input/thumbstick/touch
* subpathname:/input/thumbrest/touch
* subpathname:/input/grip/pose
* subpathname:/input/aim/pose
* subpathname:/output/haptic

include::{config}/grip_surface_notice.adoc[]
include::{config}/ext_palm_pose_notice.adoc[]
include::{config}/ext_hand_interaction_notice.adoc[]

[[semantic-paths-meta-touch-controller-rift-cv1-profile]]
==== Meta Touch Controller (Rift CV1) Profile
(Provided by `XR_VERSION_1_1`)

Path: pathname:/interaction_profiles/meta/touch_controller_rift_cv1

Valid for user paths:

* pathname:/user/hand/left
* pathname:/user/hand/right

This interaction profile represents the input sources and haptics on the
Oculus Touch controller and is a legacy profile added to specifically
represent the controller shipped with the Rift CV1.

Supported component paths:

* On pathname:/user/hand/left only:
** subpathname:/input/x/click
** subpathname:/input/x/touch
** subpathname:/input/y/click
** subpathname:/input/y/touch
** subpathname:/input/menu/click
* On pathname:/user/hand/right only:
** subpathname:/input/a/click
** subpathname:/input/a/touch
** subpathname:/input/b/click
** subpathname:/input/b/touch
** subpathname:/input/system/click (may: not be available for application
   use)
* subpathname:/input/squeeze/value
* subpathname:/input/trigger/value
* subpathname:/input/trigger/touch
* subpathname:/input/trigger/proximity
* subpathname:/input/thumb_resting_surfaces/proximity
* subpathname:/input/thumbstick/x
* subpathname:/input/thumbstick/y
* subpathname:/input/thumbstick/click
* subpathname:/input/thumbstick/touch
* subpathname:/input/thumbrest/touch
* subpathname:/input/grip/pose
* subpathname:/input/aim/pose
* subpathname:/output/haptic

include::{config}/grip_surface_notice.adoc[]
include::{config}/ext_palm_pose_notice.adoc[]
include::{config}/ext_hand_interaction_notice.adoc[]


[[semantic-paths-meta-touch-controller-quest-1-rift-s-profile]]
==== Meta Touch Controller (Rift S / Quest 1) Profile
(Provided by `XR_VERSION_1_1`)

Path: pathname:/interaction_profiles/meta/touch_controller_quest_1_rift_s

Valid for user paths:

* pathname:/user/hand/left
* pathname:/user/hand/right

This interaction profile represents the input sources and haptics on the
Oculus Touch controller and is a legacy profile added to specifically
represent the controller shipped with the Rift S and Quest 1.

Supported component paths:

* On pathname:/user/hand/left only:
** subpathname:/input/x/click
** subpathname:/input/x/touch
** subpathname:/input/y/click
** subpathname:/input/y/touch
** subpathname:/input/menu/click
* On pathname:/user/hand/right only:
** subpathname:/input/a/click
** subpathname:/input/a/touch
** subpathname:/input/b/click
** subpathname:/input/b/touch
** subpathname:/input/system/click (may: not be available for application
   use)
* subpathname:/input/squeeze/value
* subpathname:/input/trigger/value
* subpathname:/input/trigger/touch
* subpathname:/input/trigger/proximity
* subpathname:/input/thumb_resting_surfaces/proximity
* subpathname:/input/thumbstick/x
* subpathname:/input/thumbstick/y
* subpathname:/input/thumbstick/click
* subpathname:/input/thumbstick/touch
* subpathname:/input/grip/pose
* subpathname:/input/aim/pose
* subpathname:/output/haptic

include::{config}/grip_surface_notice.adoc[]
include::{config}/ext_palm_pose_notice.adoc[]
include::{config}/ext_hand_interaction_notice.adoc[]

[[semantic-paths-meta-touch-controller-quest-2-profile]]
==== Meta Touch Controller (Quest 2) Profile
(Provided by `XR_VERSION_1_1`)

Path: pathname:/interaction_profiles/meta/touch_controller_quest_2

Valid for user paths:

* pathname:/user/hand/left
* pathname:/user/hand/right

This interaction profile represents the input sources and haptics on the
Oculus Touch controller and is a legacy profile added to specifically
represent the controller shipped with the Quest 2.

Supported component paths:

* On pathname:/user/hand/left only:
** subpathname:/input/x/click
** subpathname:/input/x/touch
** subpathname:/input/y/click
** subpathname:/input/y/touch
** subpathname:/input/menu/click
* On pathname:/user/hand/right only:
** subpathname:/input/a/click
** subpathname:/input/a/touch
** subpathname:/input/b/click
** subpathname:/input/b/touch
** subpathname:/input/system/click (may: not be available for application
   use)
* subpathname:/input/squeeze/value
* subpathname:/input/trigger/value
* subpathname:/input/trigger/touch
* subpathname:/input/trigger/proximity
* subpathname:/input/thumb_resting_surfaces/proximity
* subpathname:/input/thumbstick/x
* subpathname:/input/thumbstick/y
* subpathname:/input/thumbstick/click
* subpathname:/input/thumbstick/touch
* subpathname:/input/thumbrest/touch
* subpathname:/input/grip/pose
* subpathname:/input/aim/pose
* subpathname:/output/haptic

include::{config}/grip_surface_notice.adoc[]
include::{config}/ext_palm_pose_notice.adoc[]
include::{config}/ext_hand_interaction_notice.adoc[]

==== Samsung Odyssey Controller Profile
(Provided by `XR_VERSION_1_1`)

Path: pathname:/interaction_profiles/samsung/odyssey_controller

Valid for user paths:

* pathname:/user/hand/left
* pathname:/user/hand/right

This interaction profile represents the input sources and haptics on the
Samsung Odyssey Controller.
It is exactly the same, with the exception of the name of the interaction
profile, as the Microsoft Mixed Reality Controller interaction profile.
It enables the application to differentiate the newer form factor of motion
controller released with the Samsung Odyssey headset.
It enables the application to customize the appearance and experience of the
controller differently from the original
<<_microsoft_mixed_reality_motion_controller_profile, mixed reality motion
controller>>.

Supported component paths:

* subpathname:/input/menu/click
* subpathname:/input/squeeze/click
* subpathname:/input/trigger/value
* subpathname:/input/thumbstick/x
* subpathname:/input/thumbstick/y
* subpathname:/input/thumbstick/click
* subpathname:/input/trackpad/x
* subpathname:/input/trackpad/y
* subpathname:/input/trackpad/click
* subpathname:/input/trackpad/touch
* subpathname:/input/grip/pose
* subpathname:/input/aim/pose
* subpathname:/output/haptic

include::{config}/grip_surface_notice.adoc[]
include::{config}/ext_palm_pose_notice.adoc[]
include::{config}/ext_hand_interaction_notice.adoc[]

==== Valve Index Controller Profile

Path: pathname:/interaction_profiles/valve/index_controller

Valid for user paths:

* pathname:/user/hand/left
* pathname:/user/hand/right

This interaction profile represents the input sources and haptics on the
Valve Index controller.

Supported component paths:

* subpathname:/input/system/click (may: not be available for application
  use)
* subpathname:/input/system/touch (may: not be available for application
  use)
* subpathname:/input/a/click
* subpathname:/input/a/touch
* subpathname:/input/b/click
* subpathname:/input/b/touch
* subpathname:/input/squeeze/value
* subpathname:/input/squeeze/force
* subpathname:/input/trigger/click
* subpathname:/input/trigger/value
* subpathname:/input/trigger/touch
* subpathname:/input/thumbstick/x
* subpathname:/input/thumbstick/y
* subpathname:/input/thumbstick/click
* subpathname:/input/thumbstick/touch
* subpathname:/input/trackpad/x
* subpathname:/input/trackpad/y
* subpathname:/input/trackpad/force
* subpathname:/input/trackpad/touch
* subpathname:/input/grip/pose
* subpathname:/input/aim/pose
* subpathname:/output/haptic

include::{config}/grip_surface_notice.adoc[]
include::{config}/ext_palm_pose_notice.adoc[]
include::{config}/ext_hand_interaction_notice.adoc[]
