You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Gamepad API currently has a proposal for events that would fire on button press/release, which overlaps a bit with our currently proposed use of selectstart/end events. To be clear, the select events fire for inputs other than gamepads and as a result we won't be discarding them. Given that context it's a nice behavioral unification to have them fire for every gamepad button. Also, the select events contain an XRFrame, which is necessary for tracking any timing-sensitive data like device pose. Finally, the state of the gamepad proposal is unclear, with the PR having been opened way back in 2015(!) but being updated as recently as last October.
Still, the fact that these two pairs of events otherwise cover similar functionality means we should do a bit of due-diligence investigation to see if there's any opportunity to merge them.
The text was updated successfully, but these errors were encountered:
After further evaluation it does not seem like attempting to align with gamepad events would be beneficial at this point, nor is it clear that they will be stabilized within the time frame that we are considering. As a result, it seems the answer to the question in this issue's title is "Don't."
To be clear, if gamepad events become a well-supported, popular feature in the future we could easily support them alongside our select events without trouble, though the events themselves would fire from window, which isn't terribly useful for XRSession-scoped input, wouldn't have an indication of what XRInputSource they were related to, and would not contain the XRFrame necessary to evaluate any sort of spatial relationships.
The Gamepad API currently has a proposal for events that would fire on button press/release, which overlaps a bit with our currently proposed use of
selectstart/end
events. To be clear, the select events fire for inputs other than gamepads and as a result we won't be discarding them. Given that context it's a nice behavioral unification to have them fire for every gamepad button. Also, the select events contain anXRFrame
, which is necessary for tracking any timing-sensitive data like device pose. Finally, the state of the gamepad proposal is unclear, with the PR having been opened way back in 2015(!) but being updated as recently as last October.Still, the fact that these two pairs of events otherwise cover similar functionality means we should do a bit of due-diligence investigation to see if there's any opportunity to merge them.
The text was updated successfully, but these errors were encountered: