[ltp] Emulating tp-smapi's stop_charge_thresh with a daemon

[Guarded Identity]

Hi everyone,

I just started using Shem Multinymous' tp_smapi kernel module to control 
maintenance/usage of my battery.  The charging threshold support that tp_smapi 
offers is really compelling.  I probably feel more inclined toe cap my 
battery charging after reading some of the discussion on 
http://www.batteryuniversity.com/parttwo-34.htm.  Throwing away 15% of 
capacity needlessly sounds pretty wasteful.  And I rarely remember to unplug 
my laptop before most of the charging has finished.  I've run through more 
than half of the capacity of my battery already, and it feels so soon.  I've 
played around with removing the battery while plugged in, but the AC gets 
unplugged sometimes (bust!), and also it's just a hassle altogether.

Unfortunately, although the start_charge_thresh option of tp_smapi works for 
my Thinkpad T42, the stop_charge_thresh does not.  As per 
http://www.thinkwiki.org/wiki/Tp_smapi#Model-specific_status it doesn't 
appear that many models have support for stop_charge_thresh.

Here's how charge thresholding works without stop_charge_thresh.  if the AC is 
plugged in while the battery's charge is above the setting of 
start_charge_thresh, the battery will kick into an "idle" state (in which 
there's no charging or discharging).  However, if the battery's charge is 
below the setting of start_charge_thresh, then the battery continues charging 
potentially all the way to a full charge, unless the AC is disconnected and 
reconnected some time after the charge is above the setting of 
start_charge_thresh.  Such a reconnection throws the battery into an idling 
state (which makes sense).  Also, I found that simply rewriting a value to 
start_charge_thresh (say even the same value already there) has the same 
effect as a reconnection.

I imagine that for T43's and laptops with stop_charge_thresh support that 
charging idles naturally without intervention after the battery's charge 
reaches the setting specified by stop_charge_thresh.

I E-mailed Shem briefly about this and he responded that he's exhausted all 
the ideas he has for further support by his kernel module.  He mentioned two 
more courses of action: 1) do some reverse engineering on a Windows machine 
to figure out if anything's missing from tp_smapi 2) emulate 
stop_charge_thresh with as he put it 

On Tuesday 21 February 2006 2:13 am, Shem wrote:
> Anyway, you can simulate it using
> inhibit_charge and a control script.

So I think reverse engineering Windows isn't something I'm likely to do.

As I mentioned above. I think an alternative to using inhibit_charge is to 
just do a write to start_charge_thresh, but there's also force_discharge to 
play with too.  Right now I'm leaning towards using start_charge_thresh.

I was totally ready to have a control script triggered by the acpid daemon's 
"ac" or "battery" events.  Unfortunately, I've found that it's very common to 
go quite a long time without one of these ACPI events.

This lead me to think about what the right way to go about this is.  In 
preparation of using acpid, I made an /etc/init.d/ script that reads values 
from /etc/default and sets start_charge_thresh.  Also, using the resolvconf 
package as an inspiration, I set up a "stop_charge_thresh" file in /dev/shm/.  
If another script or daemon is going to poll this little file for a value, 
I'd just rather it be in shared memory.  My script very much mirrors 
resolvconf's, so the location of this emulating stop_charge_thresh is managed 
by a symlink at /etc/tp-smapi/run.

This is about where I'm at.  Since I'm not able to trigger my 
stop_charge_thresh emulation using acpid, I feel as though I have two 
options: 1) use cron to trigger some other script I write 2) write a small 
daemon and have it managed by the init.d script that I've already written.  

Using cron seems like a hack.  I feel as though I might want polling performed 
more frequently than once a minute, and even at once a minute, cron seems 
like the wrong tool.

On the other hand, this seems like a very small tool to have a single daemon 
for -- a waste of a process.  I already have a quite a few "laptop" daemons 
running -- sleepd, tp-scroll, tpb, ifplugd.  Still, though, this is a route I 
seem to be leaning towards.  I might just take a daemon like sleepd as a 
template for writing up my own.  Interestingly, this might allow for 
even more options.  Like auto-discharging to a specified end-point, say by 
implementing a "target_charge".  

Okay, so this E-mail is way longer than I'd anticipated.  Having said what 
I've said, I was hoping someone in this forum might respond to the following:

1) Does a new daemon sound like the right way to go if getting 
stop_threshold_charge working tp_smapi for more machines is just not 
feasible?  If not a daemon, what else?

2) Is anyone interested in working with me to put this together?  If not, I'll 
probably just put it together myself, but on a slower time-scale.

3) Is the above information correct?  Feel free to correct me if I'm 
misinformed.

Thanks,
Sukant Hajra