Should we use "samsung-odyssey" instead of the VID/PID?

[thetuvix]

@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

[jacobcdewitt]

When I was talking to @toji about this a while ago, I think he made the point that exposing a VID/PID string for controllers means that UAs could still differentiate between devices without needing updates every time a new controller comes out.

However, most of the functionality from the controllers is explained by the xr-standard gamepad mapping and the generic profile names that can be constructed at runtime by the UA based on what capabilities are detected. So, exposing VID/PID might be overkill, especially if we also try to expose human-readable names in some cases.

[thetuvix]

Yea - I believe that VID/PID was the right answer here in WebVR, when there was no XRInputSource.profiles list with fallback elements. However, it came with the standard downsides of giving apps detailed output values about the current device, encouraging apps into compat traps around particular hardware of the era, rather than falling back gracefully.

Now in WebXR, when a new controller design of any sort comes out, there is a clear path to follow, providing a reasonable fallback until UAs update:

For example, the Samsung Odyssey controller is a design variant of the standard Windows Mixed Reality controller. Both controllers share the same input layout. As a result, the profiles for a Samsung Odyssey controller could be: ["samsung-odyssey", "windows-mixed-reality", "touchpad-thumbstick-controller"]. The appearance of the controller is most precisely communicated by the first profile in the list, with the second profile describing an acceptable substitute, and the last profile a generic fallback that describes the device in the roughest sense. (It's a wand with a touchpad and thumbstick.)

Right out of the gate, pages would fall back to either "windows-mixed-reality" or "touchpad-thumbstick-controller" rendering and input handling. Within 6 weeks, browsers would then add support for this controller (or even better, just merge in the latest OpenXR-to-WebXR mapping from #81) and they'll have the optimal support.

[thetuvix]

Here is my proposal for the Samsung and non-Samsung Windows MR controllers:

• Samsung: ["samsung-odyssey", "microsoft-mixed-reality", "generic-trigger-touchpad-thumbstick"]
• Non-Samsung: ["microsoft-mixed-reality", "generic-trigger-touchpad-thumbstick"]

UAs would map the OpenXR /interaction_profiles/microsoft/motion_controller path to WebXR's "microsoft-mixed-reality" profile in the absence of any more specific OpenXR interaction profile path known to the UA, providing a reasonable fallback for future Windows MR controllers. Other XR platforms could follow a similar approach for their own present and future controllers.

It does feel somewhat odd in the proposal above to treat today's "non-Samsung" controller assets as the default Windows MR motion controller for all time, although I suppose that is something that can also evolve over time in any asset CDN.

Thoughts? If this looks sensible, I can submit a PR.

[jacobcdewitt]

@thetuvix , your profiles for Samsung and Non-Samsung LGTM

[jacobcdewitt]

Actually, I believe the last entry in both Samsung and Non-Samsung arrays should be "generic-trigger-grip-touchpad-thumbstick" since the controllers do have a grip button.

[NellWaliczek]

It does feel somewhat odd in the proposal above to treat today's "non-Samsung" controller assets as the default Windows MR motion controller for all time, although I suppose that is something that can also evolve over time in any asset CDN.

The CDN is for the merged profiles that come out of the assets package. If I'm understanding the purpose of a registry right, we should really only be thinking about modifying existing profiles under extraordinary circumstances. Given that, are you still ok with this approach?