Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expose events for a squeeze(grip) action #876

Closed
Manishearth opened this issue Oct 14, 2019 · 2 comments · Fixed by #893
Closed

Expose events for a squeeze(grip) action #876

Manishearth opened this issue Oct 14, 2019 · 2 comments · Fixed by #893
Labels
fixed by pending PR A PR that is in review will resolve this issue.
Milestone

Comments

@Manishearth
Copy link
Contributor

(See immersive-web/webxr-gamepads-module#2 for the "squeeze" naming if unfamiliar)

A couple of us discussed this a bit at TPAC: We think it would be useful to expose a set of squeeze events like we have select events, for a "primary squeeze" action (currently defined in the gamepads module). This basically exposes an event for buttons[1] (if nonempty) just as select is an event for buttons[0]. Devices would not be required to trigger this event (unlike the primary action, which is mandatory).

Select and squeeze seem to be the two main webxr-exposed buttons that are common across most devices and have familiar and uniform meanings (it wouldn't make as much sense to expose, say, a "B button pressed" event)

This is also good for AR devices that wish to expose hands as input sources: these hand-input-sources do not have gamepads, but can have select or squeeze events. We eventually need to come up with a way to expose articulated hand tracking, but a lot of applications need just one or both of these events to work, without needing gamepad support.

cc @thetuvix @NellWaliczek

@Manishearth Manishearth changed the title Expose events for a grip/squeeze action Expose events for a squeeze(grip) action Oct 15, 2019
@toji
Copy link
Member

toji commented Oct 16, 2019

Minor clarifying note: addEventListener() is perfectly happy to accept unknown event types, so adding a new event like this after shipping is not backwards compatibility breaking.

@Manishearth
Copy link
Contributor Author

Fixed by #893

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
fixed by pending PR A PR that is in review will resolve this issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants