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.
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
