G-P-M on the wrong track?!

[Richard Hughes]

On Mon, 2005-10-17 at 13:13 +0200, Danny Kukawka wrote:
> On Sunday 16 October 2005 12:26, Matthias Grimm wrote:
> > Divide G-P-M in two parts (projects):
> >  part 1: Desktop module which visualize interesting data to the user
> >          including configuration dialogs
> >  part 2: a power management daemon that do the dirty work, provide data
> >          to HAL and receive orders from desktop programs through dbus.
> >
> > This concept has a lot of advantages:
> >  - It won't break with existing power management structures. Migration
> >    is possible in small steps,
> >  - The user can use the Desktop tools with a power manager he likes,
> >  - the new power management daemon will cooperate with all desktops,
> >    not only with Gnome,
> >  - HAL can fulfill its job straight forward. No foreign code anymore.
> 
> This is what we do with powersave [1] on SUSE and ALT Linux. There is a 
> (desktop and arch (ix86, ix86_64, ia64 and now also ppc) independent) daemon 
> which only do powermanagement and which also do powermanagement if there is 
> no desktop user logged in.

What use case has this got? How many times on battery do you leave your
laptop at the login screen? There was talk of integrating g-p-m with gpm
so that it runs at the login prompt (with the preferences of root), but
I'm not sure how far this idea actually got.

> On the other side there are clients (e.g. 
> KPowersave/wmpowersave, see e.g. [2]) which communicate with the daemon over 
> DBUS to get information, change settings and suspend/standby the machine.

PowerSave is good, but doesn't provide support for (I might be wrong
here) PowerMacs, UPS's, wireless mice and keyboards...

Isn't configuration actually done in /etc/sysconfig/powersave/?

Seeing stuff like this in script files doesn't aspire me..

elif [ $VAL -eq 81 ]; then # Start Browser/Konqueror
  run_on_xserver "export DISPLAY=:0.0;/opt/kde3/bin/kfmclient
openProfile webbrowsing" &
  : # do something

Plus, powersave is actually using HAL for some power=management
functionality:

batteries = libhal_find_device_by_capability( hal_ctx,
				"battery",
				&numBatteries,
				&dbus_error);

So I'm rather confused.

> I see also the problem with currently unclear concept of HAL and to build 
> blackhole-'mega-system-do-everything daemon' (as I sad in different 
> discussions before).

Yes I agree with that, but what about for UPS's... APC has one
interface, Belkin have another. Two small addons just to update the
charge seems better than one super init script just for everything.

> We should not workaround all problems for broken 
> hardware in HAL (e.g. we should not at special workarounds for broken ACPI 
> bios as for COMPAQ EVO N160), this is to much and IMO a problem to maintain. 
> Do such things in the kernel or in other ways. 

You ever got the kernel guys to accept fixes for a broken ACPI BIOS?
The answer I got was that battery reporting fixes should be done in
userspace when possible.

> On the other side, there are also some issues which make IMO sense to set 
> devices with HAL where it not make sense to develop a additonal daemon.

Like..? Also how do we know when to launch the additional daemon(s)?

> In case of powermanagement and ACPI (and also for input abstaction, see IAL), 
> I think it make sense to have a (or more different, what ever the 
> user/distibutor want) special daemon which only do powermanagement issues 
> (and maybe read informations from HAL about hardware, as we do with 
> powersave). In this daemon you can concentrate on all related problems and 
> workaround problems on a better way than HAL.

But HAL works well now. There are lots of users who install g-p-m and
things "just work" -- no installing or starting of additional services,
devices just working, accurate information.

Using HAL as the backing store makes it easy for applications such as
battstat applet have a really easy source for getting the data.

HAL is already used in lots of GNOME applications and the new dep not a
problem for most people.

Richard.