Re: [w3c/gamepad] Move vibrationActuator to the main spec (PR #190)

@gabrielsanbrito commented on this pull request.



> +        <dfn>Gamepad</dfn> interface
+      </h2>
+      <p>
+        This interface defines an individual gamepad device.
+      </p>
+      <pre class="idl" data-cite="HR-TIME">
+        [Exposed=Window, SecureContext]
+        interface Gamepad {
+          readonly attribute DOMString id;
+          readonly attribute long index;
+          readonly attribute boolean connected;
+          readonly attribute DOMHighResTimeStamp timestamp;
+          readonly attribute GamepadMappingType mapping;
+          readonly attribute FrozenArray&lt;double&gt; axes;
+          readonly attribute FrozenArray&lt;GamepadButton&gt; buttons;
+          [SameObject] readonly attribute GamepadHapticActuator? vibrationActuator;

When trying to write this, I felt like it is a little bit confusing to have both  a `FrozenArray<GamepadHapticActuator> hapticActuators` and a `GamepadHapticActuator vibrationActuator` on the the Gamepad interface. For example, to keep consistency, if we decide to also expose `hapticActuators`, should the two dual-rumble motors also be individually exposed as 2 extra elements of the `hapticActuators` array? If that is the case, why should we do it when we can achieve the same level of control by calling playEffect? We can activate only one of the motors with:
```js
gamepad.vibrationActuator.playEffect("dual-rumble", {
        duration: 1000,
        strongMagnitude: 0.5,
 });
```

As mentioned in #148, the Quest Controller Pro has 3 haptic actuators (one in the grip, one in the thumb rest, and another in the trigger). I see that the `pulse()` proposal was made some time ago already. Maybe, this type of controller could take advantage of the trigger rumble extension proposed earlier (#138). Another issue that I see with the `hapticActuators` approach is that there is no standardized way (yet) for us to identify the actuators (which one is the left trigger? which one is the right ERM?) and actuate the desired one. 

For now, I would suggest to postpone adding the `hapticActuators` array and the `pulse()` method to the Gamepad spec and, instead, keep `pulse()` in the Gamepad Extensions document inside a partial GamepadHapticActuator Interface. Later on we can discuss further how to support both `hapticActuators` and `pulse()`. What do you think?

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

Message ID: <w3c/gamepad/pull/190/review/1733720458@github.com>