"doing" things to HAL devices

[David Zeuthen]

On Tue, 2005-03-15 at 12:08 +0000, Richard Hughes wrote:
> I'm at a stage with GNOME Power Manager where I want to "do" events, for instance
> 
> Computer:Shutdown
> Computer:Hibernate
> 
> There's no facility in HAL to do this for power devices, and wanted to know
> suggestions or comments about how this should be done.
> 
> For instance, for acpi:
> To sleep: echo "sleep" > /sys/power
> To shutdown: shutdown -h now
> 

Right, the idea here is that each hal device object will be able to
implement one or more D-BUS interfaces. Right now, only the interface
org.freedesktop.Hal.Device is implemented. This interface gives you all
the property methods as well as the generic Rescan()/Reprobe() methods.

I expect to have a strlist property info.interfaces that says what
interfaces are supported. I also expect, once D-BUS settles, to export
this through the org.freedesktop.DBus.Introspection stuff.

So, this will mean that e.g. the object /org/freedesktop/Hal/computer 
will export the o.fd.Hal.Device and o.fd.Hal.Device.PowerManagement
interfaces. The latter interface is defined by having the following
methods:

 -  bool Suspend() throws o.fd.Hal.NotSupported, .NotPrivileged
 -  bool Hibernate() throws o.fd.Hal.NotSupported, .NotPrivileged
 -  bool Shutdown() throws o.fd.Hal.NotSupported, .NotPrivileged

and I guess we've would have think very carefully about designing this
interface correctly (we may need isSuspendSupported(), see below).

Now, implementation-wise, I don't think hald should be in the business
of trying to actually doing these things, it should call out to other
(distro-specific) programs to do this. So, e.g. for Fedora I would merge
the properties

 info.interface.PowerManagement.Suspend = '/usr/sbin/hal-suspend.sh'
 ...

and so forth where we'd need to have a well-defined interface between
the invoker (hald) and the invokee (hal-suspend.sh) such as hald passing
args in the environment or maybe something using a pipe.

Note that distros would also need to specify the security policy here
with D-BUS; again, on Fedora I would probably use at_console and perhaps
requiring the caller (gnome-power-manager for instance) to run in a
specific SELinux security context. Other distros may do different
things.

This is also to be used for e.g. the LUKS stuff that Mike is working on;
we'd just have

 info.interface.Volume.Crypto.Setup = '/usr/sbin/hal-cryptsetup'

and this may not even be distro-specific.

The point here really is that the desktop bits can use a single
well-defined interface. All this just needs some coding, I'd hope to get
to this soon :-)

> I guess we would need a utility program (like lshal) to send events
> for testing.

I guess that dbus-send can be used for this :-)

> I've no idea for APM or PMU. Sjoerd?
> 

I don't think you need to care about this really. Leave this to
distributors to implement (I'm presently trying to do this for Fedora
with ACPI, PMU and APM, FWIW). 

What you do need to handle in gnome-power-manager is the reality that
e.g. isSuspendSupported() might return false because a) it just doesn't
work on many computers; b) distributors may not enable Suspend() in the
default install because it's too dangerous. This probably means that you
need to grey out options in the UI or something, but now I'm
digressing :-)

David


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