GNOME Bugzilla – Bug 577434
[PATCHES] gnome-extra/gnome-power-manager-2.26 cpufreq regression (upstream)
Last modified: 2012-03-23 09:45:53 UTC
Please describe the problem: Hi, i'm gentoo gnome-overlay contributor and i written patches to re-integrate cpufreq feature in gnome-power-manager and gnome-power-preferences, it's especially for other distributions ;) you could find patches at link : https://bugs.gentoo.org/show_bug.cgi?id=263891. mrpouet Steps to reproduce: 1. 2. 3. Actual results: Expected results: Does this happen every time? Other information:
Created attachment 131764 [details] [review] libhal-glib API patch
Created attachment 131765 [details] [review] daemon and gnome-power-preferences patch
Created attachment 131766 [details] [review] glade sheet gnome-power-preference patch
Created attachment 131767 [details] [review] translation updates for gnome-power-preferences
Please find in attachments patches which re-add feature
I really miss this feature too.
What's the logic for adding this feature back? Now ondemand works, there's no need to change the governor at all.
Richard, I think it is mainly psychological, but having the cpufreq-applet graph jumping up and down while the laptop is AC powered gives me a strange feeling... If you assure me that the speed is exactly the same with ondemand and performance governors, than I think I will remove the cpufreq-applet from the panel :)
Luca, there are a few use cases where ondemand doesn't do the right thing. A few are: * Low latency intermittent database accesses * Decoding on a processor that is very close to saturation for a lot of the burst time Neither are typical on a workstation and in the 0.1% of cases where such special tuning is being used, the user sure isn't using gnome-power-manager, or even Xorg. Using ondemand in preference to performance (or powersave) actually saves a lot of power.