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.
--
Ben Dooks <[email protected]> http://www.fluff.org/ben/
--
unsubscribe: [email protected]
website: http://groups.google.com/group/android-porting