Active Topics

 


Reply
Thread Tools
Posts: 875 | Thanked: 918 times | Joined on Sep 2010
#541
Originally Posted by n9ots View Post
seems that pressing the power button 'unlocks' the rest of the buttons (not the touchscreen though) and whatever button i press causes the default action for that button (I locked the tablet with MicroB open and then pressing the power button followed by the menu key opened the menu. power + d-pad down moved down the menu...and so on.)
17) press PB to map asui
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.
 

The Following User Says Thank You to auouymous For This Useful Post:
Posts: 1,101 | Thanked: 1,185 times | Joined on Aug 2008 @ Spain
#542
Originally Posted by auouymous View Post
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?
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.
 
Posts: 875 | Thanked: 918 times | Joined on Sep 2010
#543
Originally Posted by maacruz View Post
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.
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?
 
Posts: 1,101 | Thanked: 1,185 times | Joined on Aug 2008 @ Spain
#544
Originally Posted by auouymous View Post
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?
While I haven't tested much, I'd say that it happens (about 0.8% in half hour).
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?
That's what I'm trying to say , ICD doesn't scan after turning manually off and when it is off changing to flight mode (otherwise I'd have to rush to the flight mode button after touching the wifi applet).
 
n9ots's Avatar
Posts: 139 | Thanked: 38 times | Joined on Nov 2007 @ mid gulf coast florida
#545
Originally Posted by auouymous View Post
Did you open/close the MMC door 6 times during that log period? .
I did open the Battery Compartment (six times sounds believable). did so the first time in order to remove the battery to shut down, but noticed different behavior so I fiddled with it a bit to see if I could confuse it into submission

towards the end of my inept tinkering hildon-desktop was killed and I started getting pop-ups showing estimated battery left and a notice that "USB device not supported"

is there a way to log what the stock "lock and blank" is doing? (it has always worked)
The only programs that I use that have a setting to keep screen lit are MaemoMapper and FBReader, and only Maemomapper is set as such. (and I had not used Mapper for a few days)

Thanks for all your work and sorry to add more confusion to your life...
and since I am adding confusion....I use the following to enable Bluetooth when in off-line mode (dbus-send --system --type=method_call --dest=org.bluez /org/bluez/hci0 org.bluez.Adapter.SetMode string:discoverable) yet this only works a percentage of the time (less than half the time me thinks)

Last edited by n9ots; 2011-04-15 at 11:32.
 
Posts: 875 | Thanked: 918 times | Joined on Sep 2010
#546
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.
 

The Following User Says Thank You to auouymous For This Useful Post:
Posts: 875 | Thanked: 918 times | Joined on Sep 2010
#547
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 2 Users Say Thank You to auouymous For This Useful Post:
tso's Avatar
Posts: 4,783 | Thanked: 1,253 times | Joined on Aug 2007 @ norway
#548
Originally Posted by auouymous View Post
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.
I am tempted to call that a feature

as for Tear, i think most users have gone Opera given the latest releases. Still, if you can grok vala the source is out there (and the primary dev on long term hiatus apparently)...
__________________
Be warned, posts are often line of thoughts at highway speeds...
 
Posts: 1,101 | Thanked: 1,185 times | Joined on Aug 2008 @ Spain
#549
Originally Posted by auouymous View Post
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.
It seems to work fine , but I'm still testing, now with the latest debug binary.
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.
LOL
I'm tempted to label that as a feature too
@ 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.
LOL. And in the process you have fixed what seems to be a very long standing diablo bug, and improved the battery life for everyone
 

The Following User Says Thank You to maacruz For This Useful Post:
n9ots's Avatar
Posts: 139 | Thanked: 38 times | Joined on Nov 2007 @ mid gulf coast florida
#550
thank you.
lock now works....although when I lock the screen it dims, but will not blank until I tap the power button.
 
Reply

Tags
bada blows, bada rox


 
Forum Jump


All times are GMT. The time now is 02:58.