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

Feedback on the DeviceOrientation API

From: Rich Tibbett <richt@opera.com>
Date: Fri, 1 Aug 2014 11:58:08 +0200
Message-ID: <CAAsrAZAuAWS_P5UDvxFDcM3-cyZE=LgxDkg=2-TMzXA5hgHSSA@mail.gmail.com>
To: public-geolocation <public-geolocation@w3.org>
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=
Received on Friday, 1 August 2014 09:58:35 UTC

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