Re: DeviceOrientation Clarification

Jonathan: I think you are right regarding the example using the
acceleration on the z-component instead of y. We should fix the example in
the specification.

Tim

On Mon, Nov 3, 2014 at 10:08 PM, Jonathan Ross <jonross@google.com> wrote:

> Hi,
>
> Thanks everyone for the great feedback. I noticed that a number of the
> threads also touched on the Screen Orientation api
> <https://w3c.github.io/screen-orientation/>. I am also currently working
> at implementing this API for Chrome OS. I'll take this information into
> consideration while working on these.
>
> I plan to identify what issues I encounter while developing these, and to
> provide that feedback. I would certainly like to find a way to make these
> interact in a way that web developers can use them as easily as possible.
>
> Lars, thank you for bringing up axis of device orientation vs the natural
> hardware orientation (portrait/landscape.) I can see this being compounded
> further by convertible devices Where the specification would consider the
> state with an active keyboard to be a landscape device, but where when
> converted to a tablet form factor one might consider it to be a portrait
> device.
>
> Regards,
> Jonathan
>
> On Sat, Nov 1, 2014 at 6:42 AM, Lars Knudsen <larsgk@gmail.com> wrote:
>
>> 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
>> > >
>> > >
>>
>>
>