It's good to have this controlled by Gaia. Although many consider the system app part of the platform, it is still easier to customize compare to gecko. Without putting any special logical in gecko, it's much clearer how events are handled in Gaia/WebApps.
Kanru Marco Chen <[email protected]> writes: > Hi, > > In order to minimize the power consumption it is a correct way to hold > wakelock by each components of Gecko & Gaia. > My only concern is that if we do power key handling in gecko then > there is no necessary to handle this kind of problem. > Or is there a key reason of we need to keep this handling in Gaia ? > > Sincerely yours. > > ----- 原始郵件 ----- > 寄件者: "Andreas Gal" <[email protected]> > 收件者: "Marco Chen" <[email protected]> > 副本: "Tim Chien" <[email protected]>, "Julien Wajsberg" > <[email protected]>, "Alive Kuo" <[email protected]>, "Mozilla > mailing list" <[email protected]> > 寄件備份: 2013 9 月 6 星期五 下午 2:17:39 > 主旨: Re: [b2g] Moving Power Key Handling from Gaia to Gecko According to Bug > 898707 > > > When the event fires, and if an event handler is installed, can we take > a wake lock for each installed event handler and release it only after > the event has executed? The rest is then handled in Gaia. > > Andreas > > Marco Chen wrote: >> Hi Tim, >> >>>> The power key didn't always mean "go into suspend", we still need >>>> to handle "sleep menu" by long pressing power key. >>>> So we can't use the approach you proposed. >> >> I gave the first reason of why don't I prefer "get temporary >> wakelock then find a suitable point to release " in previous mail >> already. >> And the second reason is Gecko can't guarantee how Gaia will process >> power key event, so there is no suitable way to hook the ending >> point of wakelock. >> >> Generally to say, each component should take care their usage of >> wakelock by themselves so we can reduce the life cycle of each >> wakelock. >> But this is hard to do when power key is flowing between Gaia and Gecko. >> >> By the other way, there is two purpose of power keys only. One is >> for suspend/resume and the other is for sleep_menu.js. >> For first one, I think it is no necessary to be handled by Gaia or is there >> any benefit of handling by gaia? >> For second one, gecko can decide to send sleep_menu event to gaia or not. >> >> Thanks, >> Sincerely yours. >> >> ----- 原始郵件 ----- >> 寄件者: "Tim Chien"<[email protected]> >> 收件者: "Marco Chen"<[email protected]> >> 副本: "Alive Kuo"<[email protected]>, "Julien >> Wajsberg"<[email protected]>, "Mozilla mailing >> list"<[email protected]> >> 寄件備份: 2013 9 月 6 星期五 下午 12:11:54 >> 主旨: Re: [b2g] Moving Power Key Handling from Gaia to Gecko According to Bug >> 898707 >> >> On Fri, Sep 6, 2013 at 11:52 AM, Marco Chen<[email protected]> wrote: >>> Hi all, >>> >>>> Before system message is dispatched, it would acquire a 30s cpu >>>> wake >>>> lock. >>>> (http://mxr.mozilla.org/mozilla-central/source/dom/messages/SystemMessageInternal.js#120) >>>> And then sms app on getting the message, it would acquire another 30s cpu >>>> wake lock and do the notification. >>> I don't think this is a good approach because it brings more power >>> consumption on the mobile device. >>> Image that when user put the device in suspend state, it will be >>> wake up at least 30 seconds when SMS is coming before going back to >>> suspend. >>> >>> If every one used this kind of solution to solve their problem then >>> I can expect that the time of "Day of Use" on FxOS will become bad. >>> >>>> For macro's use case, what if we do the same thing from gecko: >>>> acquire a wake lock before power button event is dispatching? >>>> And release the wake lock when 'sizemodechange' is notified? >>> The power key didn't always mean "go into suspend", we still need >>> to handle "sleep menu" by long pressing power key. >>> So we can't use the approach you proposed. >>> >> >> Marco, I thought you are only talking about problems with "press a key >> to wake up a phone" scenario? >> >> Can Gecko implements a temporary wakelock until the key event returns >> from the Gaia system app context? We don't really need 30 sec for that >> if you could determine when the function call returns exactly. >> >> If Gaia ended up waking up the phone, it will do so *within* the function >> call. >> >>> Thanks, >>> Sincerely yours. >>> >>> ----- 原始郵件 ----- >>> 寄件者: "Alive Kuo"<[email protected]> >>> 收件者: "Julien Wajsberg"<[email protected]> >>> 副本: "Marco Chen"<[email protected]>, "Mozilla mailing >>> list"<[email protected]> >>> 寄件備份: 2013 9 月 6 星期五 上午 12:38:43 >>> 主旨: Re: [b2g] Moving Power Key Handling from Gaia to Gecko According to Bug >>> 898707 >>> >>> >>> Julien Wajsberg 於 2013/9/6 上午12:00 寫道： >>>> What about other things ? For example I can think of when we receive a >>>> SMS. There are Wakelocks in Gaia and in Gecko, but we still have a >>>> problem sometimes (we have a bug for this, I don't remember the number) >>>> and as a result we don't get the notification. >>> AFAIK, this shall not be the same case. >>> Get sms -> Fire System Message -> sms app's mozSetMessageHandler -> sms >>> requireWakeLock >>> Before system message is dispatched, it would acquire a 30s cpu >>> wake >>> lock. >>> (http://mxr.mozilla.org/mozilla-central/source/dom/messages/SystemMessageInternal.js#120) >>> And then sms app on getting the message, it would acquire another 30s cpu >>> wake lock and do the notification. >>> >>> Unless we're so unlucky to get all thing done in 30s + 30s… >>> >>> >>> For macro's use case, what if we do the same thing from gecko: >>> acquire a wake lock before power button event is dispatching? >>> And release the wake lock when 'sizemodechange' is notified? >>> >>>> So I think this problem is more general and can't be solved (generally, >>>> I mean) by moving things from gaia to gecko. (even if in the power case >>>> this could fix the problem). >>>> >>>> _______________________________________________ >>>> dev-b2g mailing list >>>> [email protected] >>>> https://lists.mozilla.org/listinfo/dev-b2g >>> Alive C. Kuo, Front end engineer, Mozilla Taiwan >>> [email protected] >>> >>> >>> >>> >>> _______________________________________________ >>> dev-b2g mailing list >>> [email protected] >>> https://lists.mozilla.org/listinfo/dev-b2g >> >> >> > _______________________________________________ > dev-b2g mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-b2g _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
