the ebuild give this message To enable frequency scaling interface, use the following command: * gconftool-2 /apps/gnome-power-manager/ui/cpufreq_show * Note that this will conflict with other power managment utility * like app-laptop/laptop-mode-tools. but cpu freq scaling has been remove upstream Reproducible: Always
yes yes, we known and that's the only reason this is not in tree yet. leio will take care of it :p
To be clear, Gilles means I will work on reintroducing cpufreq support before this enters portage tree, not that I will be removing the message from the ebuild.
Moved to tree (masked), also fixing description
Please find in attachment 3 [details, diff] patches which reintegrate cpufreq feature : - the first patch re-add the libhal-gcpufreq module in libhal-glib binding, and include Makefile.am modifications - the second, re-add the gpm-cpufreq gnome-power-manager module, and add a instance of GpmCpufreq class in gpm-manager (to "catch" and treat "value-changed" signal) and include Makefile.am modifications too. - the last patch include modification if the gpm-prefs glade sheet. - and finally the new ebuild including these patches, and which make a call to eautoreconf to regenerate autotools file properly. mrpouet
Created attachment 184875 [details, diff] libhal-glib binding patch
Created attachment 184877 [details, diff] patch which add gpm-cpufreq module and other features
Created attachment 184878 [details, diff] patchs for the gpm-prefs glade sheet
Created attachment 184879 [details] the new ebuild
patches looks fine, will need to be compressed and pushed to our mirrors though given their sizes.
For the record, userspace-driven frequency scaling is a terrible idea, use on-demand or conservative governors. Please don't put it back in g-p-m. If you want to do terrible things, use something like laptop-mode-tools (which can do many other useful and/or terrible things). And lets get the new gnome-power-manager out asap.
There is no single choice of a governor. Some people tout that everyone should just always use ondemand, but it simply does not work sometimes. Some users would like to be able to enjoy their 720p or 1080p home movies instead of getting lots of stuttering caused by the ondemand governor. This is not user-space frequency scaling, this is kernel-space frequency scaling governor (algorithm) selection in user-space. Using just one certain governor without any possibility to change it simply does not work yet. I'd be glad if ondemand would finally be perfect, but that is not the case yet, at least not in linux version 2.6.28.
(In reply to comment #11) > I'd be glad if ondemand would finally be perfect, but that > is not the case yet, at least not in linux version 2.6.28. http://www.codon.org.uk/~mjg59/power/good_practices.html gives the solution. Simply ask Matthew Garrett and all will be solved! But seriously, it makes sense to not have a desktop application that can be used to change the governor. If ondemand breaks then either the application of the ondemand governor is at fault, and attempt should be made to fix one or the other. It should actually not be so easy to switch governors as a "temporary fix" to the problem, in my opinion. This addition of frequency scaling support should not be the default choice, at least.
Isn't cpufreq-applet enough for changing governor if needed?
guys please don't debate here, this is not the proper place. We are onto fixing a user level regression, we do not really care about what is the perfect/ultimate/whatever solution. If you're fine with the regression just unmask g-p-m locally and be done with it.
Added to tree, and unmasked, thanks for the patches mrpouet :)