RE: Re: Smart Battery System driver

RE: Re: Smart Battery System driver

[Grover, Andrew]

> >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?

Hasn't anyone written a libpower yet? Battery applets shouldn't be
groveling around proc, they should be making library calls. OK all
existing apps would need to be changed (probably a big code reduction
actually) but this would let the library look for both CM and sbs
interfaces (which should not pretend to be a CMBatt of course) and
handle them.

Bonus points for also supporting APM through this interface...

-- Andy


-------------------------------------------------------
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

Re: Re: Smart Battery System driver

[Karol Kozimor]

Thus wrote Grover, Andrew:
> Hasn't anyone written a libpower yet? Battery applets shouldn't be
> groveling around proc, they should be making library calls. OK all
> existing apps would need to be changed (probably a big code reduction
> actually) but this would let the library look for both CM and sbs
> interfaces (which should not pretend to be a CMBatt of course) and
> handle them.
> 
> Bonus points for also supporting APM through this interface...

Hat-trick for the sysfs interface, when ACPI finally gets converted.
Best regards,

-- 
Karol 'sziwan' Kozimor
sziwan-DETuoxkZsSqrDJvtcaxF/A@public.gmane.org


-------------------------------------------------------
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

RE: Re: Smart Battery System driver

[Matthew Garrett]

On Thu, 2005-01-20 at 14:04 -0800, Grover, Andrew wrote:

> Hasn't anyone written a libpower yet? Battery applets shouldn't be
> groveling around proc, they should be making library calls. OK all
> existing apps would need to be changed (probably a big code reduction
> actually) but this would let the library look for both CM and sbs
> interfaces (which should not pretend to be a CMBatt of course) and
> handle them.

hal is probably the right layer to do this, rather than develop yet
another niche abstraction library. I believe the fd.o people are working
on it.

-- 
Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org



-------------------------------------------------------
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

Re: Re: Smart Battery System driver

[Simon Fowler]

[-- Attachment #1: Type: text/plain, Size: 1703 bytes --]

On Thu, Jan 20, 2005 at 02:04:16PM -0800, Grover, Andrew wrote:
> > >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?
> 
> Hasn't anyone written a libpower yet? Battery applets shouldn't be
> groveling around proc, they should be making library calls. OK all
> existing apps would need to be changed (probably a big code reduction
> actually) but this would let the library look for both CM and sbs
> interfaces (which should not pretend to be a CMBatt of course) and
> handle them.
> 
From my perspective (I'm the current maintainer of the wmacpi
battery monitor dockapp), all this would be much much easier if
there was some documentation of what exactly all the files in
/proc/acpi /mean/. I've had to root around in the kernel source to
work out what some of it does. 

I've got the beginnings of an acpi reporting library in wmacpi,
which I could fill out very easily if there was just some
documentation to base the code on . . .

> Bonus points for also supporting APM through this interface...
> 
If I had a laptop that supported APM I'd happily do that ;-)

Simon

-- 
PGP public key Id 0x144A991C, or http://himi.org/stuff/himi.asc
(crappy) Homepage: http://himi.org
doe #237 (see http://www.lemuria.org/DeCSS) 
My DeCSS mirror: ftp://himi.org/pub/mirrors/css/ 

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

RE: Re: Smart Battery System driver

[Paul Ionescu]

On Fri, 21 Jan 2005 00:03:17 +0000, Matthew Garrett wrote:

> hal is probably the right layer to do this, rather than develop yet
> another niche abstraction library. I believe the fd.o people are working
> on it.

HAL is the right layer, and they are already working on ACPI, APM and
maybe other interfaces.
But a documentation would be nice for them too.
They should focus on implementing things in HAL instead of digging in the
kernel to see what to expect in various scenarios.

Thx,
Paul





-------------------------------------------------------
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

Re: Re: Re: Smart Battery System driver

[Pedro Venda]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stefan Seyfried wrote:
| On Thu, Jan 20, 2005 at 11:04:02AM -0500, Rich Townsend wrote:
|
|
|>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.
|
|
| not "empty" but "do not exist". We will probably find machines that have
| working CM Battery but can also be used with SBS.
| Or maybe it is possible from kernelspace to check if a module is loaded
| to lock each other out => if battery or ac is loaded, sbs will refuse
| to load and the other way round.

I think the only way to do this is to integrate the sbs code into the battery
and ac_adapter drivers. that way at load time, the kernel code can check which
type of driver to use or both if possible/useful. that could be hard, I'm aware
of that.

|
|
|>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.
|
|
| It would be pretty cool to throw an event on every change of battery charge
| level (some HP notebooks do this even with CM battery), so there is no need
| to poll for battery charge level.

wasn't there a not-so-recent-but-almost discussion about this issue in the
acpi-devel mailing list? I think people argued that acpi would NOT generate
events! that could mean that the acpi layer wouldn't generate events at all or
that it wouldn't generate events on behalf of hardware unable to generate events.

care to comment?

regards,
pedro venda.
- --

Pedro João Lopes Venda
email: pjvenda-pQd4kjVL+REh2FBCd0jGRA@public.gmane.org
http://arrakis.dhis.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB8QCceRy7HWZxjWERArT0AJ9Kxk1il9RjoV1/Ow4+Dl63L0yR4wCgz4+B
cf9OpRuKZaKnKHzZe02Csd8=
=KSIG
-----END PGP SIGNATURE-----


-------------------------------------------------------
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

Re: Re: Smart Battery System driver

[Rich Townsend]

Simon Fowler wrote:
> On Thu, Jan 20, 2005 at 02:04:16PM -0800, Grover, Andrew wrote:
> 
>>>>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?
>>
>>Hasn't anyone written a libpower yet? Battery applets shouldn't be
>>groveling around proc, they should be making library calls. OK all
>>existing apps would need to be changed (probably a big code reduction
>>actually) but this would let the library look for both CM and sbs
>>interfaces (which should not pretend to be a CMBatt of course) and
>>handle them.
>>
> 
> From my perspective (I'm the current maintainer of the wmacpi
> battery monitor dockapp), all this would be much much easier if
> there was some documentation of what exactly all the files in
> /proc/acpi /mean/. I've had to root around in the kernel source to
> work out what some of it does. 

Even then, what the *kernel* does can be misleading or incorrect. For 
instance, in /proc/acpi/battery/BAT0/info, the "battery technology" 
field should be reporting "primary" or "secondary", based on the 
information it gets from the appropriate DSDT control methods (_BIF, I 
think). However, the implementor of battery.c has misread the ACPI spec 
to mean that "primary" always denotes "non-rechargeable", and 
"secondary" always denotes "rechargeable".

This led to my previous laptop, which had a control-method primary 
battery, reporting the battery as non-rechargeable -- when of course it 
wasn't.

This really does highlight why a proper library is needed for battery 
access -- both to hide the details of whether the battery is CM-based or 
SB-based, but also to remove the additional layer of obfustication added 
by proc.

cheers

Rich


-------------------------------------------------------
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

Re: Re: Smart Battery System driver

[Stefan Seyfried]

On Thu, Jan 20, 2005 at 02:04:16PM -0800, Grover, Andrew wrote:

> Hasn't anyone written a libpower yet? Battery applets shouldn't be
> groveling around proc, they should be making library calls. OK all
> existing apps would need to be changed (probably a big code reduction
> actually) but this would let the library look for both CM and sbs
> interfaces (which should not pretend to be a CMBatt of course) and
> handle them.

Thomas Renninger has written a libpower on which his powersaved is based.
It can be used without powersaved as well. It is hosted on
http://forge.novell.com (search for powersaved) and on sourceforge
(sorry, don't know the project name and right now i am offline, it probably
is also named powersaved).

> Bonus points for also supporting APM through this interface...

Yes, it can use both without the application knowing what the underlying
hardware is supporting.

Actually it is right now only extensively used and tested on SUSE, but
we have some bugreports from people compiling it on Mandrake and Debian
too, so it should not be too hard to get it going on other Distributions.
-- 
Stefan Seyfried



-------------------------------------------------------
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

Re: Re: Re: Smart Battery System driver

[Rich Townsend]

Stefan Seyfried wrote:
> On Thu, Jan 20, 2005 at 02:04:16PM -0800, Grover, Andrew wrote:
> 
> 
>>Hasn't anyone written a libpower yet? Battery applets shouldn't be
>>groveling around proc, they should be making library calls. OK all
>>existing apps would need to be changed (probably a big code reduction
>>actually) but this would let the library look for both CM and sbs
>>interfaces (which should not pretend to be a CMBatt of course) and
>>handle them.
> 
> 
> Thomas Renninger has written a libpower on which his powersaved is based.
> It can be used without powersaved as well. It is hosted on
> http://forge.novell.com (search for powersaved) and on sourceforge
> (sorry, don't know the project name and right now i am offline, it probably
> is also named powersaved).
> 
> 
>>Bonus points for also supporting APM through this interface...
> 
> 
> Yes, it can use both without the application knowing what the underlying
> hardware is supporting.
> 
> Actually it is right now only extensively used and tested on SUSE, but
> we have some bugreports from people compiling it on Mandrake and Debian
> too, so it should not be too hard to get it going on other Distributions.

But aren't we really looking for a kernel-based libpower -- so that 
*nothing* in userspace needs be exposed to the specifics of the hardware?


-------------------------------------------------------
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

Re: Re: Re: Smart Battery System driver

[Matthew Garrett]

On Fri, 2005-01-21 at 12:06 -0500, Rich Townsend wrote:

> But aren't we really looking for a kernel-based libpower -- so that 
> *nothing* in userspace needs be exposed to the specifics of the hardware?

No. The kernel should provide information and functionality, not define
policy. A good comparison point might be the lm-sensors code - each
driver provides all the information it can, and the userland libsensors
abstracts that away from everything else.

-- 
Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org



-------------------------------------------------------
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

Re: Re: Re: Smart Battery System driver

[Stefan Seyfried]

On Fri, Jan 21, 2005 at 01:16:12PM +0000, Pedro Venda wrote:

> wasn't there a not-so-recent-but-almost discussion about this issue in the
> acpi-devel mailing list? I think people argued that acpi would NOT generate
> events! that could mean that the acpi layer wouldn't generate events at all 
> or
> that it wouldn't generate events on behalf of hardware unable to generate 
> events.

i have no idea ;-) I know that hp nx5000's continuously notify me via 
/proc/acpi/event if the charge level changes, so i only have to poll battery
after an notification and that is very handy IMO :-)
-- 
Stefan Seyfried



