Re: [Utopia] ACPI and DBUS integration

[David Zeuthen <david fubar dk>]

On Sat, 2004-05-08 at 15:33 +0100, Matthew Garrett wrote:
> Daniel Silverstone (not to be confused with Daniel Stone) has hacked up 
> a nice little app that gets called by acpid and sends dbus events 
> whenever an acpi event is received. At the moment, this will be whenever 
> an ACPI button is pressed or there's a power state change.
> 

Yay - nice.

> This probably isn't the long term goal. At present, the way this works 
> is for acpid to get an acpi event and turn that into some sort of state 
> change, so you'll get "button/sleep" rather than "transitioning to S3 
> sleep". In the long run, acpid probably needs to be reimplemented so 
> it's a little bit more intelligent than just running scripts that can do 
> anything.
>
> The Utopian consequences ought to be fairly clear. Suspending a laptop
> should result in it coming back with the screen locked. Closing the lid
> should trigger screen blanking even if it doesn't suspend (this is done
> in hardware on some machines, but not all of them). Movie applications
> ought to be prompted that I'm on battery and consider whether a lower
> quality but less CPU intensive algorithm would be helpful. When I get to
> low battery levels, applications should be more paranoid about
> autosaving work (yeah, this ends up consuming more power, but still). 
> Countless others.
> 

These are all nice and important use-cases.

> The tarball's at http://users.pepperfish.net/dsilvers/acpi-dbus.tar.bz2 
> - make, make install and follow the instructions. Requires acpid to be 
> installed.
> 

I was thinking it would be useful to integrate this into HAL - presently
HAL exports a number of different devices and each device has properties
(like block.mount_point) and they can emit ''conditions'' e.g. sending
out information that can not easily be tracked in properties, like
''Processor is overheating'' or ''Block device unmounted''. 

The reason I think it's useful to integrate this with HAL is the
connection with the device emitting the condition - on that device there
may other properties/information to help various policy-pieces in GNOME
to make an even more educated decision on what to do.

Further this would allow some kind of abstraction to be created - the
Powerbook I'm writing this on right now doesn't support ACPI but it does
have a number of nice power mgmt features (albeit poorly supported by
Linux 2.6 at the moment).

Just my $0.02.

Thanks,
David