OESF Portables Forum
Everything Else => Zaurus - Everything Development => Distros, Development, and Model Specific Forums => Archived Forums => pdaXrom Development => Topic started by: louigi600 on August 31, 2007, 04:08:27 am
-
I'm not sure if this is also the the case on 2.6.21 or 2.6.22 kernels but this is what I discovered while on vacation:
When the power button is pressed for a suspend/resume apm script is not executed so all the stuff in /etc/apm is ignored in such cases (I think the whole suspend/resume affair is handled by the kernel directly when the power button is pressed) .... different story when "apm --suspend" is called.
It would be nice to be able to make the Z still do something upon suspend/resome.
The power saving stuff that should take place when the external power is or is not present is handled totally by by the lightnpower.py python sript ... and pnly works inside X since ti is the window manager that regularly executes the script . Amsolutely nothing happens when the external power status changes if you are not running X.
Presonally I think this is not a good way to appproach the problem: I would prefer having a daemon monitoring /proc/apm and react by calling a shell script tnat can then be easily modified (by anyone even without python knowlege) to make custom actions (like the acpi daemon does for standard x86 linux).
I already have a script that does more or less the same sort of things that lightnpower.py does (exept modify the config file for the moment). The problem is that the window manager has lightnpower.py hard coded in it ... should we make a plan to change this ?
P.S. :I think that the lightnpower.py script has a bug in the way that dpms features are used when suspend is inhibited (it turns off alltogether dpms ... but then standby dpms features might not behave exactly as wanted).
-
I agree a background daemon would make sence :-)
But right now, I dont have much time for pdaXrom so thats all you brother :-)
Late
-
I'll start writing a daemon in C to do the monitoring .... but can someone help me with the window manager stuff (removing the regular call to lightnpower.py) ?
-
I started googling on the /proc/apm data format only to find out that apmd (part of the apmd suite from which the apm execeutable, renamed to apm.x, comes from) does all that is neededincluding calling a script (referred as proxy script in documentation) with parameters when apm events take place.
I've never attempted using apmd on Z but I've managed to build it. I will investigate further on the matter although Z apm is implemented in a different way to x86 apm (with bios).
It is intresting because apparently suspend and resume are apm events and are passed to the proxy script .... making the whole apm shell redirect and /etc/apm juts a bad attempt to tackle the problem.
-
Ok the apmd I built is partially working (on my 760) and I got a test proxy script to log some of the supported parameters that apmd should send upon APM events.
The ones that are currently working are: start, stop, suspend and resume.
Unfortunately the power status changes are not currently reported ... not sure if this is apmd for arm bug or Z kernel bug.
This allows me to do some specific tasks upon suspend/resume (like some clock adjustments to minimize the rtc hardware design flaws) but is no good for the power saving adjustments necessary when power status changes.
-
I've never had great success with APMD, that is why I suggested a external, daemon. Maybe you can work your magic is get it working well :-)
Late
-
If I can avoid making a bad rewrite of apmd (remember I'm not a good programmer) by debugging what's wrong with it/kernel I'll be glad to stick to apmd ... otherwise I'll haveto role up my sleves and write some sort of alternative.
Next week I hope to be able to talk to some kernel developers to see if there could be any kernel issue.
Anyone have any idea how the other distro's are solving this problem ?
Do the other distros use apmd ?
I see that Angstrom uses apmd ... but I failed to get it working with my 2.6.21.5 EABI kernel and Angstrom in chrooted env.
-
Dear louigi600,
Just a little off-topic :
Is apm returning correct battery info for you in r197?
The battery info is wrong whenever I installed r197 which caused my
860 to shut off in a few minutes time with no way to wake it up.
I do know a little bit on kernels, but I cannot debug anything
with my Z shutting down every few minutes needing a full reboot ...
BR,
Felix.
-
Well you can debug the thing while on external power.
My 860 does not do this ... but it does wierd things when whatever is plugged in the CF slot draws a conciderable amount of power.
-
Dear louigi600,
After a long while and many other tasks I found the reason :
Some of the older c7x0 or 8x0 have older battery -- the 1700mAH variety with approx. 3.6-3.8V when full.
During use, the battery falls to 3.5-3.6V. The old sharp kernel knows this, so the battery is recharged
correctly. However, if you use F+D+M and check battery status then status is battery low. Apparently
sharp does not use this info. For the newer cells, the battery when fully charged is approx. 4.0V so there
is a huge difference which is why the problem with apm.
BR,
Felix.
-
Dear louigi600,
After a long while and many other tasks I found the reason :
Some of the older c7x0 or 8x0 have older battery -- the 1700mAH variety with approx. 3.6-3.8V when full.
During use, the battery falls to 3.5-3.6V. The old sharp kernel knows this, so the battery is recharged
correctly. However, if you use F+D+M and check battery status then status is battery low. Apparently
sharp does not use this info. For the newer cells, the battery when fully charged is approx. 4.0V so there
is a huge difference which is why the problem with apm.
BR,
Felix.
Well actually as any Lithium based rechargable battery (whether it be Li-Ionor LiPO) the voltage should never drop below 3V per cell under load and is generally regarded as discharged when at rest tension drops to around 3.7 or 3.6V. When fully charged should be around 4.1 or 4.2 Volts per cell (depending on constructors specifications).
Not sure if kernel makes good use of this knowlege :-(