Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 247614

Summary: >=gnome-extra/gnome-power-manager-2.24 cpufreq scaling regression
Product: Gentoo Linux Reporter: Jonathan Lambrechts <jonathanlambrechts>
Component: [OLD] GNOMEAssignee: Gentoo Linux Gnome Desktop Team <gnome>
Status: RESOLVED FIXED    
Severity: normal CC: amigadave, magowiz, mrpouet, pacho, tester
Priority: High Keywords: Inclusion
Version: unspecified   
Hardware: All   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---
Bug Depends on:    
Bug Blocks: 238650    
Attachments: libhal-glib binding patch
patch which add gpm-cpufreq module and other features
patchs for the gpm-prefs glade sheet
the new ebuild

Description Jonathan Lambrechts 2008-11-19 19:15:35 UTC
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
Comment 1 Gilles Dartiguelongue (RETIRED) gentoo-dev 2008-11-19 20:01:44 UTC
yes yes, we known and that's the only reason this is not in tree yet. leio will take care of it :p
Comment 2 Mart Raudsepp gentoo-dev 2008-11-19 23:59:45 UTC
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.
Comment 3 Nirbheek Chauhan (RETIRED) gentoo-dev 2009-03-11 15:33:12 UTC
Moved to tree (masked), also fixing description
Comment 4 Romain Perier (RETIRED) gentoo-dev 2009-03-13 16:01:13 UTC
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
Comment 5 Romain Perier (RETIRED) gentoo-dev 2009-03-13 16:02:10 UTC
Created attachment 184875 [details, diff]
libhal-glib binding patch
Comment 6 Romain Perier (RETIRED) gentoo-dev 2009-03-13 16:03:10 UTC
Created attachment 184877 [details, diff]
patch which add gpm-cpufreq module and other features
Comment 7 Romain Perier (RETIRED) gentoo-dev 2009-03-13 16:03:56 UTC
Created attachment 184878 [details, diff]
patchs for the gpm-prefs glade sheet
Comment 8 Romain Perier (RETIRED) gentoo-dev 2009-03-13 16:04:32 UTC
Created attachment 184879 [details]
the new ebuild
Comment 9 Gilles Dartiguelongue (RETIRED) gentoo-dev 2009-03-20 13:23:27 UTC
patches looks fine, will need to be compressed and pushed to our mirrors though given their sizes.
Comment 10 Olivier Crete (RETIRED) gentoo-dev 2009-03-20 14:06:49 UTC
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.
Comment 11 Mart Raudsepp gentoo-dev 2009-03-20 14:42:10 UTC
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.
Comment 12 David King 2009-03-20 15:10:50 UTC
(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.
Comment 13 Pacho Ramos gentoo-dev 2009-03-20 15:18:59 UTC
Isn't cpufreq-applet enough for changing governor if needed?
Comment 14 Gilles Dartiguelongue (RETIRED) gentoo-dev 2009-03-20 15:36:38 UTC
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.
Comment 15 Nirbheek Chauhan (RETIRED) gentoo-dev 2009-03-22 11:09:12 UTC
Added to tree, and unmasked, thanks for the patches mrpouet :)