Re: Feedback on the DeviceOrientation API

I guess it makes sense to separate the magnetic field data, especially
because some apps do not seem to require alignment with the magnetic pole.
However I am somewhat concerned about how the apps that do require absolute
orientation would compute it reliably if we always set absolute=false. I
think this is something to consider in more detail.

Tim


On Wed, Aug 13, 2014 at 2:54 PM, Mandyam, Giridhar <mandyam@quicinc.com>
wrote:

> Hello All,
> Please note that this suggestion has been out there for ten days now with
> no additional comments.  Please try to provide feedback to the list on
> Rich's proposals below by August 23.   In particular, if you know of any
> web applications currently using DeviceOrientation that would break without
> magnetometer input, please make the group aware of them.
>
> -Giri
>
> -----Original Message-----
> From: Rich Tibbett [mailto:richt@opera.com]
> Sent: Friday, August 01, 2014 2:58 AM
> To: public-geolocation
> Subject: Feedback on the DeviceOrientation API
>
> We have received feedback that impacts how we should be calculating and
> delivering DeviceOrientation data for VR and 3D gaming use cases on the web.
>
> The first issue [1] is there is currently no way for web pages to interact
> with the magnet button that is present on Cardboard VR headsets. Native
> applications do have a way to detect proximal magnetic field changes that
> can be used to represent a 'click' as demonstrated in the video at [2].
>
> Secondly, the presence of a strong magnet (i.e. the magnet button) placed
> close to a user's device can cause DeviceOrientation to behave incorrectly
> where DeviceOrientation values are calculated with Magnetometer sensor
> readings. [3] outlines the general problem using Magnetometer in
> DeviceOrientation data calculation can lead to.
>
> The second issue above is not currently a problem in iOS browsers since
> they do not use the magnetometer to calculate DeviceOrientation data. Other
> web browsers e.g. Chrome, Opera and Firefox for Android do use the
> magnetometer to derive DeviceOrientation data that can lead to the magnet
> interference issue described above. We should be looking for ways to
> reconcile these fundamentally different implementations so
> DeviceOrientation data means the same things across all web browsers.
> DeviceOrientation should ideally always be compass-oriented or it should
> always not be compass-oriented - but it should not be a mix of the two.
>
> I'd like to propose the following changes to the DeviceOrientation Events
> API based on the feedback above and on the current implementation situation:
>
> 1. We add a requirement to the specification to say that we must not use
> magnetometer data in the calculation of DeviceOrientationEvent alpha, beta
> and gamma properties. Thus, the DeviceOrientationEvent.absolute property
> will always become 'false'.
> This change would align all implementations with each other. It would also
> not break existing web applications with the assumption they are not
> relying on _world-oriented_ device orientation data and covers the major
> use cases for non-compass-oriented VR and 3D gaming on the web.
> In practical terms this change would mean calculating DeviceOrientation
> data using a combination of Accelerometer, Gyroscope but not Magnetometer
> at all times.
>
> 2. We introduce a new API for web developers to obtain continuous
> magnetometer sensor data readings from their browser that can be used to
> a.) detect proximal magnet button 'clicks', b.) be used more generally to
> interact with proximal magnetic fields and
> c.) be used in
> combination with other provided sensor data e.g. gravity to perform sensor
> fusion to derive world-oriented device orientation (i.e. given gravity and
> magnetometer sensor values a web developer could derive world-oriented
> device orientation based on e.g. [4]).
>
> Making these changes to DeviceOrientation would not break existing web
> pages that rely on DeviceOrientation Events assuming they do not rely on
> that also containing the compass heading. These changes also allow us to
> cleanly delineate VR and 3D gaming use cases (things that don't rely on
> compass direction) from compass-oriented use cases (things we could then
> calculate with additional sensor data input from e.g. a Magnetometer Events
> API).
>
> Feedback and thoughts from others on this list would be very helpful in
> deciding how we can reconcile DeviceOrientation implementations without
> breaking existing web code, cover VR and 3D gaming use cases as well as
> compass-heading use cases.
>
> br/ Rich
>
> [1] https://mail.mozilla.org/private/web-vr-discuss/2014-July/000056.html
>
> [2] https://www.youtube.com/watch?v=DFog2gMnm44&feature=youtu.be&t=19m00s
>
> [3] https://code.google.com/p/chromium/issues/detail?id=397824
>
> [4]
> https://github.com/android/platform_frameworks_base/blob/8868d1290afd96997f=
>
> ef671f4a7a4c7bbf94fa1a/core/java/android/hardware/SensorManager.java#L776-L=
> 970
>
>