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

@nondebug 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;

> 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?
 
I think we should expose dual-rumble actuators as 2 elements in `hapticActuators` as well as a non-null `vibrationActuator`.

> 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

The standard can be opinionated on actuator indices like it is for button and axis indices. If we follow the Standard Gamepad example then we should define standard actuators based on layout. That said, we generally can't detect layout programmatically for "dual-rumble" gamepads. APIs usually label them as strong/weak without specifying where they are located. I don't think the standard should care where they are located either since the intent is to vibrate the whole gamepad, not one particular side of it. Still, we need some way for apps to distinguish them.

I would be fine with using the same indices that Android uses (index 0 for strong vibration channel, index 1 for weak vibration channel). I think it makes sense to give these special placement since they are the most common type of gamepad haptic effect.

For gamepads with actuators that aren't intended to vibrate the entire gamepad (like Xbox trigger rumble or Quest Controller Pro) we should probably start thinking about adding GamepadHapticActuator attributes to identify placement instead of relying on standard indices. Perhaps we can lean on OpenXR's concept of semantic paths to describe actuator placement in a generalizable way.

https://registry.khronos.org/OpenXR/specs/1.0/html/xrspec.html#semantic-path

> why should we do it when we can achieve the same level of control by calling playEffect?

`pulse()` should not preempt effects playing on other actuators. With `playEffect()` apps need to issue a new effect each time either actuator's vibration should change. This is fine for dual-rumble but I think it might be cumbersome for trigger-rumble and other actuator configurations.

> 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?

That's fine with me, we can focus on merging `vibrationActuator` and `playEffect()` for now to unblock trigger-rumble. There aren't any implementations yet that implement both `vibrationActuator` and `hapticActuators` so it's probably premature to define their interaction in the main spec. If we keep `hapticActuators` and `pulse()` in the extensions doc then we can iterate on them there.

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

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