Rotation logic needs to be tuned for less sensitivity

[Pat McGowan]

The current logic controlling app rotation is too sensitive resulting in a rotation when its not desired.
The angle needs to be increased (we are doing 45, android seems more like 60), and perhaps a time period used to determine its a purposeful rotation (.3 to .5 secs?).

Also a rapid movement or bumping of the phone results in the UI jumping around. Only a full rotation should be used.

[kevin gunn (kgunn72)]

should this be in the shell or platform-api ?

[Michał Sawicz (saviq)]

The shell currently has nothing to do with rotation, so marking Invalid for unity8. And even when unity get some rotation logic (mostly around rotation lock and mediating rotation between apps), the actual value of device orientation will, I think, still come from the sensors.

[kevin gunn (kgunn72)]

just my 2 cents - for consistency it would seem good to build in some app rotation tuning into platform-api which would help effect all apps. however, it would seem then you would almost want 2 distinct interfaces which apps would use to get sensor info...1) "window system rotation" events and then 2) "raw rotation" events for game or instant ui feedback cases

[Thomas Voß (thomas-voss)]

Right now, we are not using the fusioned orientation sensor provided by the Android HAL and Android SensorService but instead do the thresholding ourselves in:

  * http://bazaar.launchpad.net/~phablet-team/qtubuntu-sensors/trunk/view/head:/plugins/sensors/core_orientation_sensor.cpp

For that, our calculations might well be too sensitive to outliers and we should instead switch to the fusioned orientation sensor available from Android, see:

  * http://androidxref.com/4.4.2_r2/xref/hardware/libhardware/include/hardware/sensors.h#286

Together with some low-pass filtering that would give us continuous device orientation values in ° in the range of [0, 360]. Finally, I think the shell should apply some interpretation and translate the continuous readings into discrete screen orientation values, like:

  * ScreenOrientation::Landscape
  * ScreenOrientation::Portrait
  * ScreenOrientation::ReversedLandscape
  * ScreenOrientation::ReversedPortrait

and provide state changes to applications, too. I think both continuous and discrete information are useful to app authors. HOwever, the interpretation of screen orientation should be carried out in a central place and not necessarily by individual apps or toolkits (for the sake of synchronization).