On Wed 21. Jun - 19:35:39, Kevin Ottens wrote:
> 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. =)
No problem. It's ok as long as you join the discussion in the proper
moment ;-)
>
> 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.
Yes, definitely a good possibility if you like to go this way to be more
independent from a system daemon. You remember the thread about a common
dbus interface on the xdg@ list? I think we should take this into account
IMO. If the solid library abstracts the power management related
information for desktop applications and you don't like the hard
dependency to hal, fine with me and it's even easier for kpowersave or any
other application to get the information they need.
>
> 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. ;-)
Yes, in the end, I do not really care how a the specific desktop handles
this, either directly through HAL or through solid. That's up to the
desktop developers/designers. So if you like to go this way via solid,
fine with 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.
To understand this item, one definitely needs some knowledge about our
current architecture. At the moment the daemon only sends a screen lock
request to kpowersave which in the end performs the action. If no client
is connected, the system daemon does it on its own (ugly xlock). That's
also because of historical reasons. But because of the fact that this of
course can be handled properly soley in the session, I like to change how
things are done currently ;-)
>
> > - 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).
Agreed. And yes, the new kpowersave needs definitely some redesigning if
we go that way.
>
> > --> 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.
What I also liked to say with this is to seperate the
powersave-devel/users mailinglists from kpowersave development. A new
mailinglist just for "the new kpowersave" were maintenance (e.g. user
questions, development plans) are handled after the adaption is finished.
But I will subscribe to the kde-hardware-devel list to get involved in
regards to the power management area there.
>
> > - 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.
Yes, that was what I had in mind. And having this feature extension in
mind, a wrapper like a solid frontend is definitely a good idea. Just one
example, the GNOME desktop may not want so many different settings, and
therefore solid would extend the KDE desktop with power management
features. So in regard to this, it makes sence to use solid.
>
> > 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. ;-)
CPUFreq and the "processor" capability are two completely different
things. What is ment with "processor" capability in HAL is throttling
(t-states). And that's also something you do not want to do. It doesn't
save you battery lifetime and even causes a higher power consumption on
some more modern systems. But there's nothing about CPU frequency scaling
(c-states) in HAL currently. That's what I like to get in.
>
> > (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".
But I still try to get proposal (1) because I like to see that CPUFreq
"just" works on most systems which come with hal. But I also try to
combine (1) and (2) so that the solution in HAL could be used as seperate
daemon. But that's another topic...
>
> > [...]
> > 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).
It for example computes the total capacity for all batteries. Functions we
have currently are for example in regard to batteries:
/** @brief fills the given Battery struct with the current battery
* information for all found batteries */
int getBatteriesInfo(BatteryGeneral * bat);
/** @brief get Information for only one battery
int getBatteryInfo(const int no, BatteryGeneral *battery_info);
/** @brief get number of present batteries */
int numBatteries(void);
/** @brief get detailed information about just one single battery */
int getBatteryDetailedInfo(const int no, BatteryDetailed * bd);
Having a look at this library definitely may help to reuse existing
code. Why not reuse it in solid...
>
> > - ...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.
I don't expect gnome-power-manager using this library, but as mentioned
before, also our small clients (e.g. wmpowersave) and the daemon will use
it. I could imagine to host it together with Solid, this wouldn't be an
obstacle. But I really like to see a possibility to also have it as
independent package, independent from KDE for the named applications using
it.
>
> > 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.
That's also something we can care about at a later point in time.
>
> > [...]
> > 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. ;-)
But exactly the generic support for many strange system setups or other
desktops than the big ones is something our users appreciate these
days. And I don't want do completely lose this support. Having said that,
we both already wrote that it should be considered with lower priority ;-)
>
> > 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.
That would be great IMO.
>
> > - 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.
Yes, and because of this I wrote this proposal.
>
> > - 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. ;-)
Because of the fact that I'm always aiming at getting free beer, I hope my
comments fit your expectations :-)
>
> Regards.
>
> [S] http://solid.kde.org
Regards,
Holger
_______________________________________________
powersave-devel mailing list
powersave-devel@forge.novell.com
http://forge.novell.com/mailman/listinfo/powersave-devel
