Introducing PowerManager

[David Zeuthen]

On Fri, 2005-01-07 at 17:27 +0000, Richard Hughes wrote:
> On Fri, 07 Jan 2005 11:54:10 -0500, David Zeuthen wrote:
> > Yes, there are plans to add hal device objects for the presence of ACPI
> > things like batteries, buttons, ac_adapters and so forth.
> 
> Plans? Or code? I think I could help with code. There's been so much
> discussion about a simple battery, but I don't want to duplicate other
> peoples work or tread on other peoples toes. See my post about mapping the
> ACPI bus? Anyone got any code that I can look at? Anything in CVS?
> 

There's no code yet - Sergey Udaltsov contributed the specs on how the
battery.* namespace should look like; it's here

 http://cvs.freedesktop.org/*checkout*/hal/hal/doc/spec/hal-
spec.html#device-properties-battery

and some code for polling a wireless mouse that will need to be added
when things land on HEAD - e.g. right now I'm rewriting the Linux
backend to split things into multiple processes

 http://lists.freedesktop.org/archives/hal/2004-December/001424.html

using the features of kernel 2.6.10 / udev-049. That's coming along
nicely, I got it working for input devices - the code is much simpler
and looks more robust. I need to go over it a few more times before I
commit it to HEAD. It looks like I have time on Saturday to do that :-)

With regards to ACPI, I think you can go ahead and add code to the
stable
branch that reads /proc/acpi and creates hal device objects - it should
be
pretty easy to port over to the new backend as it won't be using sysfs.

Regarding the layout of the device objects, I guess that we want the
following properties

 info.category = 'acpi_button'
 info.capabilities = 'acpi_button'
 acpi_button.type = 'lid'
 ...

and so forth - the exact properties we end up exporting might change
until we all agree on what to export. For batteries you would have
something similar and also export the battery.* properties as defined
by Sergey.

Does this sound sensible?

> > ... My thinking on this problem is
> > basically that
> > 
> >  1. Have HAL export the interesting objects from ACPI
> > 
> >  2. If polling is required for e.g. a battery, start some process that
> >     updates the values for e.g. battery levels
> 
> Proper services (ala init.d) or just a simple program (shell script?) that
> sleeps lots, then updates hal?
> 

Just a simple program that uses libhal to update properties in HAL.
There
will be facilities for invoking this program as detailed in the last 
paragraphs or this message

 http://lists.freedesktop.org/archives/hal/2004-December/001461.html

For debugging and developing this program, I suppose you can just
manually
invoke it and passing the UDI in the environment. Once we get hald to 
automatically start it (based on properties), the UDI will be passed and
it should Just Work(tm).

> Will these mini-services be in HAL or as an extra package? I think they
> should be in HAL proper for maintainability reasons.
> 

I think HAL should ship with a set of add-ons, sure. The idea is that
this
can be overridden by device information files.
 
> >  3. Export methods on the org.freedesktop.Hal.Device.<somename>
> > interface
> >     that maps to certain binaries. This would include SetLCDBrightness
> > (),
> >     Standby() etc.
> 
> Binaries or shell-scripts? Wouldn't scripts be more flexible?
> 

Well, executable might be a better word. Both a binary and a script will
suffice :-). The idea is that the executable method Foo() maps to is
defined by a property that can be overridden by a device information.
E.g., if I'm an open source project that does software for controlling
LCD Brightness, I can go and install a .fdi file setting the appropriate
property.
 
> >  4. Desktop level applications simply queries HAL for values and invokes
> >     applications as appropriate.
> > 
> > Right now I'm working on infrastructure to support 2. and 3. in a way
> > such that it's easy to support various backends; e.g. for 3.: depending 
> > on the make of the laptop SetLCDBrightness() needs to be implemented in
> > various ways. For 2.: batteries are polled in various ways.
> > 
> > Now, I'm not sure moving all this to a separate D-BUS service
> > (PowerManager)
> > and so forth is the way to go - it just seems like extra work. But maybe
> > I'm
> > missing something?
> 
> My personal opinion is that PowerManager will only be needed if the
> HAL ACPI/PMU work is never done. Gnome programmers are dying for a
> proper power management solution.
> 

Yah, patches for doing this in HAL would be most welcome :-) 

Cheers,
David


_______________________________________________
hal mailing list
hal at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/hal