OESF | ELSI | pdaXrom | OpenZaurus | Zaurus Themes | Community Links | Ibiblio

IPB

Welcome Guest ( Log In | Register )

> Apm On Current Kernel
louigi600
post Aug 31 2007, 12:08 AM
Post #1





Group: Members
Posts: 474
Joined: 21-May 06
Member No.: 9,928



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).
Go to the top of the page
 
+Quote Post
 
Start new topic
Replies
iczer3
post Jan 9 2008, 05:59 PM
Post #2





Group: Members
Posts: 59
Joined: 2-February 06
Member No.: 9,059



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.
Go to the top of the page
 
+Quote Post
louigi600
post May 2 2008, 01:25 AM
Post #3





Group: Members
Posts: 474
Joined: 21-May 06
Member No.: 9,928



QUOTE(iczer3 @ Jan 10 2008, 03:59 AM) *
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 :-(
Go to the top of the page
 
+Quote Post

Posts in this topic


Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 22nd October 2014 - 09:12 PM