Battery level alarm on Eee 901
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.
Quoted 9 lines · 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/BAT0I have a good selection of readable attributes likecharge_now,current_nowetc. 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:
Quoted 7 lines
- 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
_BTPmethod, 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.
Quoted 8 lines
- 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.
Quoted 12 lines
Many thanks for any suggestions.
Phil.
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 5 lines · Zhao Yakui
Quoted 4 lines · 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/BAT0I have a good selection of readable attributes likecharge_now,current_nowetc. There is also a writeable "alarm" file. But as far as I can see, the alarm is not implemented.
Quoted 8 lines
Quoted 4 lines
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_BTPmethod, 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
_BTPobject should exist if the battery alarm is supported. If there is no_BTPobject, 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.
Quoted 4 lines
Quoted 2 lines
- 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?
Quoted 2 lines
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.