Made the xr-standard gamepad mapping more rigid #735
Conversation
There was a problem hiding this comment.
A few small nits, but otherwise looks good. I'd like to make sure @thetuvix is happy with the new button mappings before we merge though.
|
Feedback addressed aside from the "MUST" recommendation, which I left a comment for. |
|
@thetuvix: I'd appreciate your approval prior to merging as well. |
index.bs
Outdated
| <td>Primary Touchpad/Joystick X</td> | ||
| <td>Yes</td> | ||
| <td>Touchpad X</td> | ||
| <td>If thumbstick is not present</td> |
There was a problem hiding this comment.
Side question, since primary axes were already required before: Are we requiring that all xr-standard gamepads have either a touchpad or thumbstick? What about simpler "remote-style" controllers?
There was a problem hiding this comment.
My thoughts when initially laying out the mapping were that we wanted to ensure that if something was advertised as xr-standard developers could depend on it having a certain baseline level of functionality. I still think that's a reasonable goal, though it's maybe less important if paired with the profiles concept. And yes, that would mean that some input devices (Like the Daydream controller) wouldn't qualify for xr-standard.
If we wanted to loosen up on that restriction and simply say that xr-standard only means that the inputs are mapped to a predictable place, and does not imply which of them are present then we could do so. I think we might want to look at expanding the proposed generic profile set to be a bit more descriptive in that case, with variants like:
button-controllertouchpad-controller// This is basically just the daydream controller and.... anything else?touchpad-button-controllerthumbstick-controller// Never seen a thumbstick controller without a separate triggerthumbstick-button-controllertouchpad-thumbstick-controller// Is this actually a thing anywhere?touchpad-thumbstick-button-controller
There was a problem hiding this comment.
If we wanted to loosen up on that restriction and simply say that xr-standard only means that the inputs are mapped to a predictable place, and does not imply which of them are present then we could do so.
This aligns with what I've been thinking here. Before, we only had one concept, xr-standard, overloaded to serve two purposes:
xr-standarddefined which controller parts map to whichbuttons/axesIDsxr-standardpromised a minimum profile of controller parts that developers could assume were present
We've now split these into two distinct mapping and profile concepts in the API. It seems reasonable to embrace that, simplifying the meaning of the xr-standard mapping to a pure ID mapping, and allowing profiles to make more specific promises.
There was a problem hiding this comment.
Should we continue this thread as part of #738?
There was a problem hiding this comment.
I support this direction. I'd kinda been feeling the same way as I looked over the actual spec text changes.
| </tr> | ||
| </tbody> | ||
| </table> | ||
|
|
||
| Devices that lack one of the optional inputs listed in the tables above MUST preserve their place in the {{Gamepad/buttons}} or {{Gamepad/axes}} array, reporting a <dfn>placeholder button</dfn> or <dfn>placeholder axis</dfn>, respectively. A [=placeholder button=] MUST report <code>0</code> for {{GamepadButton/value}}, <code>false</code> for {{GamepadButton/pressed}}, and <code>false</code> for {{GamepadButton/touched}}. A [=placeholder axis=] MUST report <code>0</code>. [=Placeholder buttons=] and [=placeholder axis|axes=] MUST be omitted if they are the last element in the array or all following elements are also [=placeholder buttons=] or [=placeholder axis|axes=]. | ||
|
|
||
| Additional buttons or axes may be exposed after these reserved indices, and SHOULD appear in order of decreasing importance. Related axes (such both axes of a joystick) SHOULD be grouped and, if applicable, SHOULD appear in X, Y, Z order. If a device has both a touchpad and a joystick the UA MAY designate whichever it chooses to be the primary axis-based input. Buttons reserved by the UA or platform MUST NOT be exposed. | ||
| Additional buttons or axes may be exposed after these reserved indices, and SHOULD appear in order of decreasing importance. Related axes (such as both axes of a thumbstick) MUST be grouped and, if applicable, MUST appear in X, Y, Z order. Buttons reserved by the UA or platform MUST NOT be exposed. |
There was a problem hiding this comment.
In order to introduce further reserved indices in the future, we'd need some way to reconcile the additional indices. (I suppose this is true before this change as well)
Perhaps apps need to be explicit that they want an xr-standard mapping for their Gamepad - that way, we can later introduce an xr-standard-2 mapping or such that pushes out into button/axis 5, 6, etc.
Should the gamepad attribute perhaps be getGamepad(mapping)?
There was a problem hiding this comment.
I'm pretty strongly against making that large of a change to this chunk of the API this late. (Though I don't object to introducing a xr-standard-2 at some point if needed.)
I do think we'll likely outgrow the current shape of the gamepad API at some point, but when that time comes I have a hunch that we'll be better served by introducing something along the lines of an action mapping API rather than continue to hack more robust concepts onto an API that obviously never expected to deal with them. (And hopefully at that point we have a few years of insight into how developers are using OpenXR to help inform our direction.)
There was a problem hiding this comment.
Sounds good.
Even if we later do need to support what I said in the gamepad API, there are slightly less clean ways to do it later without changes now - for example, when requesting your XRSession, you could centrally set xr-standard-2 as your preferring mapping for receiving xr-standard* gamepad buttons/axes.
|
Okay, pushed an update that swaps the grip and touchpad button indices. (And they did a quick panicked recovery of a prior commit that I accidentally stomped on when pushing, which is why they're out-of-order now. 🙄) |
This will make cross-platform implementations more compatible by removing some level of platform option from the mapping process. It will also make it more practical to expose the discussed "profiles" concept by making it easier to have inter-compatible sets of profiles. Also took the opportunity to normalized on the verbiage "thumbstick" instead of joystick, since that appears to be the official verbiage used by all the device vendors.
|
@thetuvix: I've got approval from Nell, but I'm going to hold off from merging until I hear that you're OK with the latest changes as well. |
input-explainer.md
Outdated
|
|
||
| Additional device-specific inputs may be exposed after these reserved indices, but devices that lack one of the canonical inputs must still preserve their place in the array. If a device has both a touchpad and a joystick the UA should designate one of them to be the primary axis-based input and expose the other at axes[2] and axes[3] with an associated button at button[3]. | ||
| Additional device-specific inputs may be exposed after these reserved indices, but devices that lack one of the canonical inputs must still preserve their place in the array. | ||
|
|
||
| In order to make use of the `xr-standard` mapping, a device must meet **at least** the following criteria: | ||
|
|
||
| - Is a `tracked-pointer` device. | ||
| - Has a trigger or similarly accessed button |
There was a problem hiding this comment.
It seems fine to require at least a primary button/trigger for buttons[0].
Should we more strongly state then that this button MUST also trigger onselect for this XRInputSource?
|
Thanks for the feedback! I agree that the Would appreciate one more brief review from @NellWaliczek or @thetuvix before landing, but otherwise I'm going to plan on merging this by EOD. |
Addresses concerns brought up in #695
This will make cross-platform implementations more compatible by
removing some level of platform option from the mapping process. It will
also make it more practical to expose the discussed "profiles" concept
by making it easier to have inter-compatible sets of profiles.
Also took the opportunity to normalized on the verbiage "thumbstick"
instead of joystick, since that appears to be the official verbiage used
by all the device vendors.