Re: [w3c/gamepad] spec vibrationActuator gamepad extension (#68)

This all looks pretty sensible for handling the common case of a gamepad with weak+strong rumble motors, and it seems like it'll provide some extension room for handling more interesting things. I don't know of a lot of other haptic designs in the wild aside from:
* The Xbox One controller, which has the usual dual rumble motors + two more "impulse triggers", one near each trigger button. In the past I hadn't seen any API that actually exposed them (since I don't have access to the Xbox One SDK), but it looks like Microsoft exposes them via [the WinRT Gamepad APIs](https://docs.microsoft.com/en-us/uwp/api/windows.gaming.input.gamepadvibration) nowadays.
* The Nintendo Switch Joy-Cons, which have "HD rumble", which is apparently provided by a [linear resonant actuator](https://blog.somaticlabs.io/how-it-works-linear-resonant-actuators/) and the API involves loading waveforms representing the haptic (an LRA is functionally very similar to an audio speaker).
* The Steam Controller also has LRAs, one under each touchpad, but they seem to be dual-axis actuators. ([The iFixit teardown](https://www.ifixit.com/Teardown/Steam+Controller+Teardown/52578#s117509) says the touchpads are [Cirque GlidePoint TM040040s](http://www.cirque.com/glidepoint-circle-trackpads), and the Cirque page mentions that those are compatible with [Alps HAPTIC Reactor drivers](http://www.alps.com/prod/info/E/HTML/Haptic/), which look like what's in the photo.) I'm not familiar with the Steam Controller API, but the API contains methods like [`TriggerHapticPulse`](https://partner.steamgames.com/doc/api/ISteamController#TriggerHapticPulse), which seems to offer only a simplistic rumble-like interface to the LRAs. There's also a [`TriggerVibration`](https://partner.steamgames.com/doc/api/ISteamController#TriggerVibration) which is a very simple interface that simply lets you turn on the left and right rumble motors for a controller for a period of time.
* Old-style force feedback joysticks, which had [super complicated APIs](https://msdn.microsoft.com/en-us/library/windows/desktop/ee417563(v=vs.85).aspx) for creating and playing effects. I'm not sure if controllers like this are even manufactured anymore.

In any event, most of those seem like they could be handled with future extensions to this API. The only thing I'd worry about is that if code in the wild adds support for `dual-rumble` haptics but then the spec gets extended to add something more complex (even just the 4 rumble motors in the Xbox One, say) there doesn't seem to be a fallback path so that existing code can work with newer devices.

What if instead of having `readonly attribute GamepadHapticActuatorType type` on `GamepadHapticActuator` we instead had something like `bool canPlayEffectType(GamepadHapticEffectType type)` or a WebIDL setlike type that gave the set of `GamepadHapticActuatorType` or `GamepadHapticEffectType` values that were supported? With an interface like that, users could detect if a device supports `dual-rumble` and then use it, and if support for a more complex haptic is added to the spec and implemented by browsers, browsers could have the device support *both* the newer type *and* the `dual-rumble` type, so existing code would work with newer devices, and new code could feature-detect for `quad-rumble` or whatever if it wanted to support that.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/gamepad/pull/68#issuecomment-371213927