G-P-M on the wrong track?!

[Danny Kukawka]

On Monday 17 October 2005 14:42, you wrote:
> > 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.

This is a needed feature. There are not only laptops on battery. This was only 
one example. Other expample: You run you laptop on AC or your desktop machine 
and want to suspend or change cpufreq or set a special powerscheme as 
user/root without login to desktop. There are many possible use cases. We 
know this requirement from develop powersave and SUSE users since the start 
of the project. There are also several user which want to use the daemon 
without login from a script and also this work well with powersave.

And last but not least: there is not only GNOME and g-p-m. Why reimplement a 
system basic service for each desktop system. With a powermanagement daemon I 
can Implement hundreds of different clients for what ever desktop I want. 
(and IMO we need a own daemon for this and not HAL)

Btw. note powersave is only one example, This is a general design discussion. 

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

What mean you special with PowerMac? (k)powersave should also support PPC. 

Yes currently we don't support UPS and wireless mice/keyboards (IMO mice and 
keyboard is not really a powermanagement issue, but this is only my opinion), 
but only because this is currently not implemented this mean not we would not 
implement this. powersave is not feature freeze, we permanently enchance 
powersave and KPowersave. And if requested by the users, this could be one of 
the next issues.

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

Yes, but me make this configurable soon, since this was requested from a 
debian maintainer and from some users of other distributions (Gentoo, RH, 
Slackware ...).

> 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

This is from contrib dir and is not a supported user script. This is not part 
of the daemon at all. (IMO this is send from a powersave user and we collect 
such scripts in the CVS.) Btw. this is hotkey stuff and IMO o.k. if the user 
want use this.

> Plus, powersave is actually using HAL for some power=management
> functionality:
[...]
> So I'm rather confused.

Why confuced? I never ever sad we don't use HAL to get some information (and 
only to get information), but you can compile powersave also without HAL and 
this work also fine.

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

I never sad that it not make sense to have addons to read/collect usefull 
information and provide them in HAL.

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

Yes we fix ACPI bugs if really needed (and if not posssible to workaround in 
userspace) in kernel, but this depends on the problem and is maybe easier for 
a distribution as for only one user. 

In the case of the COMPAQ we would first try to check if the DSDT is broken or 
if a BIOS update is available (this is the first way). And if it make sense 
we can workaround this also in the powersave daemon.
 
> > 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)?

One example: If you only need a simple command to enable a device (e.g. a 
tablet of a Tablet PC), which could easy detect with HAL, we should use HAL 
to do this. If you need no bigger infrastructure you could add a little addon 
to HAL. And if the user like to run HAL without root privileges, this is also 
no problem, he must maybe only live without the feature.

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

This is a generall discussion. If you add e.g. for each broken bios a 
workaround to HAL, this is no longer easy to maintain and handle. In this 
case HAL is maybe sometime no longer work well. And this is only one example.

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

If you install (K)powerssave this also work perfect with a daemon which do all 
powersave things (without to install additional packages). ;-)

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

To read known information it's o.k. for me. But you could read this 
information (and additional do all other related things) also easy from a 
special daemon over DBUS. What's the problem?

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

? To read information: o.k. But are there so many apps which use the 
powermanagement part (suspend, powersave ...) of HAL ? I'm not complete sure 
but e.g. on SUSE there is no tool.

Cheers,

Danny