Made the xr-standard gamepad mapping more rigid

[toji]

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.

[NellWaliczek]

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.

[toji]

Feedback addressed aside from the "MUST" recommendation, which I left a comment for.

[NellWaliczek]

Thanks for the fast fixes!

[toji]

@thetuvix: I'd appreciate your approval prior to merging as well.

[thetuvix]

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?

[toji]

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-controller
• touchpad-controller // This is basically just the daydream controller and.... anything else?
• touchpad-button-controller
• thumbstick-controller // Never seen a thumbstick controller without a separate trigger
• thumbstick-button-controller
• touchpad-thumbstick-controller // Is this actually a thing anywhere?
• touchpad-thumbstick-button-controller

[thetuvix]

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-standard defined which controller parts map to which buttons/axes IDs
• xr-standard promised 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.

[thetuvix]

Should we continue this thread as part of #738?

[NellWaliczek]

I support this direction. I'd kinda been feeling the same way as I looked over the actual spec text changes.

[thetuvix]

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)?

[toji]

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.)

[thetuvix]

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.

[toji]

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. 🙄)

[toji]

@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.

[thetuvix]

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?

[thetuvix]

Looks good! I left some nits to fix up, as well as some comments in the active discussions. I'm happy if you want to continue some of these discussions in a further PR.

[NellWaliczek]

This feels a lot better to me. Thanks!

[toji]

Thanks for the feedback! I agree that the xr-standard mapping no longer needs to stand in for profiles. I ran with Alex's suggestion of requiring a primary button (which I still specify should be separate from a touchpad/thumbstick press) but otherwise xr-standard in specified here to really just be an indication of which elements are surfaced where, and not which ones are actually present.

Would appreciate one more brief review from @NellWaliczek or @thetuvix before landing, but otherwise I'm going to plan on merging this by EOD.