1144674 - allow HAL to report quaternion for rotation/orientation instead of euler angles

Status: RESOLVED FIXED

(Core :: Hardware Abstraction Layer (HAL), defect)

Description

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Android deprecated Sensor TYPE_ORIENTATION in API level 8; the new way to do it is TYPE_ROTATION_VECTOR, which reports a quaternion.  This is a more stable and useful way to report this information (and is directly convertible to the old azimuth/pitch/roll format).

It would be nice to be able to listen to this internally via the Hal, and maybe even modify the web API to allow listening for a quat (or report one as well).

Also helpful would be for direct support for TYPE_GAME_ROTATION_VECTOR, for more accurate game orientation uses, but not as critical.

See http://developer.android.com/reference/android/hardware/SensorEvent.html for details.

Comment 1

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Attachment: visual testcase

Here's a visual testcase showing the problem with not doing this.

1. Open in Firefox for Android
2. Keeping the phone flat, rotate the device. Green/blue stay centered (0), red moves up and down.
3. Tilt the phone left and right.  Blue line (beta) goes up/down, green stays centered.  Ignore red
4. Tilt the phone up and down.  Green line (gamma) goes up/down, blue stays centered.
5. Now hold the phone up in landscape in front of your face ("the VR position").  Doesn't matter if you lock the phone in portrait or not.
6. Blue line (beta) should go to the top, because the phone is now rotated 90 degrees.
7. Tilt phone forward and back in the landscape position.  Observe blue line (beta) going up/down properly with the tilt.  But also see red/green lines going crazy!

Comment 2

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Attachment: Add ROTATION_VECTOR and GAME_ROTATION_VECTOR sensor support

This adds support for ROTATION_VECTOR and GAME_ROTATION_VECTOR to our HAL, and adds Android and Gonk support for reading it.  It is not exposed to the Web here -- a followup patch should change our Orientation sensors to use the ROTATION_VECTOR values converted to pitch/yaw/roll.

It would also be nice to expose GAME_ROTATION_VECTOR to content if available, because its values will be more accurate as they won't be corrected for the magnetic field; that is, its orientation is not aligned to magnetic north, but to an arbitrary axis.  Games will want the precision instead of needing to know where north is.

I plan to use this in WebVR; also it would be nice if our HAL had a way to query whether a particular sensor is available on a device.  (Right now I plan to enable both ROTATION_VECTOR and GAME_ROTATION_VECTOR, and disable R_V if I see a G_R_V value.)

Comment 3

[James Willcox (:snorp) ([e-mail]) (he/him)]

Comment on attachment 8582603 [details] [diff] [review]
Add ROTATION_VECTOR and GAME_ROTATION_VECTOR sensor support

Review of attachment 8582603 [details] [diff] [review]:
-----------------------------------------------------------------

::: mobile/android/base/GeckoAppShell.java
@@ +693,5 @@
> +
> +        case GeckoHalDefines.SENSOR_ROTATION_VECTOR:
> +            if (gRotationVectorSensor == null)
> +                gRotationVectorSensor = sm.getDefaultSensor(Sensor.TYPE_ROTATION_VECTOR);
> +            if (gRotationVectorSensor != null) 

trailing whitespace

@@ +700,5 @@
> +
> +        case GeckoHalDefines.SENSOR_GAME_ROTATION_VECTOR:
> +            if (gGameRotationVectorSensor == null)
> +                gGameRotationVectorSensor = sm.getDefaultSensor(15 /* Sensor.TYPE_GAME_ROTATION_VECTOR */); // API >= 18
> +            if (gGameRotationVectorSensor != null) 

trailing whitespace

::: mobile/android/base/GeckoEvent.java
@@ +564,5 @@
> +                event.mW = s.values[3];
> +            } else {
> +                // s.values[3] was optional in API <= 18, so we need to compute it
> +                event.mW = 1 - s.values[0]*s.values[0] - s.values[1]*s.values[1] - s.values[2]*s.values[2];
> +                event.mW = (event.mW > 0) ? Math.sqrt(event.mW) : 0.0;

It might be useful for us mortals to have some sort of comment explaining what this does :)

Comment 4

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/3e459fb85c8f

Comment 5

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/3e459fb85c8f