-------------------------------------------------------
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

Re: Re: Re: Smart Battery System driver

[Stefan Seyfried]

On Fri, Jan 21, 2005 at 12:06:54PM -0500, Rich Townsend wrote:
 
> But aren't we really looking for a kernel-based libpower -- so that 
> *nothing* in userspace needs be exposed to the specifics of the hardware?

only if you like a bloated kernel. I don't :-)
-- 
Stefan Seyfried



-------------------------------------------------------
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

Re: Re: Re: Smart Battery System driver

[Rich Townsend]

Matthew Garrett wrote:
> On Fri, 2005-01-21 at 12:06 -0500, Rich Townsend wrote:
> 
> 
>>But aren't we really looking for a kernel-based libpower -- so that 
>>*nothing* in userspace needs be exposed to the specifics of the hardware?
> 
> 
> No. The kernel should provide information and functionality, not define
> policy. A good comparison point might be the lm-sensors code - each
> driver provides all the information it can, and the userland libsensors
> abstracts that away from everything else.
> 

Yes, but isn't the lm-sensors kernel code accessed through a uniform 
API?   That's what we need for the kernel battery stuff; at the moment, 
CM batteries are interfaced using ACPI control methods, while Smart 
Batteries are interfaced using SMBus accesses. Wouldn't it be a good 
idea to present all of the available battery info through some unified 
interface? Or are you arguing that this should all be done (as much as 
possible) in userland?



-------------------------------------------------------
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

Re: Re: Re: Smart Battery System driver

[Matthew Garrett]

On Fri, 2005-01-21 at 13:04 -0500, Rich Townsend wrote:

> Yes, but isn't the lm-sensors kernel code accessed through a uniform 
> API?   That's what we need for the kernel battery stuff; at the moment, 
> CM batteries are interfaced using ACPI control methods, while Smart 
> Batteries are interfaced using SMBus accesses. Wouldn't it be a good 
> idea to present all of the available battery info through some unified 
> interface? Or are you arguing that this should all be done (as much as 
> possible) in userland?

In general, if it can be done in userland, it should be done in
userland. A power management abstraction layer is needed anyway (A
userspace app should be able to request a suspend without knowing
whether the system is ACPI, APM, a Mac or whatever), so implementing the
batteries in whichever way requires least kernel code is almost
certainly the right answer.

-- 
Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org



-------------------------------------------------------
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