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