History:
  - There was resistance from calculating the hinge angle in the EC, so the Chrome process had to listen to all accelerometer events to determine this.
  - 100ms was selected in order to support tablet mode. For both the transition to tablet mode, and rotations while in the mode, we did not want to hit 150ms latency as that would have a negative user experience. Relayout is expensive, so we went with 100ms to give a large remaining budget to that

So there are a few things which currently stop us from using a slower read time for the accelerometer while idle.

Ideally the Chrome process only listens to the accelerometer either once Tablet Mode has triggered, or when the W3C Screen Orientation API[1][2] is active.

1) We need one source of hinge angle filtering/calculation. Ideally the EC sends the hinge calculation to Chrome. This would stop the current need to listen to accelerometer events.
2) We also need to be able to vary the rate of accelerometer reading at runtime. So that we can vary the rate between simple device rotations and the screen orientation api. chromeos/accelerometer/accelerometer_reader.cc doesn't support that yet
3) Right now the calculations are done on the blocking thread. So a higher rate of reads isn't possible, and it's in general bad, issue 461433 tracks the need to shift this onto its own thread.


+oshima@ I'm not aware of what developer resources are available to look at this.


[1] https://w3c.github.io/screen-orientation/
[2] content/browser/screen_orientation/screen_orientation_provider.h

Thanks for the detailed background.

1) looks like the ideal solution, but needs change in EC and there was resistance.
3) may solve blocking issue, but does not eliminate browser background cpu and power usage as the calculation still exists.
2) seems to be a partial solution. In tablet mode, 100ms read period ensures good rotation user experience. In laptop mode, longer read period (eg 1000ms) can reduce calculation activities if slightly longer transition latency from laptop mode to tablet mode is permitted.

+gwendal@ to comment more on the EC aspect.

We'd had discussions last year about merging all of the calculations down into the EC. As since the Chrome side calculations were written the EC has also started doing hinge angle calculations. Both of which currently use different filtering which would need to be unified.

My college Zheda is working on pushing EC side to do all calculations and send out events. If EC side events are available, is there some mechanism inside Chrome to handle these events?

xdai@ any thoughts on the question in #6?

Sorry about the lack of the background knowledge. What is "EC"? What kind of events from "EC side" are you planning to send? I'm not sure if Chrome side have existing mechanism to handle the events so it might need some investigation.

Currently it looks to me that Chrome uses AccelerometerReader to read a file to get the accelerometer information and notify its observers periodically (100ms). See https://cs.chromium.org/chromium/src/chromeos/accelerometer/accelerometer_reader.h?rcl=99424620f8a042b4a2b06978f77bc98731f3d09f&l=35

EC = embedded controller (From cros ui point of view, it's firmware side).

Instead of chrome constantly reading accelerometer values and making decision, firmware can do that instead and send an event only when necessary, and chrome can switch the mode only when it receives the event.

Thanks Oshima, do we have existing mechanism to handle the event from firmware (I suppose so?). junchao.han@, are these EC side events available?

Currently Chrome is setup to respond to chromeos::PowerManagerClient::TabletMode events from the firmware.

ash/wm/tablet_mode/tablet_mode_controller.cc will turn toggle the UI on/off in response to that signal, overriding existing accelerometer cues.

If the hinge angle calculations were moved into the firmware only, Chrome could just keep relying on that existing signal. Then observing the accelerometer for screen orientation changes could be enabled once in tablet mode.

There's already some code in EC to calculate lid angle.
see https://chromium.googlesource.com/chromiumos/platform/ec/+/master/common/motion_lid.c#216 for the code. But motion_lid_set_tablet_mode (motion_lid.c#167) is defined in a few boards(kevin, nami). As gwendal@ explained, for most boards, chromeos::PowerManagerClient::TabletMode is only fired by EC when lid angle is 360 or keyboard detached. 

Probably we can enable motion_lid_set_tablet_mode in EC for more boards?

Besides, EC also has some code for screen orientation (https://chromium.googlesource.com/chromiumos/platform/ec/+/master/common/motion_sense.c#35), may add message to notify Chrome for any change.

For motion_lid_set_tablet_mode in the EC, we'd need to update it to enter at 200 degrees, and exit at 160 degrees. Then it would match what Chrome is currently doing, and we'd be able to stop always listening to the accelerometer while in laptop mode.

There's also currently currently some differences in how the EC and Chrome smooth out the accelerometer data. We'd likely want to unify the two.

As for EC having screen orientation code: it would also be awesome if that could be done as a notification to Chrome.

I make a prototype to let EC handles lid angle calculation and notify Chrome the tablet mode switch event. Thus lid angle calculation and corresponding accelerometer data read in Chrome can be removed. 

According to evaluation, CPU utilization of Chrome process can be reduced, and it can bring power benefit (128mW, 3.8% of idle system power in laptop mode on Chromebook). Could u please take a look at the prototype patch and give some comments ?
EC: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1390943
Chrome: https://chromium-review.googlesource.com/c/chromium/src/+/1391911

There are still a few things need to do, such as to refine lid calculation algorithm in EC to make it reliable, and match Chrome behaviour.

So gwendal@ has recently uploaded a patch on the EC: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1388844

Which is working to update the lid calculation to match that of Chrome's. This would make the EC patch in #15 unnecessary. I'll take a look at the Chrome side patch

Yes after EC side lid calculation is ready, Chrome side patch may work.

Besides, will gwendal@ consider doing similar things for screen orientation after EC lid patch? Could you please add my access to the crosbug b:120346412 ? 

This issue has an owner, a component and a priority, but is still listed as untriaged or unconfirmed. By definition, this bug is triaged. Changing status to "assigned". Please reach out to me if you disagree with how I've done this.