Re: DeviceOrientation Clarification

I did write something that might make sense to you too a while back:
http://lists.w3.org/Archives/Public/public-web-mobile/2014Apr/0018.html

IMO, it is important with a holistic view when adjusting all orientation
and full screen related specs.

Br
Lars
On Nov 1, 2014 11:26 AM, "Rich Tibbett" <richt@opera.com> wrote:
>
> On 1 Nov 2014 11:19, "Lars Knudsen" <larsgk@gmail.com> wrote:
> >
> >
> >
> > On Sat, Nov 1, 2014 at 10:41 AM, Rich Tibbett <richt@opera.com> wrote:
> >>
> >> Hi Jonathan, Lars,
> >>
> >> On 31 Oct 2014 16:17, "Jonathan Ross" <jonross@google.com> wrote:
> >> >
> >> > Hi,
> >> >
> >> > I am currently working on implementing the DeviceOrientation Event
Specification for Chrome OS.
> >> >
> >> > I wanted to get a clarification on one of the examples. The final
example in Section 2 Introduction:
> >> >
> >> >>> A device is mounted in a vehicle, with the screen in a vertical
plane, the top uppermost and facing the rear of the vehicle. The vehicle is
travelling at speed v around a right-hand bend of radius r. The device
records a positive x component for both acceleration and
accelerationIncludingGravity. The device also records a negative value for
rotationRate.gamma:
> >> >>>
> >> >>>       {acceleration: {x: v^2/r, y: 0, z: 0},
> >> >>>
> >> >>>        accelerationIncludingGravity: {x: v^2/r, y: 0, z: 9.81},
> >> >>>
> >> >>>        rotationRate: {alpha: 0, beta: 0, gamma: -v/r*180/pi} };
> >> >
> >> >
> >> > From the description of the device I would have expected that the
gravity component would be applied to the Y-axis. Giving
accelerationIncludingGravity: {x: v^2/r, y: 9.81, z: 0}. Is that a correct
interpretation?
> >> >
> >> > Furthermore, while testing implementations of the API I have noticed
a discrepancy between the Chrome Android, and the Safari iOS
implementations. Currently Android orients gravity in the same manner as
the specification, with a flat device reporting
accelerationIncludingGravity: {x: 0, y: 0, z: 9.81}. However I am seeing
the gravity reversed with iOS, which reports accelerationIncludingGravity:
{x: 0, y: 0, z: -9.81}.
> >> >
> >> > Currently I am planning to follow the specification and Android
implementations. I wanted to bring this up because the inconsistency could
make the API hard for web developers to use.
> >> >
> >> > Please advise.
> >>
> >> I sent an email to this list in July with the same observations:
> >
> >
> > I feel your pain:
https://groups.google.com/forum/#!msg/mozilla.dev.webapi/Qal4EQ1s2E0/yDM6JbtAGhwJ
> >
> > (been ranting about the faulty specs and implementations for years -
but apparently you will quickly be put on the ignore list if you don't
agree with the spec'er in charge ;))
>
> Tim and I only recently picked up  the editing of this spec. Please know
we are very keen to get some consistency here any way we can.
>
> >>
> >>
http://lists.w3.org/Archives/Public/public-geolocation/2014Jul/0024.html
> >>
> >> I'm also not sure how we proceed here. My current interpretation is
that Chrome for Android is providing the correct values and iOS values are
inverted according to the spec guidelines.
> >>
> >> In that previous email I provided a demo of the problem.
> >>
> >> Is it possible to fix this inconsistency without breaking some
existing content?
> >>
> >> On 31 Oct 2014 16:33, "Lars Knudsen" <larsgk@gmail.com> wrote:
> >> >
> >> > See this nice little compensation lib:
https://github.com/richtr/Full-Tilt
> >>
> >> I wrote this library. I did not include any normalisation between iOS
and Android DeviceMotionEvent.acceleration or
DeviceMotionEvent.accelerationIncludingGravity data as I considered browser
detection the incorrect way to fix inconsistencies at the time (e.g.
if(iOS) then invert accelerometer values). Using browser detection would
also make this library not future compatible in the case that either iOS or
Android want to invert their implementations to provide consistency.
> >>
> >> I'm as uncertain what to do as you both are.
> >>
> >> What could we do? We can add whatever solution we decide on to the
spec of course.
> >>
> >> - Rich
> >
> >