Hi list, I slightly hijack this thread to introduce myself. I was tracking progress there, and was about to make this introduction anyway. =)
I am Kevin Ottens (aka ervin on IRC), and I'm working on the hardware interaction from the desktop for KDE4 this ongoing effort is named Solid[S]. It's the continuation and extension of my work in KDE 3.x with the media:/ ioslave. In this regard I'm planning to have Solid addressing network and power management. I got interested in powersave hence why I'm subscribed here. Now you can blame me for not making this introduction earlier. =) Ok, time to comment this looong and interesting mail. I'll try to explain where I think it fits or not my plan for KDE4, and where we could (and surely should) collaborate better. Le mercredi 21 juin 2006 16:52, Holger Macht a écrit : > [...] > Frontends: kpowersave - gnome-power-manager > =========================================== > [...] > So what I would like to be done is... > > - Seperate kpowersave from powersaved. It should be useable and useful > also without powersaved Taking in account your introduction, it definitely makes sense to move this way. > - Do everything which is possible via HAL, for instance: Of course, since I'm biased here I'd propose to use HAL through Solid. This way, you get a nice C++ wrapper around HAL that handles all the gory details for you. Moreover, since its architecture is frontend/backend based, you'll gain portability on other platforms where HAL is not available (if Solid get a proper backend), and if HAL behavior is modified we'll be able to compensate this from the relevent backend. In my opinion it would be a win-win situation, since it'll make you closer to KDE upstream, ensure that Solid classes fully cover power management needs and offload some work from me. ;-) > - Brightness > - Battery limits and needed actions HAL already gives those features, most of them are already exposed via Solid, so that's fine for me (assuming my previous comment is addressed). > - screen locking on suspend Hmm, shouldn't it be done from the session? I've not seen anything related to this from a system daemon. > - Best would be to get it into KDE4 by default which is a feasible > approch IMO > --> maybe move development tree to KDE svn That's definitely welcome IMO, I already proposed it to Danny Kukawka if I remember correctly. Actually the timing would be pretty good for such a thing since I introduced some powermanagement related classes. I think the current backend would be lost, but the frontend part is (hopefully) a good basis for a new kpowersave (although it still needs some work). > --> create mailinglist only for kpowersave related topics Or use the kde-hardware-devel list which already exist and has a relatively low traffic right now. > - The Powersave daemon _may_ only _extend_ kpowersave with additional > functionality (if any) Looks like a good idea, if you go the Solid way, the interface I designed (which has been very influenced by powersave btw) allow to query the backend about the supported features. So the new backend I would imagine could simply indicates less features when powersave daemon is not here, and provide the full feature set when it's available. > Powersave daemon > ================ > [...] > 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... ;-) Actually that would be an interesting move, the "processor" capability being quite limited in HAL currently. ;-) > (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. Well, that would be fine with me. In particular with my earlier comment on how to deal with an "optional daemon". > [...] > 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 Which is actually quite useful, maybe it's something we might want to fit in the Solid frontend? I assume that the computations done on this are the same independently of which subsystem reported them (if you get the same information of course). > - ...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. My previous suggestion of course means that some parts of this get merged in kdelibs. Maybe that doesn't fit your plans, it would make sense to keep this independent from KDE. On the other hand it would be nice to host it there. > The daemon itself > ----------------- > [...] Not much to add there. That definitely makes sense IMO. > 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. Regarding Acoustic scheme, I'm fine with both solution actually. > [...] > 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 ;-) Right, definitely not high priority IMHO. ;-) > 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 Definitely the best improvements. > - We get kpowersave as real upstream solution for KDE and chances are > good that every distribution will ship it alongside with their KDE > packages Well, as I hinted earlier if it fit my plans as I'd love to see it happens it'll surely be in kdelibs+kdebase. > - 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 The gain would be that it would be closer to upstream though. > - 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 I admit I also have some worries about this. It raises the complexity of this daemon. On the other hand it's current architecture seems to allow to keep this manageable. > Comments are greatly appreciated. In the end, I like to get something > everybody is pleased with. Well, I'm honestly quite satisfied by this mail, I was a bit worried because of our previous discussion on IRC. Your proposal looks like the way out IMHO, and it'll mean more contributions to important components which is the right thing to do if we want them to fit our needs. You already get my vote, moreover if your plans get slightly reajusted as I proposed in this mail I'll definitely owe you a beer. ;-) Regards. [S] http://solid.kde.org -- Kévin 'ervin' Ottens, http://ervin.ipsquad.net "Ni le maître sans disciple, Ni le disciple sans maître, Ne font reculer l'ignorance."
pgpflabykktNF.pgp
Description: PGP signature
_______________________________________________ powersave-devel mailing list powersave-devel@forge.novell.com http://forge.novell.com/mailman/listinfo/powersave-devel
