Hi Brandon,

> On 22 Apr 2016, at 08:14, Brandon Jones <bajo...@google.com> wrote:


> Finally, I'd like to propose that we add gamepad vibration controls. This has 
> been talked about in the past as well, and the thinking has typically been 
> that the Gamepad API may want to try and use the Vibration API somehow 
> instead of exposing a new interface. However that API doesn't currently have 
> a way to target anything other than the device's default motor (usually for a 
> phone), and I don't see there being much interest in extending it to do so. 
> Still, I don't see much sense in re-inventing this wheel so I suggest 
> exposing the same interface on the Gamepad object.
> partial interface Gampad {
>     boolean vibrate (VibratePattern pattern);
> };

If you have suggestions for improvements you'd like to see in the Vibration 
API, please feel free to open issues in GitHub:


Some specs already reuse parts of the Vibration API. For example, the 
Notifications API reuses and references the vibration pattern, and its 
'validate and normalize' and 'perform vibration' algorithms. We actually added 
some hooks to the Vibration API spec to make that integration possible.

> This is pretty basic as far as gamepad haptics go, but it's also provides a 
> lowest common denominator interface that should be supportable by anything 
> with a motor in it. It gives up some granularity (For example, it doesn't 
> allow developers to trigger the two motors in an Xbox controller 
> individually), but it provides a clean, universal interface that's easy to 
> use and mimics existing features on the web platform.

At the time the spec was crafted, we evaluated devices that were widely 
available and took an intersection of the feature set. That said, we should 
re-evaluate the feature set from time to time and make sure it matches the 
capabilities of the today's devices.


-Anssi (the Vibration API editor)

Reply via email to