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

Gamepad button events #4

Open
NellWaliczek opened this issue Jul 19, 2019 · 2 comments
Open

Gamepad button events #4

NellWaliczek opened this issue Jul 19, 2019 · 2 comments
Milestone

Comments

@NellWaliczek
Copy link
Member

This issue was raised in discussions on immersive-web/webxr#692 and was requested to be tracked separately.

The current spec is defined such that XRInputSources are designated to have a single primary input that will trigger the select, select-start and select-end events. Additionally, some XRInputSources may have their gamepad attribute populated with a Gamepad that has buttons, touchpads, and thumbsticks. Other than the gamepad component designated as primary, none of these other components are spec'd to fire events.

This issue tracks deciding if that is something we'd like to change and which approach to take. There may be others, but the following three are the current approaches under discussion:

  1. Fire select events for all buttons on a Gamepad and add a buttonIndex to the select events indicating which button caused the event. The downside of this approach is that developers who only care about a primary select will get events for additional gamepad buttons they don't care about. The upside of this approach is it introduces very little additional API surface area.
  2. Create new events to be registered for gamepad buttons. When the primary button is pressed, it would fire the originally designed select events as well as the new events. When other buttons are pressed, only the new events would be fired. The downside to this approach is that it would be a lot more spec text and design work. The upside is that it provides a clear signal that only developers who care about would listen to.
  3. Try to coordinate with the Gamepad API which is considering events in a future api version. The downside is that the timelines for when this would be available seem unclear and potentially far off. The upside is that we wouldn't have to parallel mechanisms that behave differently based on where the Gamepad was retrieved from. This approach was originally ruled out in Determine how to use Gamepad events, if at all. webxr#551
@NellWaliczek NellWaliczek self-assigned this Jul 31, 2019
@NellWaliczek NellWaliczek transferred this issue from immersive-web/webxr Aug 9, 2019
@cwilso cwilso added this to the September 2019 milestone Aug 19, 2019
@cwilso
Copy link
Member

cwilso commented Aug 21, 2019

/agenda. (Just testing, pay no attention)

@probot-label probot-label bot added the agenda label Aug 21, 2019
@cwilso cwilso removed the agenda label Aug 21, 2019
@NellWaliczek NellWaliczek removed their assignment Oct 9, 2019
@toji
Copy link
Member

toji commented Oct 9, 2019

Discussed with the Gamepad group at TPAC and it doesn't look like gamepad events are on their roadmap for a while. Moving this to future are a result.

@toji toji modified the milestones: October 2019, Future Oct 9, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants