Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Require or at least recommend the use of hysteresis for suggested input mappings #27

Closed
jherico opened this issue Jul 31, 2019 · 2 comments
Closed

Require or at least recommend the use of hysteresis for suggested input mappings #27

jherico opened this issue Jul 31, 2019 · 2 comments
Labels
enhancement New feature or request synced to gitlab A corresponding issue has been filed in the Khronos internal GitLab

Comments

@jherico
Copy link
Contributor

jherico commented Jul 31, 2019

For actions created with ename:XR_ACTION_TYPE_BOOLEAN_INPUT when the runtime is obeying suggested bindings: Boolean input sources must: be bound directly to the action. If the path is to a scalar value, a threshold must: be applied to the value and values over that threshold will be ename:XR_TRUE. The threshold may vary from device to device or component to component and is left as an implementation detail.

I suggest that this is too vague and that mapping analog inputs to boolean actions should require that implementations ensure that potential sources of noise do not cause the input to be rapidly triggered over and over when the analog source is very close to a given threshold. Noise in this case could be either muscle twitches by a user that are detectable by hardware but below the level of the intention of squeezing or releasing, or electronic noise from an analog sensing unit.

Saying that implementation must provide some level of hysteresis on such analog->boolean mappings and should attempt to ensure that the hysteresis range is appropriate for the potential noise values from a given analog input, taking into consideration both the ergonomics of the device and it's electronic properties would be appropriate, IMO.
@rpavlik rpavlik added the enhancement New feature or request label Aug 2, 2019
@rpavlik-bot
Copy link
Collaborator

An issue (number 1260) has been filed to correspond to this issue in the internal Khronos GitLab.

If you have a Khronos account, you can access that issue at KHR:openxr/openxr#1260.

@rpavlik-bot rpavlik-bot added the synced to gitlab A corresponding issue has been filed in the Khronos internal GitLab label Nov 25, 2019
rpavlik added a commit that referenced this issue May 11, 2021
@rpavlik
OpenXR Specification 1.0.16 (2021-05-11)
7874fcf 
This release contains improved/clarified behavior for xrCreateInstance
and xrEnumerateInstanceProperties, a new multi-vendor extension, a new
vendor extension, and a collection of clarifications.

-   Registry
    -   Add new XR_ERROR_RUNTIME_UNAVAILABLE error code, add
        XR_ERROR_RUNTIME_UNAVAILABLE as a supported error code to
        xrCreateInstance and xrEnumerateInstanceProperties, and remove
        XR_ERROR_INSTANCE_LOST as a supported error code from
        xrCreateInstance. (internal MR 2024, internal issue 1552,
        OpenXR-SDK-Source/#177)
    -   Add XR_EXT_hand_joint_motion_range multi-vendor extension.
        (internal MR 1995)
    -   Add XR_FB_swapchain_update_state vendor extension. (internal MR
        1997)
    -   Fix missing XR_ERROR_INSTANCE_LOST return codes for extension
        functions in XR_EXT_performance_settings, XR_EXT_debug_utils,
        XR_EXT_conformance_automation, and XR_EXT_thermal_query.
        (internal MR 2023, OpenXR-Docs/#10, internal issue 1256)
    -   Reserve extension 166 for working group use. (internal MR 2025)
-   Specification
    -   Clarify use of xrRequestExitSession on platforms with managed
        application lifecycle. (internal MR 1978)
    -   Clarify hand grip orientation Z semantics. (internal MR 2008)
    -   Clarify unordered swapchain usage flag meaning. (internal MR
        2029, internal issue 1543)
    -   Clarify that hysteresis should be used when applying thresholds
        to scalar input. (internal MR 2031, internal issue 1260,
        OpenXR-Docs/#27)
    -   Document new multi-vendor extension
        XR_EXT_hand_joint_motion_range - allows applications to request
        specific motion ranges when using XR_EXT_hand_tracking.
        (internal MR 1995)
    -   Document new XR_FB_swapchain_update_state vendor extension.
        (internal MR 1997)
    -   Fix xml_consistency scripts to properly identify missing error
        codes from handle ancestors, and suppress warnings about all
        missing _LOST and _LOSS_PENDING on xrDestroy functions.
        (internal MR 2023, OpenXR-Docs/#10, internal issue 1256)
    -   Modify language in XR_EXT_hand_tracking to explicitly state that
        an “empty hand” range of motion is the default. (internal MR
        1995)
    -   Session: Explicitly name the pattern for “get graphics
        requirements” functions, and place a generic version of the
        XR_ERROR_GRAPHICS_REQUIREMENTS_CALL_MISSING return code text
        from graphics extensions in the core spec. (OpenXR-Docs/#79,
        internal issue 1547)
    -   Style guide: Update “Extensions” chapter to simplify and reflect
        actual practice and policy. (internal MR 2027)
    -   Extension process document: Update to note the working group
        policy on extending core/KHR bitmasks. (internal MR 2025)
    -   scripts: Have reflow.py identify a file’s current newline
        convention, and reproduce it upon writing the output. (internal
        MR 2028)
@rpavlik
Copy link
Contributor

rpavlik commented May 11, 2021

Fixed in 1.0.16. We went with an overall "should", declining to make it more specific or "must" because of difficulty in testing it in a conformance test.

@rpavlik rpavlik closed this as completed May 11, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement New feature or request synced to gitlab A corresponding issue has been filed in the Khronos internal GitLab
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@rpavlik @jherico @rpavlik-bot