- From: Matt Reynolds <notifications@github.com>
- Date: Thu, 09 Jun 2022 15:48:47 -0700
- To: w3c/gamepad <gamepad@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/gamepad/pull/163/review/1002081681@github.com>
@nondebug commented on this pull request. > </p> <pre class="idl"> [Exposed=Window] interface GamepadHapticActuator { readonly attribute GamepadHapticActuatorType type; + boolean canPlayEffectType(GamepadHapticEffectType type); + Promise<GamepadHapticsResult> playEffect( + GamepadHapticEffectType type, + optional GamepadEffectParameters params = {}); Promise<boolean> pulse(double value, double duration); I'm fine with removing pulse() since I think there are no actual implementations. Chromium doesn't implement it, Firefox has IDL but it's not hooked up on any platforms. I'm not sure we even need a "pulse" effect. In practice, far more gamepads use two-channel "dual-rumble" haptics than single-channel "pulse" haptics. Reading the [Firefox bug](https://bugzilla.mozilla.org/show_bug.cgi?id=680289) it's not clear to me how we arrived at the single-channel version currently in extensions.html. I'd lean toward removing pulse() and having applications send "dual-rumble" effects with equal strongMagnitude and weakMagnitude values since that's what the user agent would likely do anyway. -- Reply to this email directly or view it on GitHub: https://github.com/w3c/gamepad/pull/163#discussion_r894020198 You are receiving this because you are subscribed to this thread. Message ID: <w3c/gamepad/pull/163/review/1002081681@github.com>
Received on Thursday, 9 June 2022 22:48:59 UTC