Le mercredi 21 juin 2006 21:35, Holger Macht a écrit : > On Wed 21. Jun - 19:35:39, Kevin Ottens wrote: > > 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.
Yes, I remember this discussion. The DBUS interface proposed there is designed to be implemented by session wide policy applications. Hence why it looks like it should be exposed by kpowersave. That would give us something like: [Solid::PowerManager class] -used by-> [kpowersave] <-implemented by- [fd.o DBus Iface] -used by-> [Desktop apps] The proposed DBus interface looks fine for the average desktop application needs, but this way we would keep the Solid::PowerManager class available for special applications that don't care about the policy implemented in kpowersave and would need finer grained information (like desktop applets). > > 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. Great. > 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. That definitely makes sense regarding the new way you want the development to be done. > But I will subscribe to the kde-hardware-devel list to get involved in > regards to the power management area there. Ok. > > 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. Agreed. My point was more to be able to control the c-states from devices holding the "processor" capability (you can't do this currently). But maybe I was unclear, or I'm missing something. > 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. Then it's better to keep it outside of kdelibs to encourage people to depend on it. Which is the right way to go to keep wmpowersave and friends alive. > Because of the fact that I'm always aiming at getting free beer, I hope my > comments fit your expectations :-) Definitely! So you've just fullfilled your aim. ;-) Regards. -- 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." _______________________________________________ powersave-devel mailing list powersave-devel@forge.novell.com http://forge.novell.com/mailman/listinfo/powersave-devel
