Re: Re: Smart Battery System driver

Rich Townsend
2005-01-20T16:04:02Z

Pedro Venda wrote:
> Rich Townsend wrote:
> | Tonight's build:
> |
> | http://shayol.bartol.udel.edu/~rhdt/download/acpi_sbs-20050120.tar.gz
> |
> | ...only has one modification (apart from fixing a typo in my name,
> | thanks to Olaf Jansen-OIlliges!). The 'present rate' field in the
> | legacy-interface /proc/acpi/battery/*/state file is supposed to show the
> | present discharge/charge rate in either mA or mW, depending on the
> | capacity_mode used. However, I've just been using the current (in mA)
> | returned by the Smart Battery System, which is clearly incorrect when
> | capacity_mode=2 (mW) is selected.
> |
> | I've fixed this in a rather cunning way. The SBS is more sophisticated
> | than normal control-method batteries, in that individual batteries can
> | report their time to empty or full (applications reporting on CM
> | batteries have to calculate these times from the last full capacity and
> | discharge/charge rates). What I've done in the latest release is to
> | calculate what value of the 'present rate' field will produce the
> | correct time to empty or full when combined with the last full capacity.
> | The upshot is, not only does the 'present rate' field now give sensible
> | values when capacity_mode=2, but also the times reported by applications
> | using the legacy interface will be direct reflections of the proper SBS
> | times.
> |
> | The SBS driver seems to be working reasonably well now -- there are no
> | outstanding bugs. My next task is to work out how best to aim for kernel
> | integration, and to figure out how to set up event handling. Don't
> | expect the pace of development to be as fast as the past few days -- I
> | need sleep like the rest of you!
>
> yes, you definately deserve it. :-) very good work. again many thanks
> for your
> time and dedication.
>
> I think we should try to solve the issues with the current battery and
> ac ACPI
> drivers. that is something that's giving some problems to most people
> trying the
> driver.

Well, I could make it so that the driver would refuse to compile if
either of these were enabled in the kernel. That's something I
originally considered doing, before I moved to the current behaviour of
silently not compiling the legacy interfaces if ac or battery were
enabled. It seems that such behaviour is confusing.

The best solution would be to perform a run-time check. I'll see if I
can add code to dynamically detect if the ac_adapter and battery
directories are empy on module insertion, and only add the legacy
interfaces if they are.

cheers,

Rich

PS Last night, I got a proof-of-concept for event notifications working.
I still haven't got battery alarms working, but we should now be able to
do event-driven AC and battery present/charging/discharging statuses.

-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl