Gamepad API Trigger-Rumble Haptics Extension

[gabrielsanbrito]

Request for position on an emerging web specification

Information about the spec

• Spec Title: Gamepad API Trigger-Rumble Extension
• Spec URL: https://w3c.github.io/gamepad/extensions.html
• GitHub repository: https://github.com/w3c/gamepad
• Issue Tracker (if not the repository's issue tracker): Xbox One impulse trigger effects w3c/gamepad#138
• Explainer (if not README.md in the repository): https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/GamepadHapticsActuatorTriggerRumble/explainer.md

Design reviews and vendor positions

• TAG Design Review:
• Mozilla standards-positions issue: Gamepad API Trigger-Rumble Haptics Extension mozilla/standards-positions#656

Bugs tracking this feature

• Chrome Status: https://chromestatus.com/feature/5162940951953408
• WebKit Bugzilla:
• Radar:

Anything else we need to know

We would like to extend the GamepadHapticActuator interface to expose the trigger-rumble capability in the Web for compatible gamepads.

P.S.: I have already sent an email to webkit-dev, but decided to continue the discussion here.

[hober]

I think @beidson & @marcoscaceres have opinions here.

[marcoscaceres]

I'm personally opposed to this proposal (i.e., this position is NOT representative of the WebKit community; I'm posting it as input while waiting for further input from WebKit community members).

Although I'm are generally supportive of enabling haptic feedback, such as "trigger-rumble", on gamepads, I have significant reservations about the (non-standard) GamepadHapticActuator interface on which this proposal relies.

Specifically with the "trigger-rumble" proposal, I'm concerned that it’s targeting a narrow set of hardware. To alleviate this, it would be good to provide a canonical representation, such as an audio file, that can be used to consistently emulated "trigger rumble" across generic gamepads.

Returning to GamepadHapticActuator (and the changes that result directly from adding "trigger-rumble"), I've provided feedback on the design of the API via the W3C and outlined several issues. Some of the issues also appear in the "trigger-rumble" proposal (particularly around .canPlay()).

Lastly, I'm are sympathetic that GamepadHapticActuator has been shipping in Chromium-based browsers for a while despite the API not being a published standard. This situation is quite unfortunate and something the implementers should try to remedy through collaboration at the W3C: the more developers come to rely on the design of GamepadHapticActuator, the higher the chance that the Web Platform will be stuck with it.

I would be open to exploring alternatives to the GamepadHapticActuator, or evolving GamepadHapticActuator into something more useful - as well as looking at how we can enable more haptic effects on gamepad devices.

[marcoscaceres]

Discussed with other folks and our position remains the one I posted above (#1 (comment))... basically, gamepad haptics are good, but we have concerns about GamepadHapticActuator. Marking as opposed for now, but happy to continue the discussion at the W3C.

[cabanier]

As mentioned earlier, the quest browser is exposing haptics and they're use quite a bit by developers.
We just released a new controller that has 3 sets of haptic actuators and each also support frequency.

The main actuator also support audio samples so it could play music or other effects. Was this ever discussed?

[marcoscaceres]

The main actuator also support audio samples so it could play music or other effects. Was this ever discussed?

Yes. The W3C was waiting on a proposal from Microsoft to allow playing audio files:
https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/HapticsDevice/explainer.md

I'm hoping they will move that to the WICG (if they haven't already).

[cabanier]

@marcoscaceres what is the status of haptics? Would it make sense to join the CG or WICG?

[marcoscaceres]

@cabanier, sorry I missed your question. It's still unclear if/where further haptic-related work will happen at this point. A few of us are discussing it as part of WebApps WG, but we are unsure of a venue. It will more than likely be a WICG thing.

In other news, although WebKit were opposed to this API, the vibratorActuator did end up getting implanted in WebKit and shipped in Safari Tech Preview 163 (release notes). The API has been around for a while in Chromium browsers, so it kinda made sense to ship it for web compat... even though we all agree that the design is less than ideal.

At the same time, folks involved with the Gamepad spec don't seek to pursue haptics using above model further... so we will try to figure out where, how how, we go forward from here with something better/more scalable, that better supports the capabilities of newer gamepads.

[cabanier]

Thanks @marcoscaceres
Our newest controller doesn't just have frequency; it's even possible to play music using a special motor.

We don't have an immediate need to have support for this but it would be nice to have in the future.

[hober]

Closing as we've identified our position.

[cabanier]

@hober what do you think of my proposal in w3c/gamepad#186?

[marcoscaceres]

Reopening it on request of Chromium/Microsoft folks. I'll coordinate with @gabrielsanbrito on this.

[gabrielsanbrito]

Hey @marcoscaceres, I have updated the explainer to match the latest version of the Gamepad API spec.

[marcoscaceres]

Changed position to support, as we collaborated in the specification over in WebApps and implement this.