The Following User Says Thank You to auouymous For This Useful Post: | ||
![]() |
2011-04-15
, 08:07
|
Posts: 1,101 |
Thanked: 1,185 times |
Joined on Aug 2008
@ Spain
|
#542
|
SystemUI magically enters flight mode, maybe via one of its powerkeymenu callback return values, and then MCE tells SystemUI to open a modechange
ASUI calls req_device_mode_change and MCE sends out the signal confirming the change.
All the wifi and bluetooth dbus activity after the flight signal is the same for SystemUI and ASUI. I don't see how the different MCE calling mechanisms would make any difference since the services all respond the same.
@ maacruz, could you try logging `dbus-monitor --system --profile` after entering flight mode with SystemUI and see if ICD still scans for networks?
![]() |
2011-04-15
, 09:22
|
Posts: 875 |
Thanked: 918 times |
Joined on Sep 2010
|
#543
|
Yes, it happens with SystemUI too. I wonder why I didn't notice the battery drain before.
So, after some more logging I can confirm that:
If the device is turned from wifi connected to flight mode directly, with either ASUI or SystemUI, ICD will keep scanning for wifi networks at the programmed interval.
If wifi is disconnected before turning into flight mode, ICD will be quiet.
Did ASUI wait for ICD to confirm wifi is disconnected before turning to flight mode?
Since it works by turning off wifi by hand, may be that's the issue.
![]() |
2011-04-15
, 10:45
|
Posts: 1,101 |
Thanked: 1,185 times |
Joined on Aug 2008
@ Spain
|
#544
|
Does the abnormal drain happen with SystemUI? We haven't yet proven the ICD scan is causing the drain. Does it drain normally if you stop the wifi services?
No ASUI didn't wait for ICD to ack the disconnect. Try manually turning off wifi, wait for red light to go gray and then enter flight mode. Does ICD still scan?
![]() |
2011-04-15
, 11:25
|
|
Posts: 139 |
Thanked: 38 times |
Joined on Nov 2007
@ mid gulf coast florida
|
#545
|
![]() |
2011-04-15
, 16:07
|
Posts: 875 |
Thanked: 918 times |
Joined on Sep 2010
|
#546
|
The Following User Says Thank You to auouymous For This Useful Post: | ||
![]() |
2011-04-15
, 17:55
|
Posts: 875 |
Thanked: 918 times |
Joined on Sep 2010
|
#547
|
![]() |
2011-04-15
, 18:18
|
|
Posts: 4,783 |
Thanked: 1,253 times |
Joined on Aug 2007
@ norway
|
#548
|
New ASUI test binary. I forgot to reset the flight mode flag and it'll automatically enter flight mode every time wifi or bluetooth disconnects.
![]() |
2011-04-15
, 19:51
|
Posts: 1,101 |
Thanked: 1,185 times |
Joined on Aug 2008
@ Spain
|
#549
|
New ASUI test binary.
- fix: turn off wifi and bluetooth and wait for their services to acknowledge before entering flight mode
- fix: lock keys for the 2 seconds it takes power button to blank screen when locked
- save and restore state of battery rate/times mode
@ maacruz, this waits until icd and/or bluez have replied before sending the flight mode signal. The binary you have was sleeping for 100ms after it disconnected wifi before it sent the flight mode signal and this release gets back the flight mode change really fast so not sure if it will make a difference. If it doesn't work I can try inserting a sleep between the ack and flight mode request to simulate the time it would take your finger to move from the wifi widget to the flight mode button.
New ASUI test binary. I forgot to reset the flight mode flag and it'll automatically enter flight mode every time wifi or bluetooth disconnects.
@ maacruz, I think you solved my 14%/hour drain problem when I enter flight mode and leave wifi services running. I don't have mine set to auto-scan for networks so I never received any ICD signals, just an enormous drain that doesn't seem to happen with this fix. Now if only tear wouldn't prompt to leave flight mode everytime I access local HTML files with wifi services running.
The Following User Says Thank You to maacruz For This Useful Post: | ||
![]() |
2011-04-15
, 21:41
|
|
Posts: 139 |
Thanked: 38 times |
Joined on Nov 2007
@ mid gulf coast florida
|
#550
|
![]() |
Tags |
bada blows, bada rox |
|
28) press PB, screen was locked so it attempted to blank it
31) over and over you pressed it with same results
125) MMC access opened the blank window and unlocked keypad, waiting for secondary key to unlock
126) something enabled the screen as well, still
131) you pressed PB and it attempts to blank it
133) you touch screen which causes blank window to close but the PB finally relocks screen and keys but the blank failed
148) you press it some more
153) another MMC access and ASUI is waiting for secondary key
156) you pressed the dpad center key and unlocked the device
212) you turned off the secondary unlock key, thinking this would fix your problem, but the PB always blanks the screen when it is on and locked and since your screen isn't turning off there is no way to use PB to unlock screen since that only works when the screen is off.
Did you open/close the MMC door 6 times during that log period? USB port, headphone jack, charger and MMC all turn on the screen and unlock the device is secondary key not required, they will also unlock keys and prompt for secondary key if it is required. You could use any of these as a failsaife to unlock the device. Power button is not required to unlock the device, it is just one of many ways to access the secondary key sequence. Once you see the "press KEY to unlock" notification you just need to press the secondary key before the screen turns off.
Your problem is that MCE won't blank or dim the screen when ASUI asks it to. And if the screen never turns off then power button can never be used to unlock it. I could add a setting to disable the PB blank feature and have it always unlock or prompt for secondary key but that wouldn't help you because not having your screen blank is a much much bigger problem.
Alarm dispatcher can keep the display from blanking and the device from shutting down if an alarm is active or about to go active. You could using asui-setting app to stop alarm dispatcher and maybe remove it from boot sequence. Have you installed anything that the rest of us might not have?
Edit: It appears that whenever you press power button MCE unlocks the keys probably so SystemUI can get its secondary key to unlock screen. I was unaware it was doing this and it only happens for a 2 second period when the screen is on but locked and power button is pressed. This is why your keys are passing through, next release will fix this.