The bug may be that you are not doing what is required to correctly wake
it up again.
Try putting a KEY_POWER press and release event in your keyboard driver
on a resume. This will then report the power key press that you actually
did to wake the device up. Android should then see that event and hold a
wake lock.
If your device is suspending before the userland gets chance to resume,
then that is a bug, and something needs to hold a wake lock, but I dont
see that on my build.
Perhaps a log with your console log level set to 7 or higher would
enable you to see how far the resume is getting before the next suspend
occurs.
On 19/04/11 11:38, Ben Dooks wrote:
On 19/04/11 10:17, Robert Beckett wrote:
Im not sure what was intended in this situation, but the way I
interpreted it was that this is as expected.
If you are resumed because of an RTC alarm (e.g. something wants to
check for updates at a given time), then it will want to go back in to
suspend asap after checking its updates. If you are woken through a
power button press, then your input driver handling the power button
should pass the button press in to the kernel input system. This is how
I handle this. In my keyboard driver's resume handler, if it detects
that we woke up due to power button press, it reports a KEY_POWER press
and release. Android then notices this key press and the power manager
holds its wake lock as usual after a key press.
It would be interesting to hear if this is the intended behaviour.
It is most definetly a bug, you press a button to wake the device
up and it just sits going through a tight suspend/resume cycle
until you give up and reset it.
There's nothing wrong in the driver path. It is user-space failing
to either run soon enough, or not running the correct action to send
"on" to /sys/power/state.
I currently have a call to set the power state to on after the resume
has run, and this is at-least getting a usable system. However I do
not think this is the correct action. init.rc has a line for echoing
"on" to /sys/power/state but this never seems to be run.
--
unsubscribe: [email protected]
website: http://groups.google.com/group/android-porting
