Potential registry format

[NellWaliczek]

A really early stab at how we might define the registry. This will probably end up moving into a different folder, but for now...

I put three sections in the json. The first, is the list of agreed up on generic profiles. The third is the legacy controller names for WebVR.

The interesting part is the second section. "customProfiles" is a terrible name, but in the interest of not getting stuck in the weeds bikeshedding.... the important bit here is that I've got an entry for each hardware device. That entry's value is an array of the strings. The XRInputSource.profiles[0] will be the custom profile key and all the subsequent XRInputSource.profiles elements will be the values of the custom profiles array in order.

A few questions that come to mind...

• Do we want to make a requirement that each customProfile entry must end in a generic profile?
• Do we want to make a requirement that there only be one generic profile in each custom profile's list?
• Should we remove the webvr legacy elements?
• Should we not bother separating the generic profiles at all?

Lots to think about.

[jacobcdewitt]

As discussed in issue #70 , these names are ambiguous about the presence of a grip button. Here is what I have implemented in Chrome, which avoids the ambiguity:
controller
touchpad-controller
thumbstick-controller
touchpad-thumbstick-controller
grip-controller
grip-touchpad-controller
grip-thumbstick-controller
grip-touchpad-thumbstick-controller

This covers all the possible xr-standard Gamepads by specifying whether or not each optional element (grip, touchpad, thumbstick) are present. The trigger button will always be present, so it's not required in the name. JS code could even parse these generic strings to figure out the basic functionality of the controller without even needing to query a registry.

[toji]

I'm supportive of making the presence of a grip button part of the generic profiles. Initially I was worried about a combinatorial explosion of profile strings, but if we limit it to just the xr-standard inputs and list them in the same order each time (as Jacob shows) then it seems very manageable and useful to developers. I have no opinon on the ordering of elements other than to say I'd be fine with the above list as-is. (With the addition of button-controller as we originally had.)

[jacobcdewitt]

Is button-controller supposed to mean a controller with just a trigger button (but no grip button)?

And yes, I agree we should limit the generic profiles to covering functionality from xr-standard inputs. If developers want to know about additional optional buttons (such as Oculus touch A/B buttons), then they need to look at the more specific profile strings.

[toji]

Yes, button-controller would be a device with only a trigger button (or only a primary button, even if it wasn't trigger-shaped.) It would basically be the fallback for an xr-standard device where none of the other generic profiles applied. The only device I'm aware of that it would apply to off the top of my head is the HoloLens clicker, but regardless of how common it is it's a decen idea to have a clear plan for how to address any devices that fit that description.

[jacobcdewitt]

This happens to be the "Samsung Odyssey", which could be exposed with a human readable name of "samsung-odyssey".

[NellWaliczek]

During the WebVR timeframe, these were the strings that Microsoft chose to expose. @thetuvix needs to weigh in on what Microsoft actually wants here.

[NellWaliczek]

In the realm of "huh, that's an eerie coincidence", I'd actually started to ponder this exact problem earlier today. It's also somewhat related to this issue I filed in the gamepad repo a while back immersive-web/webxr-gamepads-module#3.

In any event, after talking it over with @toji a bit, I'd like to propose the following generic profile names.

        "xr-unknown",
        "xr-standard", 
        "xr-standard-touchpad", 
        "xr-standard-thumbstick", 
        "xr-standard-touchpad-thumbstick",
        "xr-standard-grip",
        "xr-standard-grip-touchpad", 
        "xr-standard-grip-thumbstick", 
        "xr-standard-grip-touchpad-thumbstick"

Our reasoning behind the names was based on several factors.

1. The hardware-based (non-generic) profile names all start with a vendor id and the generic ones did not. Now it's not super likely that a company named "touchpad" would start shipping XR hardware, but I guess you never know.
2. All xr-standard controllers are required to support a primary button so we didn't think it necessary to call it out specifically. All other allowable combinations of additional components are covered by items in this list.
3. It is allowed to have an XRInputSource.gamepad even if it isn't xr-standard, so it's possible that we'll need at least one string to indicate that situation. However, it is also possible that when we address Reconsidering the rules for when XRInputSource.gamepad should be null webxr-gamepads-module#3 that this will no longer be necessary, but i'm not entirely sure.

Lastly, given that this list of generic profiles ended up fairly tightly tied to the xr-standard mapping, I'd like to suggest we move the definition of these particular generic profiles into the webxr-gamepads-module. To reiterate something we've said before though, the profile ids are not unique to gamepad-based input sources. Which means we'll need to make it very clear in the module text that the gamepad-related generic profiles list does not exhaustively cover all potential XRInputSources, but that it only exhaustively covers profileIds allowed by an XRInputSource with a non-null gamepad.

[mounirlamouri]

@kearwood is this something Mozilla has an opinion on?

[jacobcdewitt]

ping ...

[NellWaliczek]

Closing in favor of #78