GNOME Bugzilla – Bug 153311
Inclusion of a CpuFreq applet
Last modified: 2004-12-22 21:47:04 UTC
I'd like to see some support of a CpuFreq applet in gnome-applets. CpuFreq allows you to monitor and change the frequency speed of your laptop, a very common feature of other Desktops/OS. CpuFreq is currently supported on Linux only. I don't know if the BSD have such a system. It's exporting and reading new settings using the sysfs and is working through a driver, called a governor, that exposes and applies the settings. There are already two implementation already: - gnome cpufreq applet (http://linups.org/~kal/gnome-cpufreq-applet/) - emifreq applet (http://zzrough.free.fr/emifreq.php). Here are the pros and cons of each (warning: it could be really biased, lol): - gnome cpufreq applet: * supports multiple processors * additional support for the old /proc interface (but it's been deprecated since 2 majors kernel releases) * little bit older, no changes since 3 months it seems * you can show/hide different settings regarding frequency * basic a11y work as far as I can see in the code - emifreq applet * single cpu supports, multiple support the next release * actively maintained * quite old too but only announced a month ago, a lot of positive feedback for the UI * very HIG UI, simple preferences, gnome-ish look (thanks, Jimmac, for the icon) and modeled after the wireless applet (look, no update interval in the preferences, ...) to be more consistent with the desktop * display the CPU temperature * really nicely supports vertical panels (icons and text rotating), this has been appreciated by a number of users * an optional daemon that allows to easily change the processor frequency thanks to an easy popup menu in the applet, but designed to work w/o it if it's wanted I think this is a really needed feature in every modern desktop. Being able to modify the frequency is also really needed, but it seems there's a trend not to use more daemons than we already have, but in emifreq, everything is ready not to enable the daemon. Well, if people really wants (a lot of people seems to be intersted), the good stuff is they can download the daemon apart from the GNOME desktop and it'll just activate automagically :) I think both projects are mature enough to be imported in the tree, so let's have a discussion about which one needs to be picked up or if we need to take half of each code base or something. (and you know what, I am a supporter of emifreq since I wrote this little app for my girlfriend ;)
Need to get some action on this, CCing Carlos to generate some discussion.
* little bit older, no changes since 3 months it seems gnome-cpufreq-applet is also actively maintained, the last release was in October, less than 3 months. * additional support for the old /proc interface (but it's been deprecated since 2 majors kernel releases) There are still many users who have a 2.4 kernel. IMHO it's very important to keep the support for old interface. gnome cpufreq applet also allows you to change the cpu frequency, but without a daemon. I only want to add: gnome cpufreq applet * supports all governors even the new ondemand governor. * all of those advantages of the emifreq, except to display the temperature, are also in the gnome cpufreq applet (HIG, vertical panels, frequency selector, etc.) * AFAIK the gnome cpufreq applet is already included in several linux distros
first: sorry to answer that late, but I don't receive the comments where as I'm the one who opened the bug, it's weird. * sorry for the release, I didn't see this one, so I thought it wasn't maintained that much because at that time there was no website. now there's gnomefiles.org, so that's fine. * for the /proc interface: you sure you don't mess up kernel versions ? Isn't /sys supported in 2.4 ? I think /proc is only useful for users using 2.2, and the cpufreq support is there, well, more primitive. * if gnome-cpufreq-applet allows you to change the speed, it's certainly with spawning a sudo command or something ? you need to type your password each time or is it using pam or something ? just curious ... * last time I checked, when you use g-c-a on a vertical panel, the display was completely screwed up: I'd get half an applet because it's too wide. Did you change the label and icon positionning in the last release. I'll test the last release when I'll have a chance. * emifreq is in mandrake, which also provides a package for the daemon, that you can install separately. But know, I really wonder like other ppl on d-d-l whether it's that useful if you can't modify the speed ...
g-c-a is registered in gnomegiles.org since "June 17, 2004". I think it's enough for a so simple program. I don't think it needs its own website. I've received many bugs and comments from people who are still using the deprecated /proc interface. g-c-a allows you to change the frequency with a suid root command. You can avoid the installation of that command or not install it suid root. I think it's better to use a command for a task that is not used too often, instead of having a daemon that is running all the time. The activity level of a project is not the number of releases. I don't like to do a release for every commit because it supposes a big effort to users and package maintainers of linux distros. You can have a look at the cvs commits to get a more precise activity level of a project.
A few quick points: - not even gnome-applets itself has a website - Linux 2.4 does not have the /sys interface, that's an addition in Linux 2.6 - I am not fond of the idea of having a daemon running - A suid binary is also not really a good solution, but as Carlos indicated that can be avoided. Ideally we would give instructions to HAL, or use a security model like SELinux to indicate we were allowed to play with the CPU speed. Is there any chance of you two joining forces on this? I am finding myself leaning towards Carlos' applet, but you are both active maintainers and that makes it rather hard to choose with a view towards the future. Things I'm looking at for GNOME 2.10: - Retouching the artwork Not really something for the programmers, but I think the artwork could do with a bit of a touchup. Neither of the two existing artworks really has what we're looking for. Stéphane, you'll notice that the WiFi applet that inspire the look of your applet now has new artwork as the coloured squares are not very visible. - Abstraction of the frequency monitoring This may already be done, ideally the frequency monitoring should be separated out completely so that it can easy be modified portability. This should also allow us in the future to switch to a HAL backend, where we receive speed changes via DBus.
Carlos: g-c-a allows you to change the frequency with a suid root command. You can avoid the installation of that command or not install it suid root. I think it's better to use a command for a task that is not used too often, instead of having a daemon that is running all the time. That's the whole point of my applet, half the ppl wants to change their cpu speed really often. That's why on proprietary OS, you can change it, whenever you take the train, you watch a movie, you develop, you're writing a document, you play... these tasks don't require the same cpu usage. Because it's less heat, noise and save your batteries. That's why I aimed it to be so easy to change (two clicks and easy to use). As for the activity of a project, it's definitely how often you release. Well, that's what I think and what everybody because we don't have has much visibility on your project than you have. Sorry, but your project really seemed dead having a couple of fixes after a couple of months. Off course releasing for just a commit if it's not critic is stupid, I agree so much on that :) Davyd: - sysfs, ok, I'm on crack these days. Otherwise, I knew for the daemon, that's why I think emifreq doesn't make any sense in gnome-applets. I think it would be wiser to use g-c-a if it's just to show speed of your Cpu. Now, I don't realize yet the use of an applet that always display the same icon and value :D No, I mean, really :) Then it's not an applet anymore, it's just as useful as Wanda the fish :P So I think emifreq is definitely not suited for a Desktop component, and it seems g-c-a supports everything of emifreq, so let's make it wise : choose g-c-a ;) Off course the HAL approach seems interesting too. As for the graphics, it sure could be more polished. I'm off track here, Glynn's wireless applet has been completely superceded by Mark's network monitor ? I saw on a doc the display for reception level, it sure is easier to read too.
We have chosen to go with Carlos' applet. Stéphane thanks for all your effort, I encourage you to contribute again in the near future, as the desktop always needs more eager bodies and minds.
thanks, but I dropped my remaining bits of maintainership recently, so I think it's good time to switch for fresh blood after a while. Sorry for turning my back and asking the usefulness of the applet w/o switching the speed after having proposed emifreq: I can understand that's not a strong position, but after having thought about it, I just wanted to mention that. Now I'm following the thread about daemon in d-d-l, it might become really interesting. Looking forward for g-c-a in 2.10 ^^