In the README.md, the Supported Hardware section in the appendices needs to be filled in. Instructions for keeping this up to date should be included in #51

In PR #4, the GamepadMock was added. Jest seems to have support for mocks that might be worth looking into using with it: https://jestjs.io/docs/en/es6-class-mocks

Per the comment here: #71 (comment)

Should Oculus Quest not be allowed to have Oculus Touch as a fallback profile because there is an extra thumbrest button on the latter?

The README.md needs an explanation of where to put new profiles/assets and how to validate them before issuing a pull request. This item is related to #12 and also probably should involve creating a dedicated PR template for new hardware

Currently the library is authored to be tested in a node.js environment. However, as it will be used primarily in-browser, this should be made just as easy.

The README.md needs a section added explaining how to file a bugs. This may involve creating issue templates. It may mean separate instructions for source bugs and profile bugs.

In the context of a major/minor/patch version scheme, we need to decide which types of changes to this repo would trigger a version bump. Throwing down a first proposal, I suggest:

Patch

• Adding new mapping and asset files
• Fixes to existing mapping or asset files

Minor

• Fixing bugs in source code
• Fixing bugs in tests
• Non-breaking schema changes (additive features)
• Non-breaking source changes (additive features)

Major

• Breaking schema changes
• Breaking source changes

Additionally, I'm wondering what we want to do about the version property in the mapping files. It seems a bit much to rev the version # in a mapping file simply because a new mapping file was added. Perhaps we change the version property in the mapping.json files to just be major/minor?

Currently thinking of requiring a .gltf model for all folders and optionally allowing other asset formats. This might make it a bit challenging to add automated tests for any random asset type, so perhaps there's an approved "secondary asset types" list? If we go down this route, we'll need to change the schema portion defining assets to be more flexible.

Test page currently uses three.js, but there are other engines that would be good to include as options for rendering.

In src/profiles, there are generic names thumbstick-controller, touchpad-controller, and touchpad-thumbstick-controller. However, with those names and the functionality that their profiles.json files define, it's still ambiguous whether or not the controllers have a grip button (or if it's just a placeholder button required by the xr-standard mapping).

For example, ideally there would be separate profiles for:
touchpad-controller (grip button slot is placeholder required by xr-standard mapping)
grip-touchpad-controller (grip button is actually exposed)

"unknown" gamepad ids may appear if the hardware is unidentifyable by the user agent or if the user agent has provided users a way to mask their gamepad id for privacy reasons. In this situation, a mapping and asset should be present to fall back to. This same fallback should be used if the gamepad id does not have a mapping in the repo.

Yes, this is an absurd nit. But it's also currently the only repo in the immersive-web org that has a capital letter in it, so... 🤷‍♀️

In the README.md, the motivation section needs an explanation of what a motion controller is.

As of PR #4, the schema tests are a lot of copy/paste. I'd like to figure out how to get jest to consume a manifest of some sort and automatically run the same test against the manifest's supplied input.

As authored, this library invokes an asychronous method to fetch and load a profile. When the input source is of type 'screen', this creates unnecessary overhead. This issue tracks thinking about how we might choose to modify the library to avoid this.

Alternatively we can do nothing and expect developers to check the type of the XRInputSource before invoking the Profiles.createMotionController() method.

