Hi, On 7/28/06, Vojtech Pavlik <vojtech@xxxxxxx> wrote:
> Battery polling is already used extensively, and its overhead is > completely negligible. You're joking, right? On quite a number of laptops, it takes quite a while to read the battery, spent in BIOS through SMI, polling the I2C bus while talking to the battery. The less often this is done, the better.
Yes, I know -- tp_smapi does that too. And it's still negligible, usually a few microseconds. Heck, the hdaps driver polls that same I2C bus 50 times per seconds and still doesn't tickle the load average.
> I'm yet to see any deployed userspace code > trying to query battery status more than once per second. The applets that were doing it (yes, up to 100 times per second) corrected their ways pretty quickly, because some machines became unusable with the applet enabled.
Exactly -- and they've been working merrily ever since. And if you don't want to trust applet developers, cache the latest reads and refresh them only if X jiffies have passed.
You could, trivially, mirror the behavior of current applets: Not report the changes to the battery status more often than each N seconds, except for critical events.
You're taking a polling-based hardware, exposing it as an event-based interface, and then and kludging it so that it behaves like polling again... So, in this scheme, how many lines of code does is the equivalent of "cat /sys/devices/platform/smapi/BAT0/voltage"?
> And you'll need to identify devices in a useful way, a problem that's > not yet solved even for input devices... You see where it's going. May you be more specific here? I'm not aware of any problems in this area. This may be my fault: What needs to be fixed there?
"Generic interface for accelerometers (AMS, HDAPS, ...)" on LKML, a few weeks ago, about moving accelerator-based hard disk parking from sysfs polling to the the input infrastructure. One unresolved issue was how to find which input device happens to be the relevant accelerometer. Shem - 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
