826366 - "gecko" wakelock asserted while in a call w/ display off

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::System, defect, P1)

Description

[Michael Vines [:m1] [:evilmachines]]

We see that the "gecko" wakelock continues to be asserted while in a call w/ the display turned off.  This is causing excessive power usage.

Comment 1

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

All we need to do is rip the _cpuWakeLock logic out of screen_manager.js.

Comment 2

[Dietrich Ayala (:dietrich)]

Tim, can you fix or reassign, thanks!

Comment 3

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Marco, I need you help on this since the _cpuWakeLock is implemented in bug 753842.

Do we have other better way to protect the proximity sensors?

Comment 4

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Hum, Marco is on vacation.

Re-read the bug again, I think to get rid of the wake lock, the proper fix would have to live in Gecko, where we patch nsDeviceSensor.cpp and send the proximity sensor events even if the window is marked "background". See bug 753842 comment 40.

Chris, what do you think?

Comment 5

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Hm yes, proximity events.  Ignore comment 1 ;).

So what I see us doing is *always* holding the wakelock in order to receive proximity events.  Even if the screen times out and turns off, proximity events will turn it back on.  That's kind of a weird behavior.

This differs from android, which does the following (saner)
 - while the screen is on, responds to proximity events, turning screen on/off
 - after the screen times out and turns off, stops responding to proximity events

What I'm not sure about is whether we're testing the first case above or the second.  Before we spend a lot of time worrying about efficient proximity events, -> CAF for a clarification ;).

Comment 6

[Michael Vines [:m1] [:evilmachines]]

I like the /saner/ approach.  Proximity events aren't been taking into consideration in this power measurement.  

STR:
1. Make a call
2. Put the phone down and let the display time out
3. Start measuring after a little while

Comment 7

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Tim, so what we need to do here is release the cpu wake lock that's being held for proximity events when the display times out on its own.  Android has a special kind of wake lock for this.  If we don't have what we need to implement this in gaia, then we can look at fixing this in gecko.

Comment 8

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to Chris Jones [:cjones] [:warhammer] from comment #7)
> Tim, so what we need to do here is release the cpu wake lock that's being
> held for proximity events when the display times out on its own.  Android
> has a special kind of wake lock for this.  If we don't have what we need to
> implement this in gaia, then we can look at fixing this in gecko.

I could do it in Gaia with what comment 5 described.

Comment 9

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Attachment: WIP

WIP ... let me run some manual tests first.

Comment 10

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Attachment: Github: https://github.com/mozilla-b2g/gaia/pull/7290

https://github.com/mozilla-b2g/gaia/pull/7290

Comment 11

[Etienne Segonzac (:etienne)]

Comment on attachment 697860 [details]
Github: https://github.com/mozilla-b2g/gaia/pull/7290

r=me

(tiny nit on github)

Comment 12

[Tim Guan-tin Chien [:timdream] (please needinfo)]

https://github.com/mozilla-b2g/gaia/commit/a6b9bd822958b44e96a75e6951dd3f34ae2831e5