W3C home > Mailing lists > Public > public-geolocation@w3.org > August 2014

RE: Feedback on the DeviceOrientation API

From: Mandyam, Giridhar <mandyam@quicinc.com>
Date: Wed, 13 Aug 2014 13:54:50 +0000
To: Rich Tibbett <richt@opera.com>, public-geolocation <public-geolocation@w3.org>
Message-ID: <CAC8DBE4E9704C41BCB290C2F3CC921A23E45FE7@NASANEXD02E.na.qualcomm.com>
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

Received on Wednesday, 13 August 2014 13:55:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:51:08 UTC