While the WebXR spec (after immersive-web/webxr#553 is merged) provides some guidelines around exposing controllers as Gamepads, there is still room for interpretation that could lead to different behavior among implementations. In addition, future controller/input mechanisms (i.e., hands as exposed by a specific technology) may not map well to "xr-standard" or otherwise have obvious mappings.

To encourage consistency and interoperability, details about how specific controllers should be exposed by user agent implementations should be defined in a registry. The registry would be separate from the spec, allowing out-of-band updates (per an established process). It would both clearly define how implementations should expose specific controllers and thus how applications and libraries (e.g., https://github.com/immersive-web/xr-gamepad-mappings) can expect them to be exposed.

The registry would map some well understood definition of a physical controller to:

• id string
• GamepadMappingType
• The physical button that represents the primary action
• A clear definition of how the physical buttons are exposed via the Gamepad interface
  • This would include which buttons are not to be exposed, such as those reserved by the system and/or user agents.

Ideally, the entry would also include some concrete information, such as USB vendor and product IDs and/or identifier exposed by native runtime(s).

A single entry could cover multiple devices (i.e., revisions of a controller) as long as the physical appearance (due to the intent for applications to use the id to choose a controller model) and button mapping are the same. If there are multiple versions of hardware with the same product name, they may be identified by version, year, or similar.

Such a registry would also solve a couple open issues:

• Format of Gamepad identifiers (#550): While the registry could have guidelines, there wouldn’t be a need to define a perfect rule covering all hardware because the registry would specify the identifier.
• As such, identically-/similarly-named controllers (e.g., “Oculus Touch” per immersive-web/webxr#550 (comment)) can be clearly and easily differentiated.

One additional possibility is that [XR-specific] GamepadMappingTypes also be specified in a registry. These would be added much more conservatively, but it might be preferable to be able to define new ones without going through the full spec process. This would also allow slimming the core WebXR spec a bit.

For reference, there is an open issue for the W3C Process Document (w3c/w3process#168) to define a process for handling registries. This shouldn’t block us from proceeding, and other specs have successfully used registries in the past.

The profile.id is prefixed with "WebVR " if it's a webvr profile as of #48. Perhaps we don't need separate property indicating the same thing?

It could be that the way to do this is to have two separate folder hierarchies? This would allow us to have the "Oculus Touch (left)" for WebVR and the correct "OculusTouch" for WebXR. Alternatively, we could put another .json file at the root of the repo containing a list of reported gamepad IDs and which folder contains the mapping/asset.

Also, we'll need to add a component node for the target ray origin for WebVR.

Anything else?

I'm leaving this for now, so I can move onto the next steps, but I'd like to change the XRGamepad.getMapping() function to have the ability to automatically determine the correct mappingType. This would be predicated on uniqueness in naming.

In the README.md, the motivation section needs an explanation about the difference between WebXR and WebVR

Unsure if this is necessary, but it might be helpful for validation purposes.

This is dependent on the outcome of https://github.com/immersive-web/webxr/issues/772

If we do enable events, this library might want to do something to allow component event firing.

Perhaps this is just for visualResponses, but it seems like it would be useful for all objects with properties describing nodes to indicate if the node paths are relative to the parent's object's root or if they are absolute to the asset file. This might significantly simplify the number of separate visual response nodes necessary.

So this is feedback that's a couple of PRs too late, but it didn't really click with me till I saw it used in context. The use of "origin" here feels to me like it only implies a position offset, so it read kind of weird to me at first. Is there a better term that we could use?

Originally posted by @toji in #38

PR #27 fixed all the text references, but it looks like I missed the one diagram referring to "hands".

We can drive further cross-UA conformance for UAs built atop OpenXR. Another package of JSON mappings could map each WebXR input profile to its corresponding OpenXR interaction profile, defining which button/axis index maps to which OpenXR /user path. OpenXR-based UAs could then simply merge in the latest OpenXR mappings once per release to inherit conformant support for all the latest controllers.

Originally posted by @thetuvix in #78

Other schema portions have tests in the tests/schemas folder as of #4; add the response tests there.

Just FYI: Oculus Quest controllers mapping is exactly the same as Oculus Touch one. More over, even the name of the controller is the same, including the gamepad id (at least, currently; this is done for compatibility reasons in WebVR with existing Oculus Touch-enabled experiences). The only difference is the 3D model of the controllers, but to determine this you'd need to check the name of the headset (at the moment).

Right now the library just exposes the targetRayOrigin as a property. This issue tracks investigating if there's a better way to integrate with the WebVR->WebXR polyfill. Updates to the library and README.md are likely.

This is pretty similar to the thumbstick and touchpad source descriptions. Merge them into a single file with the appropriate schema limitations to disallow "buttonIndex"

Use a schema regex validator to ensure that the version property is major/minor

While working on updating to the xr-gamepad-mappings library to match the latest spec text, I discovered a fairly annoying profile definition issue. I'm expecting to have the library updates posted shortly, but in the meantime I figured I'd get this issue filed for discussion.

The XRInputSource.getProfiles() call is designed such that developers can iterate over the list returned and select the best profile they know how to render and interpret. We've defined several default profiles to make this easier such as button-controller, thumbstick-controller, touchpad-controller, and touchpad-thumbstick-controller. The trouble is we defined the latter three to be ambiguous about whether or not a button is also present. In order to utilize this optional button or render its movement appropriately, developers must also check if the gamepad's mapping is xr-standard and potentially load/animate a different renderable model.

I know it's not ideal to have to define a bunch of additional default profile names (button-thumbstick-controller, button-touchpad-controller, button-touchpad-thumbstick-controller), but I'm not sure what other better approach there is. I'm super open to ideas though!

/cc @thetuvix

This property was added to make schema validation easier, but it doesn't actually add value to the mapping file. Figure out how to rewrite the schema so it doesn't depend on it.

Sections that still need filling in:

Motivation

• Explaining WebVR and WebXR
• Defining motion controllers

Design goals

• Remove "Developers should not need to add code checks for specific Gamepad.id as aberrant user agent behavior is also documentable in the schema as bugs are discovered." until we have a solution for this.

Adding New Hardware

• Describe the steps for adding a new mapping folder and how to test the chane
• Create Issue and PR templates

Filing a bug

• Describe which sorts of bugs are appropriate to file on this repo and how to do it
• Create an Issue template

Hardware

• Update the supported and missing lists

The "gamepad" node doesn't seem to be adding a whole lot of value to the schema. Consider removing it.

After some back-and-forth discussion, it was decided that the the mapping files will require assets to at least be available as FBX or glTF/glB. We'll look into what an extension schema would look like to allow other well-known formats.

(not sure if this is the right location for this ticket so please inform me if it needs to be moved)

I am encountering difficulty in implementing HTC Vive Trackers in the current WebVR 1.1 standard. I'm curious how this is proposed to be supported in WebXR.

Here are the issues:

• WebVR 1.1 browsers appear to expose controllers (and trackers) as an array accessible through Navigator.getGamepads()
• There is inconsistency with how WebVR 1.1 browsers expose the trackers:
  -- Firefox sometimes exposes them, sometimes they are assigned handedness, sometimes not, unclear pattern to this behavior
  -- Exokit only explicitly exposes vive wands, does not expose trackers (related ticket exokitxr/exokit#884)
  -- Supermedium has similar behavior to Firefox
• Further complicating things, Valve changed the behavior around managing inputs approx Oct 3 2018 during this release (search for "tracker") https://steamcommunity.com/games/250820/announcements/detail/3213772926319522701
• In Oct 10 2018 Valve introduced a built-in end-user-accessible SteamVR tool for Vive Tracker Mapping. This allows the end-user to map a "role" to a tracker such as "Left Foot" or "Right Hand". (this also created confusion which led to them to release a blog post about these changes)
• WebVR 1.1 browsers do NOT appear to pass the controller "role" that is set by the end-user using the new SteamVR Input Mapping configuration, making it impossible for WebVR applications to use specific trackers with reliability aside from random and/or rewriting a temporary mapping tool within the web application.

The ask for WebXR spec is to expose "role" that controllers may have as determined by SteamVR that allow targeting specific trackers from a web application.

The manual test should be updated and hosted from this repo so that new hardware can be tested easily

There are a number of profiles missing for known valid hardware. In addition, the profiles that exist are missing assets to go with them. This issue tracks getting assets added, node names updated in existing profiles, and missing profiles added as well.

The schema and library were authored under the assumption that there must always be 3D assets accompanying a profile.json. However, there is still value in a profile.json file describing a motion controller for use with an AR device so that button, thumbsticks, and touchpads can be easily reasoned about. However, AR devices have no need to render the model.

Given this, would it be a good idea to remove the requirement for a 3D asset to be present?

If so the following schema changes would be required when a 3D asset isn't available:

• Each "handedness" in the profile.json should have no "root" or "asset"
• Each "component" in the profile.json should have no "root"
• No "visualResponses" should be allowed in the profile.json
• When no asset, MotionController.assetPath should be ""
• When no asset, Component.rootNodeName should be ""
• When no asset, Component.labelNodeName should be ""

Per the change in WebXR, the "neutral" hand should be referred to as "none". The "hands" node probably should be renamed "handedness"

We tend to think of visual responses only affecting transforms, but it could theoretically be interpolation between any two values. For example, it could be the opacity of a highlight or the base color of a material.

The package has already been renamed; this will bring the repo into alignment

@jacobcdewitt:
Why not use "samsung-odyssey" instead of the VID/PID? That's more human-readable and the convention in this repo seems to be that we should use readable names.

@thetuvix:
Good question!

This naming directly flows from the WinMR Gamepad.id values used in the WebVR era as keys for render model CDNs - for example: https://github.com/BabylonJS/Babylon.js/tree/master/assets/meshes/controllers/microsoft/045E-065D This was done because the WinMR native APIs exposes VID/PID for each controller, and so a UA then didn’t need to be updated when a new WinMR controller came out.

The key question now is whether this still makes sense given the broader profile system, where an app could make use of a more generic profile before UAs update.

Originally posted by @thetuvix in #78

This is probably a small fix, but it's currently low priority as the issue can be worked around by refreshing the page.

Currently the rollup build only runs linting on the files passed as input and jest is only configured to run linting on *.test.js files. This means no linting is currently automatically run on the following files:

• src/testHelpers/testHelpers.js
• rollup.config.js
• rollup-plugin-profiles.js

Linting can currently be performed manually by "npm run lintAll", but this is error prone.

Some thumbsticks/touchpads have a deadzone in the middle to mask jitter in the sensor data. Determine if this information needs to be included in the schema and/or if the source files should add one if not present.

Currently no asset validation is performed; this issue would enable at least walking the asset to ensure required nodes are present.