Define initial set of generic profiles

[toji]

This supporting PR for #695 defines an initial set of generic XRInputSource profiles that are recommended to be used as a last-resort fallback when describing a device. It's very controller-centric right now, but I don't really object to adding additional profiles like "hand" if everyone things that's useful to define right now.

[thetuvix]

Thanks for filing this @toji!

Can you share more about your concern with a UA returning both "touchpad-thumbstick-controller" and "thumbstick-controller" at the end of their profiles list?

A few points that come to mind for discussion:

• If a UA omits "thumbstick-controller" here for a complex controller like a Windows Mixed Reality controller or Valve Index controller, it would seem to give up potential app compat without a clear counter-balancing benefit. I expect UAs would quickly start to just add this in to support more content, and so it would become a de facto standard anyway.
• In contrast, if the argument is that apps will all need a CDN-powered app-side mapping library anyway in the WebXR 1.0 timeframe for many other reasons, and so we should defer complex designs for now, do profiles need to be a list at all? It would then be the job of such a library and its CDN to enable apps to reason about whether an input source supports "touchpad-thumbstick-controller" or such, including any more complex remappings that may be necessary.

[thetuvix]

Pinging @TrevorFSmith and @NellWaliczek to share their thoughts here.

[TrevorFSmith]

I support this design.

In PotassiumES the input system has two main jobs at runtime:

🌸 Map sets of low level input events into higher level actions
Example:
left-thumbstick-down | right-thumbstick-down | kb-key-23-down | wink + nod -> activate-selected-component

Developers write a JSON file that defines the input->action mapping (with recognizers and filters in the mix) and then at runtime the app framework polls the input system in the game loop.

🌸 Give users with unusual or unexpected hardware a way to map their own inputs to actions (still in development)
Example: People using custom input hardware built into their wheelchairs should be able to use standard web input events (which are already mapped onto their hardware through OS accessibility services) to set up a custom input->action map.

The web app could store this custom map using browser storage or some back-end storage and a cookie or login to recall the map. The user can also download the file for use at a later time.

Developers add a UI element to their app that brings up the custom mapping UI with a file-load/drop-target for previously created mapping files.

So, with this design PotassiumES's input system could iterate through to pick the profile with the highest specificity and route events from the XRInputSource into common input events that app developers and end users with custom hw can map to actions.

[NellWaliczek]

I'm happy with this list. One follow-up comment that can be addressed after VR complete.

[NellWaliczek]

Controllers with this profile must not use the xr-standard Gamepad mapping.

Now that we have named profiles, this restriction is increasingly weird to me. I get that it originally came from the need to have a primary button for triggering the select event. It just seems like we could probably cover that requirement without contorting ourselves around the need for a button in the text.

[NellWaliczek]

I'm ok with addressing this as a separate issue post-VR complete, though.

[toji]

Oh, I meant to revisit this after the latest changes to the xr-standard mapping. Devices with this profile should identify themselves as xr-standard now. Fixed!