search

immersive-web / webxr-gamepads-module

Repository for the WebXR Gamepads Module
https://immersive-web.github.io/webxr-gamepads-module
Other
30 stars 10 forks source link

Is xr-standard's button 0 meant just for triggers or also for other primary buttons? #17

Closed thetuvix closed 4 years ago

thetuvix commented 4 years ago

Also I think we were intending a restriction that the first entry must be a trigger not a face button.

So perhaps just:

  • Primary Trigger
  • Primary Squeeze
  • Primary Touchpad
  • Primary Thumbstick

WDYT? Too confusing?

Originally posted by @NellWaliczek in https://github.com/immersive-web/webxr-gamepads-module/pull/14

Manishearth commented 4 years ago

Both I and @toji feel like the answer here is "yes"

NellWaliczek commented 4 years ago

@thetuvix I'm inclined to agree with Brandon on this one, but I want to make sure you're ok with the change since you had some concerns when originally discussed.

thetuvix commented 4 years ago

Sounds good to me. I can make a small PR to fix this up.

Manishearth commented 4 years ago

Does Daydream's clicky thing count as a trigger?

toji commented 4 years ago

No. Daydream's main button is the touchpad. It will be mapped to buttons[2], but still fire the select events. The app and home buttons are reserved by the UA and OS respectively.

Yes. This is profoundly weird. At this point it's a self correcting problem, though.

Manishearth commented 4 years ago

@toji hmm, the PR here is requiring a primary trigger at buttons[0], should that be changed?

toji commented 4 years ago

No, that should be fine for two reasons:

  1. The Daydream controller will not report itself as xr-standard, and that text only applies to xr-standard devices.
  2. select events are not explicitly bound to only a primary trigger, which is why we have all the language about identifying a "primary (select) action".
Manishearth commented 4 years ago

Sounds good. I was careful to make sure that PR implies that the primary trigger/squeeze MUST trigger the primary actions, but others may as well.

toji commented 4 years ago

Seems like this can be closed now that #24 is merged.

thetuvix commented 4 years ago

I'm fine for now to run with the onselect and onsqueeze events and hope that most sites power their UIs with those rather than Gamepad buttons, given the group's broader decisions around not surfacing Gamepad instances for non-controllers, such as detected hands. However, my background concern remains that we're drawing a somewhat arbitrary distinction between "buttons" from hands (e.g. select/squeeze) and "buttons" from controllers (e.g. select/squeeze) that may lead to a split in which web content supports which headsets.

If we ultimately find that too much WebXR content is making assumptions about physical gamepads specifically, UAs on hand-focused devices like HoloLens may be forced to implement virtual "Gamepads" to get content compatibility. That would be a key data point for us to ensure WebXR's post-Gamepad input API better unifies controller and hand input.