Hi Kan-Ru, >> 1. Changing PowerManager.screenEnabled is THE ONLY WAY to trigger the >> suspend. > This is not true. The android kernel could call suspend at anytime when > the wake lock count in kernel hits zero. When design power management > API we must remember that the user space has to cooperate with the > kernel. Wake up events could come from device drivers or user space.
Basically it is true of system will go into real suspend state when wake lock count is 0. But please refer to the link as below http://code.google.com/p/bricked/source/browse/kernel/power/earlysuspend.c?repo=tenderloin&name=2a47e396d5&r=2a47e396d569c069bf7023202e336ec19bbf615c#168 When Gecko set "/sys/power/state" to "on", there is a wakelock created by kernel - main_wake_lock. So there is no chance of wakelock count is 0 until PowerManager.screenEnabled = false -> Gecko set "/sys/power/state" to "mem" -> check wakelock is 0 or not. If the statement as below is still true then we don't need PowerManager.cpuSleepAllowed and just handled by system app itself. "1. Changing PowerManager.screenEnabled is THE ONLY WAY to trigger the suspend." > Please define powerLevel. Currently the Resource Lock API Honestly to say, I have no strong reason to change this. But just focus on rename the PowerManager.screenEnabled and split it to two functions - Suspend & Screen. > 1. System app can collect the minimal power level requests from each apps > then decide what is the minimal power level now. > 2. Then calling setPowerLevel() when any condition is triggered. (ex: power > key handling, idle time out or proximity event during phone call). > 3. App can really request screen to off by calling screenEnabled attribute. >> >>The third step does not depend on the first and second change. Yes, the third step didn't depends on first and second. What I want to mention is "suspend and screen off can be split into two different things" Thanks, Sincerely yours. ----- 原始郵件 ----- 寄件者: "Kan-Ru Chen (陳侃如)" <[email protected]> 收件者: "Marco Chen" <[email protected]> 副本: [email protected], [email protected] 寄件備份: 2013 11 月 27 星期三 下午 7:29:23 主旨: Re: [b2g] [WebAPI] The Naming of PowerManager.screenEnabled Misleads the Gaia Developers [ +dev-webapi You could find the original thread here: https://groups.google.com/forum/#!msg/mozilla.dev.b2g/UP5h_a3QAHE/i3S3aCwNPTUJ ] Marco Chen <[email protected]> writes: > Hi Kan-Ru, > > Thanks for your reply first. > >> Changing PowerManager.screenEnabled is just one way to trigger the suspend. > > As I knew, > 1. Changing PowerManager.screenEnabled is THE ONLY WAY to trigger the suspend. This is not true. The android kernel could call suspend at anytime when the wake lock count in kernel hits zero. When design power management API we must remember that the user space has to cooperate with the kernel. Wake up events could come from device drivers or user space. >> and remove the cpuSleepAllowed attribute from PowerManager > > 1. Currently PowerManager.cpuSleepAllowed is set by System app and depends on > any apps tried to call navigator.requestWakeLock or not. > 2. Then gonk implementation will help to acquire a wakelock from linux kernel > corresponding to value of cpuSleepAllowed. > 3. Then this mechanism can prevent system go into suspend from setting > PowerManager.screenEnabled to false. Yes. This describes how the system works currently. But note that the PowerManager is a certified only API. > I agree that PowerManager.cpuSleepAllowed can be removed and system app can > take care this state by itself. > > partial interface navigator { > boolean requestMinPowerLevel(DOMString powerLevel) > }; Please define powerLevel. Currently the Resource Lock API[1] (aka WakeLock) allow apps to request the resource they need to accomplish a task and the power required for the resource may vary on different platforms. For example the e-ink screen consumes no power when the cpu is off. > partial interface PowerManager { > // Ask the system to suspend. Return true on success, false otherwise. > boolean setPowerLevel(DOMString powerLevel); > > void addPowerLevelListener(MozPowerLevelListener aListener); > void removePowerLevelListener(MozPowerLevelListener aListener); > > // Is the device's screen currently enabled? > attribute boolean screenEnabled; > > // removed > //void addWakeLockListener(MozWakeLockListener aListener); > //void removeWakeLockListener(MozWakeLockListener aListener); > > // removed > // attribute boolean cpuSleepAllowed > }; > > 1. System app can collect the minimal power level requests from each apps > then decide what is the minimal power level now. > 2. Then calling setPowerLevel() when any condition is triggered. (ex: power > key handling, idle time out or proximity event during phone call). > 3. App can really request screen to off by calling screenEnabled attribute. The third step does not depend on the first and second change. What's the reason to change the Resource Lock API to the power level interface? Kanru [1]: https://wiki.mozilla.org/WebAPI/ResourceLockAPI _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
