Fedora power management

[David Zeuthen]

On Mon, 2004-11-15 at 11:04 +0000, Hughes R Mr (UG - Electronic Eng)
wrote:
> 
> David, (cc-ing to hal-devel)
> 

Hi (dropping the fedora-devel-list cc)

(please fix your mailer to wrap at 72 columns or something, thanks)

> Well, if you need a hand...
> 

Patches are indeed welcome :-)

> >An interesting question is how we allow the desktop session to say
> "put
> >the system into standby". One trivial idea is to provide a 'system-
> >suspend' command (through consolehelper or something), however I
> think
> >that it might make more sense to make the hal daemon expose a D-BUS
> >interface with the appropriate methods - e.g. perhaps just the method
> >Suspend() on an interface org.freedesktop.Hal.Device.PowerManagement.
> 
> org.freedesktop.Hal.Device.PowerManagement sounds good. Then battstat
> could
> then just call on this interface to do the suspend, and do away with
> that
> nasty textbox configuration option for suspending.
> 
> >This method call should map to an appropriate script. That way we can
> >leverage the D-BUS policy system for allowing/denying this action
> [2].
> >Plus, that we'll need this in HAL anyway for other kind
> hardware/actions
> >(e.g. Rename() and Eject() on storage volumes) and it makes it
> somewhat
> >easier to use from e.g. GNOME applets.
> 

We really need it for other stuff too including some crypto stuff using
dm-crypt I'm presently working on (will post about it soon; this week or
so). See below also.

> So in this unified-HAL theory, where would the brightness of an LCD
> panel live?
> Would a "LCD panel" be varient of monitor in the HAL tree? How can
> this
> information be added to HAL?
> 

I envision we do the following

 1. For batteries add hal device objects of capability 'battery' for
    each device. Put appropriate properties on them. Many of these would
    have to be optional, no sweat. Note that we want to consider an
    external UPS a hal device object of capability 'battery' too, so
    perhaps a boolean property battery.is_external or something might be
    good. Or something. Use the polling in hal to update the properties
    representing charged state etc.

 2. For buttons (the lid can be considered a button) add hal device 
    objects for each of them, give it capability 'button'. Perhaps add
    the 'button.function' string property and define 'lid', 'power',
    'sleep'. When we detect a press (by listening on /proc/acpi/event
    or /dev/pmu etc.), send out a DeviceCondition (see the method
    device_send_signal_condition() on HalDevice in hald_dbus.c) saying
    that the button has been pressed (such things are hard to express
    in properties, hence the DeviceCondition stuff).

 3. For LCD brightness, I'm not sure this is a property of the monitor,
    graphics adapter or actual make of laptop - I kind of suspect is it
    the latter. Anyway, from your original mail, here (for other hal
    readers)

     http://www.redhat.com/archives/fedora-devel-list/2004-November/msg00422.html

    the /sys/acpi/toshiba/lcd seems highly Toshiba/ACPI specific (I
    think that in 2.6.10 there will be some stuff for Thinkpads too,
    that would rock.

    So we may need to think about how to do this in a sensible way; I
    guess, given it's 'actual make of laptop' specific, we may want this
    functionality to live on the root hal device object representing the
    computer. This device object may gain the capability lcd_display
    and may export the interface org.fd.Hal.Device.LcdDisplay interface
    with the SetLCDBrightness() property.

 4. For actually suspending /org/freedesktop/Hal/devices/computer could
    export the interface org.freedesktop.Hal.Device.PowerManagement with
    the methods Standby(), Suspend() or what we decide to call them. 

On point number 4., exporting interfaces with methods, there are several
options; here are some random thoughts

 a. We could make use of D-BUS introspection though I'm not sure this is
    finalised yet

 b. We could have a property, say, info.interfaces that is a list of
    strings of exported interfaces, e.g. for computer it would be
    (yes we would need to add lists as a type)

     info.interfaces = {'org.freedesktop.Hal.Device',
                        'org.freedesktop.Hal.Device.PowerManagement'}

    and perhaps for volume

     info.interfaces = {'org.freedesktop.Hal.Device',
                        'org.freedesktop.Hal.Device.Volume'}

    and for an encrypted volume

     info.interfaces = {'org.freedesktop.Hal.Device',
                        'org.freedesktop.Hal.Device.Volume',
                        'org.freedesktop.Hal.Device.Volume.Crypto'}

    Where the .Crypto interface would export e.g. Setup(string
    passphrase), ChangePassphrase(string passphrase, string
    newPassphrase). 

c. All interfaces other than org.freedesktop.Hal.Device would be defined
   in /etc/hal/methods.d/<InterfaceName>.xml, e.g. we would have

    /etc/hal/methods.d/Volume.xml
    /etc/hal/methods.d/Volume.Crypto.xml
    /etc/hal/methods.d/PowerManagement.xml

   and PowerManagement.xml would simply map Standby() (and typecheck
   the method call) to a shell script or something that on ACPI does a
   'echo standby > /sys/power/state', and on PMU does something similar.

This pretty much represents my thinking on how this should be done; I
think it makes a lot of sense; it's extensible, sweet, concise and type
safe. It may also be made secure by only allowing e.g. users at the
console to invoke methods (on RH systems) or hald/D-BUS could integrate
with other privilege systems (resmgr on SUSE for instance). So, to me
it's an ideal interface for the desktop to do 'heavy-duty' operations/
reconfiguration of hardware - the light-weight operations on devices
(e.g. using them!) can be done through traditional ways.

Robert earlier said we should this through SetProperty or don't do it at
all. I disagree here. Some operations (in fact most of the interesting
operations) doesn't really map to SetProperty; e.g. for passworded media
there is no way you can set a property with your passphrase; similar for
Eject() there is sensible way to do it.

> Similarly, could we Implement an Eject() [to call cardctl eject?] on a
> PCMCIA
> adaptor quite simply?
> 

I'm quite sure cardctl won't be necessary once all the PCMCIA stuff have
landed safely in the upstream kernel. I could be wrong though.

Cheers,
David


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