Re: Re: Smart Battery System driver

[Rich Townsend <rhdt-OBnUx95tOyn10jlvfTC4gA@public.gmane.org>]

Matthew Garrett wrote:
> On Mon, 2005-01-17 at 20:36 -0500, Rich Townsend wrote:
> 
> 
>>But I'm not sure why this is happening with the revised version of the 
>>code (20050116); this version contains #ifndef directives to prevent the 
>>legacy interfaces being compiled in if they are already in the kernel. 
>>Are you sure your kernel configuration matches your currently-running 
>>kernel?
> 
> 
>>From a distribution point of view, it would be nice to:
> 
> a) Not have to rewrite every acpi battery applet to use the sbs
> interface directly, and
> b) Not have to have a database of hardware that has a smart battery
> 
> Is there any way to provide the legacy interface even if standard
> battery support is built in, or alternatively some way of probing the
> system to determine which battery module should be loaded?

We can't have the legacy interface (/proc/acpi/battery) if standard 
battery support is built in, since standard battery support *defines* 
the legacy interface! The legacy interfaces in acpi-sbs only exist to 
fake the existence of a standard (i.e., control method, CM) battery.

Regarding auto-loading of the correct module, it is likely that at some 
point in the future there may be some sort of merge between the SBS work 
done by myself and Bruno Ducrot, and the standard battery code 
battery.c. This will involve quite a bit of design effort, since the 
ACPI spec considers SBS and CM batteries to be totally different beasts 
(I don't know why they didn't define a unified interface for batteries).

But at the moment we're still at the phase of getting the SBS system 
working properly.

cheers,

Rich


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt