On Wed, 2006-08-02 at 09:18 +0200, Jean Delvare wrote: > Hi Pavel, > > > > frequently it can read from the chip. And no hardware monitoring chip I > > > know of can tell when the monitored value has changed - you have to read > > > the chip registers to know. > > > > ACPI battery can tell when values change in significant way. (Like > > battery becoming critical). > > Ah, good to know. But is there a practical use for this? I'd suspect > that the user wants to know the battery charge% all the time anyway, > critical or not. Some batteries throw an event for each consumed percent or at least enough events to keep track of remaining power. Some are only throwing an event when capacity warning/low is reached, some aren't throwing any events. It may be of use to reduce polling on some machines, but you will always need a fall back. Determining whether the machine throws events regularly is not really possible, so by default you will start to poll the battery on all machines. Maybe in this case the normal (0x80) battery events should be ignored to avoid double readings or the values are cached in kernel as suggested, then it does not hurt. One should also not rely on the warning/low capacity values. I cannot say for sure whether all machines throw an event if these limits are reached. We defined our own limits in userspace, this always works. I'd go for not using the BIOS limits here at all and take user defined capacity warning/low values (in percent) in hal or wherever. IMO opinion the normal battery events (0x80) are not much of a use. They probably should be forwarded, so that userspace could switch to irq driven notification if this should ever work on more than 90% of the machines, but default will be polling. More important are the status events (0x81) if a battery is added/removed. Thomas - 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
