Introducing PowerManager

[Richard Hughes]

David,

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

Quality, I wasn't sure if anything concrete had been decided.

> 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

Thanks, I'll review this in detail, and see what I can sort with ACPI. I
have no experience with PMU, and no facility to test, but I'm sure
someone else will :-)

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

Cool, I'll wait until until then before I start coding.

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

They'll be a few of these... I'm sure when the ACPI backend stuff is in,
other people will add all the other supporting objects.

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

Good for me :-)

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

Yes, I followed this thread - I tended to agree with the idea of HAL
controlling the invocation and killing of this executable with policy,
i.e. killing the executable on the last object disconnecting.

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

Like it :-)

>  
>> >  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.
>  
>> 
>> 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 :-) 

Guess what I'm doing on Saturday by the looks of it!

Cheers, Richard


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