Re: [gamepad] New feature proposals: pose, touchpad, vibration

Do we want to know the value of the press? Does the API for the Steam
Controller, for example, return the force of the press as a float? The
reason I ask is because with Touch events, there's a `force` property on
the `Touch` interface:
https://developer.mozilla.org/en-US/docs/Web/API/Touch/force

We should probably introduce something similar to the Gamepad API.

The `Gamepad.vibrate` proposal generally looks good, but I have a few
concerns. `navigator.vibrate(pattern)` works well for pulse vibrations of
varying durations and pause intervals, but the API doesn't allow the
following:

1. vibrating at a higher/lower _strength_ (i.e., every vibration is emitted
at the same strength, but you might want to do neat effects such as fading
in and out)
2. selecting which vibration motors (haptic axes) to vibrate (e.g., with
controllers that allow haptic feedback in different regions, such as
left/right/top/bottom; a perfect example is the PlayStation DualShock
controllers)

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

Brandon, you addressed my #2 above, but my concern is once the API is
changed, it's going to be hard to change it again. If you take a look at
all the content libraries out there for the Gamepad API, there's a
ridiculous amount of logic and special casing web developers are having to
do just between the Firefox and Chrome implementations - and between
Windows and Mac.

We already have `GamepadButton`, but perhaps we should have a `GamepadAxis`
and _there_ is where we should add a `vibrate` property for each haptic
axis. There are probably other ways of handling this, but just a thought.

Those are my initial thoughts. If I think of anything else, I'll let y'all
know.


On Thu, Apr 21, 2016 at 10:14 PM, Brandon Jones <bajones@google.com> wrote:

> I'd like to propose the addition of several new features to the Gamepad
> API, primarily born from needs that have been identified while developing
> the WebVR spec <http://mozvr.github.io/webvr-spec/>, but which also cover
> topics that have been under discussion in the past but deemed lower
> priority for one reason or another.
>
> First, I'm proposing that we add an optional "pose" object to the the
> Gamepad interface that would expose all the information necessary to track
> a controller with 3 Degree of Freedom or 6 Degree of Freedom tracking
> capabilities. The primary motivator for supporting this information is to
> allow devices like HTC Vive controllers or Oculus Touch to be exposed, but
> the same structure could also expose motion and orientation data for
> devices such as Wii, PS3, and PS4 controllers, as well as anything else
> that had a gyroscope and/or accelerometer.
>
> interface *GampadPose* {
>   readonly attribute Float32Array? position;
>   readonly attribute Float32Array? linearVelocity;
>   readonly attribute Float32Array? linearAcceleration;
>
>   readonly attribute Float32Array? orientation;
>   readonly attribute Float32Array? angularVelocity;
>   readonly attribute Float32Array? angularAcceleration;
> };
>
> partial interface *GampadPose* {
>   readonly attribute GamepadPose? pose;
> };
>
> Position is given in meters from a device-specific origin. Velocity and
> acceleration are given it meters per second, and orientation is a
> quaternion. If provided all arrays should have 3 elements to except the
> orientation, which has 4.
>
> The proposed pose interface largely mirrors the VRPose
> <http://mozvr.github.io/webvr-spec/#interface-vrpose> interface from the
> WebVR spec, but drops the timestamp since that's already provided on the
> Gamepad interface itself. The VRPose interface could conceivably be used
> directly, but I'm assuming that we'd rather not have a dependency on a
> separate work-in-progress spec.
>
> Second, I'd like to see the API more explicitly support devices that have
> touchpads. It's my feeling that the existing axis array is sufficient for
> exposing the touch position, but we need a way to indicate if the touchpad
> is currently being touched to disambiguate a value of zero from no input.
> This can be handled currently by assigning a button to report pressed =
> true when the touchpad is touched, but since many touchpads also can be
> clicked as a button you end up with two buttons associated with a single
> input. I'd like to proposed that we extend GamepadButton with a "touched"
> boolean to make this case explicit.
>
> interface *GampadButton* {
>   readonly attribute boolean pressed;
>   readonly attribute double value;
>   readonly attribute boolean touched;
> };
>
> For non-touch controls it seems sensible that this would always report
> false.
>
> 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
> <https://w3c.github.io/vibration/> 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
> <https://w3c.github.io/vibration/#idl-def-VibratePattern> pattern);
> };
>
> 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.
>
> I've included several developers that have been participating in WebVR's
> development to provide some feedback from that end of things. These are
> some reasonably large additions, but they can be layered on to the API as
> it stands today without breaking backwards compatibility and cover features
> that have been discussed as possible additions previously. Hopefully we can
> figure out a way to incorporate them that works for everyone.
>
> --Brandon
>