# Battery ACPI workaround?

## Antimatter

I haven't done execessive testing yet, but so far what appealy happens is I only get one Battery event only when i plug or unplug the AC adapter, and any other time, i don't get any.

Anyway at the moment i have a ACPID script that will suspend the system to harddrive when the battery power is below a definated limit.

Now if the ACPID daemon only fire off the battery event once then this script does me no good, so is there any sort of bug or workaround that i could implement?

Thanks

----------

## Antimatter

*bump*  i have been traveling in past few day so haven't had any chance of researching this topic, but now i'm back, i still haven't found much information on this.

----------

## Antimatter

so at the moment my best luck would be to fire off a seperate script that loops once every minute or so to check the battery status, and if low, suspend to harddrive?

----------

## Antimatter

Done multiple search and google search and they all turns up nothing on this topic.

So still wondering how to work around this or ?

----------

## augury

what type of laptop?  i assume you have acpi in kernel w/ no apm and the battery, button, ac adaptor to since you see an event.  does kde battery watcher thing or  battstat or xfce4-battery or xbatt or xbattbar show the battery/ac state?

----------

## Antimatter

IBM Thinkpad T42, and yes i have ACPI with no APM, and yes i do see the battery event, but it only happen when the ac is plugged in or unplugged, which sort of makes it useless, I was under the assumption that the battery event would fire when anything important happened to the battery, and from some of the other comment that I've gathered it appearly fires once a minute on some laptops.

And at the moment i don't even have x-org so i can't check this, but yes i can check the /proc/acpi directory and it shows battery/ac state, along with checking the battery status, it shows the battery draining, and all sort of information.

In short, yes the battery ACPI is working, but just not sure what the correct way for it to function, because I wrote a event for the ACPID daemon to execute, and basically every time it gets a battery event, it will check the status of the battery and if its current level is too low then shutdown the laptop, other wise do nothing.  But if the ACPID daemon only gets one battery event when the laptop is plugged and/or unplugged from an AC power source it becomes sort of useless to have that event anyway.

----------

## augury

I'm sorry I didn't read close enough.  I see what you are saying and I think acpid is only for the button and ac.  I think there are buttons, Fn + key events as well for a few buttons on some laptops.  Acpid as it is, starts laptop-mode which alters read/writes to a disk to be less frequent for less power use (30 seconds worth).  cpudynd will poll cpu activity alot like the ondemand scheduler would, and does it fairly frequently.  For what you are doing, for lack of a better answer,  cron scripts might be ok.  Especially if your already running cron or have more jobs the over head should be minimal as any other app and maybe better dispite the bash scipt (or other), since it would only need to be run about every minute or two.  Either reading /proc files or acpi -b into a grep or bash calc. and then using that as your initiation.  Acpid could be used to hibernate after a period of time w/ lid closed too.  The kde battery app polls the battery somehow.  Could alway see what it does.

----------

## sevo

 *Antimatter wrote:*   

> But if the ACPID daemon only gets one battery event when the laptop is plugged and/or unplugged from an AC power source it becomes sort of useless to have that event anyway.

 

Do you have CONFIG_ACPI_IBM=y in the kernel?

Sevo

----------

## Antimatter

Sevo:

I'm at the moment using ibm_acpi modules, but appearly in the newest kernel the ibm_acpi if finally updated so i'll switch to that sometime soon, only issue is the speical parameters, but those can be passed as kernel parameters correct?

augury: 

I actually never thought about running the script as a cron job myself, that's actually a good idea, maybe have it check once every minute to every 5 minutes or so, i will need to caluculate how much life the minium that the battery can support and add maybe 5 more minute on top of that then go from there, its a good idea actually  :Smile:   thanks.

Only concern is the cron daemon writting to disk but i think i can do some managing with the logger daemon to only print that to the screen and not to the logs.

And i'm already reading the /proc files to get my needcassary information for the battery and few other function of the ACPI scripts

----------

## sevo

Have you actually checked that the computer fails to raise an ACPI event once the batteries run out? Or do you merely assume that it is not working because it does not raise events for every battery level change? The latter would actually be a bug...

A working ACPI setup should NOT generate events for the running battery usage, but only for transitions between states. Nor should you have to poll the hardware to do your own power management - ACPI is event driven by the hardware, and not a polling daemon or dependent on polling daemons. 

That is, the ACPI capable hardware itself will raise an event when the battery voltage drops below the level in /proc/acpi/battery/BATx/alarm (and possibly whenever other system-specific limits are reached). If you want to display battery status, you may of course poll proc/acpi/battery/BATx/status - but you should not act upon it, as ACPI will already raise the neccessary events whenever the hardware detects a critical limit.

Sevo

----------

## Antimatter

I haven't actually drained the battery to death yet, so yes that is a assumption.  Guess you could say I'm little wary of the 500 charge cycle on the lithium-ion battery, to me 500 charge/discharge cycles doesn't seem that much before its "dead"

So that's good information, i guess I'll have to just set the laptop out and let it slowly drain away and see what events gets triggered upon battery death.  Any precautions that i can take? such as remounting most of my mount-points as read only, and only mounting log as read/write so the ACPID daemon can write the events to the log

----------

## augury

/proc/acpi/battery/BAT0/alarm

```
alarm:                   unsupported

```

/proc/acpi/battery/BAT0/info

```
present:                 yes

design capacity:         6600 mAh

last full capacity:      6600 mAh

battery technology:      rechargeable

design voltage:          14800 mV

design capacity warning: 400 mAh

design capacity low:     0 mAh

capacity granularity 1:  66 mAh

capacity granularity 2:  66 mAh

model number:            BAT1

serial number:           0001

battery type:            LION

OEM info:                NOTEBOOK

```

/proc/acpi/battery/BAT0/state

```
present:                 yes

capacity state:          ok

charging state:          charged

present rate:            unknown

remaining capacity:      6600 mAh

present voltage:         14800 mV

```

Mine says unsupported  :Confused: 

----------

## augury

I just let mine run out.  xfs picks-up the pieces.  very nice.

----------

## sevo

 *augury wrote:*   

> 
> 
> Mine says unsupported 

 

And it claims a maximum capacity of 6600mAh, where five to twenty times that amount would be expected on a standard notebook. Your computer must either be something subnotebookish (and may hence have suspend mechanisms which bypass the OS, like a SRAM main memory), or its ACPI implementation is seriously broken.

Sevo

----------

## augury

That is a lot isn't it.  Are you making fun of my cell phone?

That 6600mAh at ~14v which works out to about 10 - 12 cells.Last edited by augury on Mon Dec 05, 2005 4:34 pm; edited 1 time in total

----------

## augury

It only last an hour on that too.

It seems to know about warnings

```
design capacity warning: 400 mAh 
```

and it beeps when it gets low sometimes (I haven't played around w/ it all that much).  It may give an event.  And in  that case or your case rather, whatever it may be --  go with the acpid.  I was only operating on the assumption that it didn't provide events.  I know my events come through anyway ie lid, ac-adaptor.  The scripts that I saw didn't mention the battery alarm.  If you want to do hibernate to ram and you wanted to hibernate to disk when the battery was almost done acpid would maybe be the way to go.  What wakes the system when the sleep button is pressed?  It would have to do the same for the battery alarm.

----------

## augury

Maybe I disabled it in the bios.  I'll check later.

----------

