Support input sources without primary action?

[klausw]

https://immersive-web.github.io/webxr/#xrinputsource-interface currently says:

Each XR input source MUST define a primary action. The primary action is a platform-specific action that, when engaged, produces selectstart, selectend, and select events. Examples of possible primary actions are pressing a trigger, touchpad, or button, speaking a command, or making a hand gesture. If the platform guidelines define a recommended primary input then it should be used as the primary action, otherwise the user agent is free to select one.

Does this really need to be so restrictive? I think there are valid use cases for XR input sources that don't have primary actions.

For example, the VIVE Tracker provides 6DoF poses, but doesn't have any gamepad-style input at all. It would be useful to be able to support such trackers in WebXR, for example for tracked props or as body/leg trackers.

Separately, for transient touch input, I think it would be useful to provide multitouch input, but I think it would be confusing if each finger would produce distinct select events, especially if those end up arriving in orders that applications aren't expecting. (For example, the event sequence could be selectstart#0, selectstart#1, selectend#0, selectend#1). If additional fingers were reported as additional transient input sources, but without select events, multitouch-aware applications could opt in to using them based on inputsourceschange events, but they wouldn't confuse applications that are designed around a single primary input source.

Would it be OK to rephrase that? Maybe something along these lines?

XR input sources are either primary input sources or auxiliary input sources. The system MUST provide at least one primary input source. A primary input source MUST define a primary action. The primary action is [...]

An XR input device is an auxiliary input source if it does not have buttons or other affordances suitable as a primary action. They MAY be provided in addition to primary input sources.

Note: while an overall XR system is required to support at least one primary input source, users are of course free to design experiences that use only auxiliary controllers, or no controllers at all.

[klausw]

For example, the event sequence could be selectstart#0, selectstart#1, selectend#0, selectend#1

Of course, this sequence is something that can already happen for a system with two controllers that each have their own primary input, so ideally applications would be robust enough to deal with that, but I still think it would be odd for screen touch input. By comparison, DOM pointer events have an isPrimary attribute to distinguish the first finger from additional touches, and WebXR could follow that model, but I'm not sure if that's really necessary since the existing inputsourceschange events would make it fairly easy to keep track of when additional transient sources get added and removed.

[klausw]

By comparison, DOM pointer events have an isPrimary attribute to distinguish the first finger from additional touches

I think it's also worth noting that the DOM pointer events reference says that only a primary pointer will produce compatibility mouse events. I think that would be similar in spirit to not producing XR select events for secondary screen touches.

[Manishearth]

XR input sources are either primary input sources or auxiliary input sources. The system MUST provide at least one primary input source. A primary input source MUST define a primary action. The primary action is [...]

Yeah, this works for me. In fact, this is how I thought it worked originally (where there's a primary action for the system, not per-source).

[klausw]

Suggested edits in PR #929, please let me know what you think.