Hello,
I too am facing the same issue here(3.10 kernel) "It wakeups from
deepsleep, but enters suspend before it executes the resume"
but I checked my power button device driver, its already reporting the
KEY_POWER event via input_report_key. Thus it should tell the PowerManager
service to acq
I have found solution to my problem, yes
I have changed my power button device driver in order to report an
input event, like other kerboard keys and touch screen pen , all they
have to report an input event in order to trigger the power manager
system
On 2 Mag, 08:21, marcero wrote:
> Hello,
>
Hello,
we have currently the same problem with our kernel.
It wakeups from deepsleep, but enters suspend before it executes the
late_resume method.
If it wakes from deepsleep it did not execute the state_store() method,
that's why I think that there is nothing written to /sys/power/state
succes
I have a good news: I think that now I am on the right track, but I
need a little suggestions about how to proceed:
IF I touch the screen (my device has a touch-screen driver working
fine with ANDROID) when ANDROID system is resuming due to the pressure
of the "on/off" physical-hardware button (th
I have found a way to trace from libhardware_legacy/power.c, sorry, it
was simpler than what I thought, I'm using logcat through serial port.
And now I can see that power.c is able to write to /sys/power/state,
but again the problem is that when resuming it doesn't write "on" to
"state".
M
On Ap
I've checked one more time the power.c code, and the fact that /sys/
android_power doesn't exist should not be a problem as it is the old
device driver for android power management in the linux kernel, while
the newer is named /sys/power
but I have an idea: as libhardware_legacy.so is not able to
another problem: power.c wants to write to this file: /sys/
android_power/auto_off_timeout
I don't see the android_power directory in the sysfs, ?
what is missing???
On Apr 11, 4:59 pm, Manjeet Pawar wrote:
> Y dont u use procfs or ioctl...to check whats goin on inside...
>
>
>
>
>
>
>
> On Wed
Y dont u use procfs or ioctl...to check whats goin on inside...
On Wed, Apr 11, 2012 at 8:17 PM, Ventanas wrote:
> found that errno is always 13, that is EACCES, so access no Permission
> denied, so what can I do?
> M
>
> On Apr 11, 4:36 pm, Ventanas wrote:
> > ok, I am trying to debug the libh
found that errno is always 13, that is EACCES, so access no Permission
denied, so what can I do?
M
On Apr 11, 4:36 pm, Ventanas wrote:
> ok, I am trying to debug the libhardware_legacy.so library that
> contains the power.c 'C'-code module that interacts with the linux-
> kernel power manager, bu
ok, I am trying to debug the libhardware_legacy.so library that
contains the power.c 'C'-code module that interacts with the linux-
kernel power manager, but I have this problem:
I want to open the /dev/kmsg file and write to it, but I get always
-1, do you know why I cannot open("/dev/kmsg", O_WR
I think that you may be wrong.
Most times when this happens its because there is some user mode service or
middle-were that needs to consume the wake event and *that* thing should be
grabbing a wake lock from user mode through the normal android API's.
I would say you are missing some integration
So do I have to encrease this timeout?
I guess user mode android code will echo on to the /sys/Power/state
file, Right? Or ama I wrong?
On 30 Mar, 19:50, mark gross wrote:
> there is a time out wake lock (1 sec) that gets grabbed at the end of
> the pm_suspend code path path (I think). (you'll
12 matches
Mail list logo
