Battery level alarm on Eee 901

Battery level alarm on Eee 901

[Phil Endecott]

Hello, it's me again...

I'm trying to get a low battery alarm to work on my Eee.  In 
/sys/class/power_supply/BAT0 I have a good selection of readable 
attributes like charge_now, current_now etc.  There is also a writeable 
"alarm" file.  But as far as I can see, the alarm is not implemented.

I have a couple of questions about this:

- Looking at the ACPI battery driver code, it knows that there is no 
support for an alarm when it tests the result of evaluating the _BTP 
method, which my BIOS doesn't seem to offer.  However, it doesn't 
subsequently return an error to the write, so my attempt to set an 
alarm succeeds.  Is this the desired behaviour?  Wouldn't it be better 
to either not create the alarm file, or to cause writes to fail, when 
it's known that there is no support?

- Presumably I could write a trivial daemon to poll the battery level.  
A quick search find bazillions of gui applets that do this.  I would 
prefer to generate a synthetic ACPI battery alarm event when I detect a 
low charge level, so that the action taken in response can be 
implemented independent of the method of detection.  Has this already 
been done?  Is there an easy way to inject a synthetic ACPI event from 
user-space?  What does a valid battery alarm event look like?

Many thanks for any suggestions.


Phil.

Re: Battery level alarm on Eee 901

[Zhao Yakui]

On Wed, 2008-09-17 at 22:43 +0100, Phil Endecott wrote:
> Hello, it's me again...
> 
> I'm trying to get a low battery alarm to work on my Eee.  In 
> /sys/class/power_supply/BAT0 I have a good selection of readable 
> attributes like charge_now, current_now etc.  There is also a writeable 
> "alarm" file.  But as far as I can see, the alarm is not implemented.
> 
> I have a couple of questions about this:
> 
> - Looking at the ACPI battery driver code, it knows that there is no 
> support for an alarm when it tests the result of evaluating the _BTP 
> method, which my BIOS doesn't seem to offer.  However, it doesn't 
> subsequently return an error to the write, so my attempt to set an 
> alarm succeeds.  Is this the desired behaviour?  Wouldn't it be better 
> to either not create the alarm file, or to cause writes to fail, when 
> it's known that there is no support?
According to the ACPI spec the _BTP object should exist if the battery
alarm is supported. If there is no _BTP object, maybe the alarm can't be
supported. 
Your suggestion is right. If alarm is not supported, OS had better not
create the alarm file. 
> 
> - Presumably I could write a trivial daemon to poll the battery level.  
> A quick search find bazillions of gui applets that do this.  I would 
> prefer to generate a synthetic ACPI battery alarm event when I detect a 
> low charge level, so that the action taken in response can be 
> implemented independent of the method of detection.  Has this already 
> been done?  Is there an easy way to inject a synthetic ACPI event from 
> user-space?  What does a valid battery alarm event look like?
You can use the daemon to poll the battery level and decide what action
to take when the battery level is lower than the predefined level. 
Why is the ACPI alarm event still expected to be triggered in such case?
In fact when the ACPI event is triggered, the user-space decides what
action to take. 
And it is not easy to insert the synthetic the ACPI event from
user-space.

> 
> Many thanks for any suggestions.
> 
> 
> Phil.
> 
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Battery level alarm on Eee 901

[Phil Endecott]

Zhao Yakui wrote:
> On Wed, 2008-09-17 at 22:43 +0100, Phil Endecott wrote:
>> Hello, it's me again...
>> 
>> I'm trying to get a low battery alarm to work on my Eee.  In 
>> /sys/class/power_supply/BAT0 I have a good selection of readable 
>> attributes like charge_now, current_now etc.  There is also a writeable 
>> "alarm" file.  But as far as I can see, the alarm is not implemented.
>> 
>> I have a couple of questions about this:
>> 
>> - Looking at the ACPI battery driver code, it knows that there is no 
>> support for an alarm when it tests the result of evaluating the _BTP 
>> method, which my BIOS doesn't seem to offer.  However, it doesn't 
>> subsequently return an error to the write, so my attempt to set an 
>> alarm succeeds.  Is this the desired behaviour?  Wouldn't it be better 
>> to either not create the alarm file, or to cause writes to fail, when 
>> it's known that there is no support?
> According to the ACPI spec the _BTP object should exist if the battery
> alarm is supported. If there is no _BTP object, maybe the alarm can't be
> supported. 
> Your suggestion is right. If alarm is not supported, OS had better not
> create the alarm file.

Right.  I could probably produce a patch to fix this, if people agree 
that it's the right thing to do.

>> - Presumably I could write a trivial daemon to poll the battery level.  
>> A quick search find bazillions of gui applets that do this.  I would 
>> prefer to generate a synthetic ACPI battery alarm event when I detect a 
>> low charge level, so that the action taken in response can be 
>> implemented independent of the method of detection.  Has this already 
>> been done?  Is there an easy way to inject a synthetic ACPI event from 
>> user-space?  What does a valid battery alarm event look like?
> You can use the daemon to poll the battery level and decide what action
> to take when the battery level is lower than the predefined level. 
> Why is the ACPI alarm event still expected to be triggered in such case?

Well, we have N alarm sources (i.e. ACPI and a polling daemon) and M 
alarm users (i.e. scripts that beep, GUI things etc) and it would be 
better to have 1 method for any alarm source to communicate with any 
alarm user rather then N*M combinations of communication to get right.  
I thought that the ACPI events would be that "1 method".  Do you have a 
better suggestion?

> And it is not easy to insert the synthetic the ACPI event from
> user-space.

OK.  Isn't there some sort of "ACPI test event" utility?  Maybe I'm 
thinking of something else.  udev maybe.


Thanks,  Phil.