Re: [w3ctag/design-reviews] Gamepad API input events (#662)

@torgo Chrome Status should have "Positive" for Firefox, referencing [Ted's comment](https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0091.html) on the public-webapps mailing list. That's pretty old so I've submitted a [standards position request](https://github.com/mozilla/standards-positions/issues/554) and will update the status once that's resolved.

I haven't heard from Safari yet.

@kenchris, please take a look at [this doc](https://docs.google.com/document/d/1rnQ1gU0iwPXbO7OvKS6KO9gyfpSdSQvKhK9_OkzUuKE/edit) for our updated thoughts on how pressure-sensitive buttons and axis changes should be handled. The proposal in the explainer (called Proposal 1 in the doc) is probably not the most useful for developers since it makes it hard to get an accurate picture of the current gamepad state without adding unnecessary latency.

A typical gamepad is implemented using the HID protocol (or something like it) where all button and axis inputs are delivered in a single packet. If we fire separate events for each button and axis then it makes it harder to understand which change events are from the same update. For example, if you're handling joystick axes then you always want to handle the X and Y updates from the same update at the same time. If you try to handle X and Y updates sequentially, you'll trace out a stairstep pattern which is a poor representation of the actual joystick movement. It's possible to work around this, but it means you have to delay handling some inputs until you're sure you've received all the relevant events.

Pointer events avoid this issue by delivering X and Y axis updates in the same **pointermove** event. To follow the same pattern, we should combine all axis changes into a single **axesmove** event. And since some buttons can behave like axes, we should include them as well. Proposal 2 combines everything into a single event (we called it "change") that's fired on every input frame if there was any change to any button or axis.

Currently I'm leaning toward Proposal 3 which keeps **buttondown**/**buttonup** events along with the **change** event. It's rare that you would ever want to subscribe to all of them since the change event would include all the same information included in buttondown/buttonup but I think it does the best job of satisfying everyone's use cases.

> buttonrelease and buttonpress makes more sense as names

Those seem reasonable and I'm open to changing the names. I prefer buttondown/buttonup because it keeps the API more consistent with mousedown/mouseup and pointerdown/pointerup.

> adaptive triggers

DualSense adaptive trigger haptics, Xbox Impulse Triggers, Switch HD Rumble and other advanced haptics aren't supported through the Gamepad API. There's a Microsoft Edge proposal for a [Haptic Device API](https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/HapticsDevice/explainer.md) that we're hoping we can adopt in order to support more advanced haptics.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/662#issuecomment-905904873