Powermanagement - next steps
============================
Due to the ongoing discussions in regard to power management in userspace,
I've prepared some ideas and concepts which could be the next steps
regarding power management for linux in general and for us.
I will describe some details and will try to summarize the past
development and efforts we have made a little bit. So please excuse that
this mail will be a little bit more detailed, but it has huge impact on
the work we've done the past years regarding power management.
To summarize our efforts during the last month, we tried very hard to make
powersave distribution independent, opened up the development, we were
building packages for various distributions and added support for some
functionalities (e.g. suspend2) which are out there but did not affect us
directly. We got patches from the community, people decided to package it
for their preferred distribution, created wiki pages and so forth. So we
are still on the right way in regard to that IMO.
We also tried to work together with some HAL and gnome-power-manager
developers, but they have completely different opinions about how things
should be done and should work in regard to power management. The
gnome-power-manager approach uses HAL as the only power management backend
and thus lacks some features we are providing. On the other hand, more and
more power management functionality is put into HAL just because of this
missing functionality IMHO.
With our current solution, although we have a lot of success in
distributing powersave and more and more distributions (about 10, but
mostly small ones) are using it, we are running into a blind alley. I like
to explicitely emphasize that I still think that the current solution we
have, an independent and cross-desktop power management daemon similar to
the NetworkManager appoach, is the better solution. I think that the
powersave daemon with its DBus interface is a stable working, all in all
solution that could be easily used by other applications respectively
distributions.
But the other approach simply finds itself in a better position because
HAL comes along with any desktop distribution and they don't have to
advertise it to anybody. It just ships with almost all distributions these
days. If something is put into HAL, no matter if it's sensible or not from
a software designing point of view, everybody simply gets it. So it's
really hard to convince people why they should use powersave instead of
HAL/gnome-power-manager which doesn't provide all the functionality but
works. Nevertheless, I think HAL is misused for many power management
tasks these days.
So I see no possibility to enforce our solution for the future. I'm just
trying to get the best out of it to have better power management support
on linux in the end. And I would really love to see a common solution in
the end which is my most important goal. But nevertheless, I have really
mixed feelings while writing this mail.
I think the powersave daemon solution has always been "one step ahead" the
last years, but I see this advantage more and more shrinking when looking
at it from a desktop user's point of view because of other software like
gnome-power-manager and HAL.
The following is a plan we could take for the future. I'm convinced that
we don't lose any important functionality (if at all) and that it's the
only way which is feasible and helpful to not get pushed into a corner
like "everybody uses HAL, expect the powersave people, they use their own
thing for power management". These are fundamental changes for us, but
it's something which is "upstream compatible" and therefore of course
brings along some advantages.
Frontends: kpowersave - gnome-power-manager
===========================================
We currently face the problem that the two most important frontends for
power management are following completely different concepts.
Gnome-power-manager doesn't use any power management backend, except
HAL. In contrast to that, kpowersave heavily depends on the powersave
daemon which, on the other hand, makes it a lot more feature rich. But
depending on an extra backend which isn't available on most systems is a
hard requirement. Without powersave, kpowersave is almost useless.
But a lot of things like adjusting the display brightness, locking the
screen before suspending, defining battery limits or querying battery
information can already easily be done through HAL or other available
desktop interfaces nowadays.
So what I would like to be done is...
- Seperate kpowersave from powersaved. It should be useable and useful
also without powersaved
- Do everything which is possible via HAL, for instance:
- Brightness
- Battery limits and needed actions
- screen locking on suspend
- Best would be to get it into KDE4 by default which is a feasible
approch IMO
--> maybe move development tree to KDE svn
--> create mailinglist only for kpowersave related topics
- The Powersave daemon _may_ only _extend_ kpowersave with additional
functionality (if any)
Powersave daemon
================
Suspend to disk/ram
-------------------
Suspend to disk/ram workarounds/scripts completely go to the pm-utils
project which was created recently:
Easy hooks can be created to get the same functionality which we
provide these days. I think it shouldn't be that hard to convert/merge
our existing scripts into this new project. It's also a great
possibility to clear out workarounds we still have but aren't needed
anymore. It's also easy to extend pm-utils to do things which aren't
wanted in the upstream project but are maybe needed for distributions
or vendors.
CPUFreq
-------
CPUFreq is currenlty the only very important functionality which can't
be handled via HAL yet and should be available (at least on KDE) to the
desktop user, so...
I see three possibilities here:
(1) Do CPUFreq through HAL
I'm quite far with this solution already and will post it to the
HAL list the next days. No concrete questions regarding this,
please... ;-)
(2) Daemon only for cpufreq (powerfreq), independently from
HAL. Disadvantage is that than there is again no common solution
and it would again only be kpowersave which uses it.
(3) Keep it as is now
As mentioned already, I don't think it makes much sense to keep
that. Not because I don't think it's no good solution which we
have currently, but we are running agains a wall with trying to
get this as "the linux solution regarding power managent" which
doesn't help anybody. We are simply too late in time for trying
this...
Powersave libraries
-------------------
We currently have a set of libraries provided for convenience which are
used by kpowersave, wmpowersave, the powersave command line tool and
powersave itself. As a summary, it provides the following functionality
which is heavily used and might still be helpful in the future:
- Interface to query HAL for information which also cares about the
needed DBus connection
- Easy to use functions to communicate and send DBus messages to the
powersave daemon or using DBus in general
- Functions for summarizing and calculating battery information
- ...and some more
I would split these libraries into an own package (maybe called
powerlibs). The library can be used by any application related to power
management and should support developers in writing new power management
related applications.
The daemon itself
-----------------
The daemon itself serves only as fallback when noone is logged in, when
no clients are running and on servers. It's just another client without
GUI. I currently don't know yet how to realize this in detail because
the new common freedesktop interface will maybe be session based for
each user logged in to the system. But it's surely something we can
solve.
If CPUFreq can be handled without the powersave daemon, I can't imaging
any features which might need a GUI and should be controllable by a
desktop user at the moment. So anything which remains in powersaved does
not interfere with the desktop session.
The daemon only handles:
- On servers, if noone is logged in or where a system policy (by any admin)
forbids the user to make those decisions:
- Battery limits and takes needed actions
- sets a default cpufreq policy
- serves for things which don't fit into another package but are
needed for distributions (hotkeys, ATI graphics driver control,
etc. are things which are there at the moment) ... to be evaluated
- Harddisk settings
- keeps its configuration files for the remaining tasks
- handles custom acpi events
- maybe only _extends_ clients with features, if any
I already talked to some embedded people in the past about a plugin
driven system solution which would also fulfill the needs of the
embedded people. In this area, they might need more fine grained policy
decisions which can't be and shouldn't be controlled by a desktop
user. That's what the powersave daemon, or any other system wide power
management daemon could serve for, doing power management tasks behind
the back of the user that "just works" and needs no interaction. But
that's the far future. In the first step, the powersave daemon itself
will tremendously lose importance and functionality.
Powersave schemes
-----------------
The existing schemes (Powersave, Performance, Acoustic, Presentation)
could be implemented by the client, except Acoustic. If we still like to
have an Acoustic scheme, which isn't that important IMO, we could
abstract the harddisk settings into HAL or let kpowersave be extended by
that feature which could be still provided by powersaved.
There were some opinions in the past that there is no need need for the
other schemes than Powersave (unplugged) and Performance (plugged). Some
time ago, we talked about kpowersave being able to create and delete
schemes in its configuration dialog. So if distributions/projects don't
like Acoustic, Presentation or whatever, they simply don't have to ship
these schemes in the kpowersave configuration. Other may ship them by
default.
Powersave command line client
-----------------------------
To keep up the support for non KDE/GNOME systems or where no frontend is
available, extend the powersave command line tool to serve as a session
daemon for caring about minimal requirements like display brightness
and/or screenlocking (xlock). That shouldn't be that hard to accomplish,
but also shouldn't be considered with high priority. Maybe we find
someone using such a 'old-fashioned' windowmanager doing it for us ;-)
Advantages
==========
- Possibility to configure and set power management policy on the
desktop
- System policy does not interfere with desktop policy
- e.g. no need for kpowersave to overwrite the configuration of
powersaved which we considered as solution some time ago
- We get kpowersave as real upstream solution for KDE and chances are
good that every distribution will ship it alongside with their KDE
packages
- Does not interfere with gnome-power-manager and we get a good working
solution for both desktops. They can independently decide which
configuration options they want to present to the user
- Although YaST2 is the main configuration tool on SUSE, it always was
an obstacle for other distributions to not have a graphical
configuration tool for powersaved. This disadvantage will vanish
Disadvantages
=============
- We lose an already good working solution regarding system power
management and KDE
- I'm still in doubt that the way of using HAL for a lot of power
management tasks is future proof and really works out in the long run
Comments are greatly appreciated. In the end, I like to get something
everybody is pleased with.
Regards,
Holger
_______________________________________________
powersave-devel mailing list
powersave-devel@forge.novell.com
http://forge.novell.com/mailman/listinfo/powersave-devel
