[kde] Re: Cannot configure processor speed in KDE 4.6
On Sat, Feb 12, 2011 at 01:03, Duncan 1i5t5.dun...@cox.net wrote: For a bit of perspective, according to LWN and other articles I've read, gnome3 has a similar power-option related brouhaha going on. In their case, it's deliberately forcing (no exposed GUI option, tho apparently it's still a dig-in-the-registry option) the laptop-lid-switch to activate suspend. There's a lot of users that don't /want/ it to suspend, preferring instead to have it only turn off the screen, or do nothing. Of course I don't/won't have gnome installed precisely for such reasons in other areas, but I specifically did setup my laptop to only turn off the /screen/ when the lid is closed. I specifically purchased it in part as a music player (smaller netbook, one of the first to have 100+ gig storage, which I've always wanted in a music player, the bonus being it's a fully functional computer too, the negative being it's rather bigger than most mp3 players, if still smaller than most laptops and even later netbooks), tho of course I use it for other things too, but for that purpose, suspending with lid-close would rather defeat the purpose. Additionally, as many, I like to be able to close the lid and carry it around, then open and use without having to resume, even from RAM. Then disconnect the lid switch. I did that to my laptop within the first month of owning it, as Fedora at the time had problems with configuring it properly. On my Dell is was just a screwdriver-as-a-prybar job to lift the plastic above the keyboard, and the connector was right there. So kde's not the only one with laptop power issues ATM. Meanwhile, AFAIK, the CPU frequency thing wasn't just kde. Apparently, that's been decided at the kernel/userspace plumbing level and with upower replacing hal, individual frequencies are no longer going to be passed thru to the user as choices. As I read it (I've not upgraded my netbook in awhile and my workstation doesn't use this stuff), they still expose the governer to the user, powersave (lowest speed), performance (highest), ondemand (scales up fast, down a bit slower), conservative (equally fast scaling both up and down), but apparently not the individual speeds (AFAIK, the userspace governor allows that, I believe it still will, but no mainstream tools will pass thru that exposure). So is there any way to leave it at wide open throttle, i.e. 2.7 GHz? Because locking it at 1000 MHz is ridiculous, I can barely use this machine. The reason given is that there's technical implications, race conditions, timing, thermal, in the throttling case little actual power saving at all (AFAIK the older throttling choices are being removed from the kernel entirely, to be managed automatically for thermal, etc, their original intent and they do /not/ save that much power, tho real frequency scaling, which /does/ save power, remains, for the newer hardware that has it), that the user can't be expected to track, so the emphasis is now on automated tools that fuzz the UI details like specific speeds a bit, giving the automated tools more flexibility in managing all those technical issues. Great, but until they actually work and don't leave me crippled at 1000 MHz at least let me manually override it. On which KDE component should I file a bug? Or should I file at my distro (Kubuntu)? What may have happened, however, is that kde 4.6 is actually out in front of the other changes, particularly if you're not running equally new kernels and lower-level user-space, so the choice is removed, but the capacity hasn't yet been, so some upgrade installs are getting locked at the last set cpu frequencies, until either the rest of the system catches up, or until the last set config is removed. It's a fairly recent kernel: u✈ganymede:~$ uname -a Linux ganymede 2.6.35-25-generic-pae #44-Ubuntu SMP Fri Jan 21 19:01:46 UTC 2011 i686 GNU/Linux ✈ganymede:~$ And I've removed all the config files, still the problem exists. This isn't the first time that's happened with kde, either. Early 4.5 had the same problem for early kde upgraders that didn't keep the rest of their system equally updated, but with graphics. Many users running outdated (in comparison to the new kde they were running) xorg, kernel, mesa, and graphics drivers, found early 4.5 rather buggy, visually. Remember that? No, I've disabled desktop effects since 4.2. Just buggy with ATI cards and FOSS drivers. The lesson, then, is to try to keep the entire system generally in sync. Don't run the newest kde unless you're running the newest kernel and lower level userspace, as well. For users dependent on semi-annual (or slower) distribution release cycles, that can mean sticking with the kde they ship, since they usually don't update the kernel, xorg, mesa, udev, upower, etc, in sync with kde. I see, thanks. The trouble is that kde's still developing rather fast, and for those with reasonably updated
[kde] Re: Cannot configure processor speed in KDE 4.6
Dotan Cohen posted on Sun, 13 Feb 2011 21:36:49 +0200 as excerpted: Then disconnect the lid switch. I did that to my laptop within the first month of owning it, as Fedora at the time had problems with configuring it properly. On my Dell is was just a screwdriver-as-a-prybar job to lift the plastic above the keyboard, and the connector was right there. Ouch! I /did/ want the lid switch to control the display, tho, both to save battery and because of the extra heat. And it was easy enough to find the acpi config in /etc/ and modify the command appropriately. But I didn't have the GUI trying to override that, either. If I had, you can be sure I'd have overridden the GUI, deleting a file if I had to. Fortunately, Gentoo's policy is to allow the user (a gentoo user being the sysadmin on a gentoo machine, they don't apologize for expecting their users to be able to configure things, and generally make no bones about the fact that if you want hand-held beyond appropriate documentation and a basic working as installed config where possible, perhaps another distribution is more appropriate for you than gentoo) to control optional dependencies, etc, at build and install-time (thus gentoo's source-based not bin-based policy as well), so that sort of element is likely to be controlled by USE flags at build/install, and a Gentoo user likely won't have to worry about Gnome pulling that fast one on them, unless of course they want it that way. And if gnome makes it a non-optional depend, or more likely, links it to polkit and similar functionality that many users want, well, disabling it may well end up in gentoo's gnome3 upgrade guide, by the time it rolls out stable (which takes awhile), and in a gentoo/ gnome dev's blog for ~arch/testing. (Yes, I know gnome3 is out, but don't have it installed nor will I, thus the still-speculative tone of the above.) I'll comment on the topic bit of the thread in another post. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
[kde] Re: Cannot configure processor speed in KDE 4.6
Dotan Cohen posted on Fri, 11 Feb 2011 11:11:30 +0200 as excerpted: The new KDE 4.6 power management applications do not have provision for adjusting the CPU speed. Because I am using a ~/.kde that was used in KDE 4.5 on a laptop, I am now stuck with the CPU of this KDE 4.6 desktop machine running at 1000 MHz, instead of it's native 2.7 MHz. I considered wiping to a new ~/.kde but I just have too many customisations in almost every KDE app to start over afresh. How can I set the CPU speed in KDE 4.6? Thanks! I recall reading about that. Apparently, the decision was (see how I did that) that it's inappropriate for mere users to be concerned about the details of power management such as CPU speeds. shrug But then again, I'm obviously no mere user, ever-since I was a kid, since it's a plain fact that no user serviceable parts inside doesn't apply to anyone with the slightest skills with a screwdriver and a replacement fuse for the inline holder (especially so if they're a 10 year old kid!), let alone anyone knowing how to use a soldering iron or cut-and- splice-and-electrical-tape wires when a cord gets chewed by the dog or something. So self-evidently, user doesn't apply to people like me. It didn't then and for much the same reasons, it apparently doesn't, in this context either. /rant To the solution, however. What, the bisect method (being a regular, I'm sure you've seen my posts describing it before) doesn't work? Maybe that mere user policy applies more directly to you than I thought? (Sorry, the whole subject has me in a bit of a mood, now.) Seriously, I'm absolutely a major customizer myself, so I know the feeling, but there's no way that'd stop me from bisecting the problem space down to the problem file, then likely into it, to the problem line, if the file itself has enough other settings to make it worthwhile, or simply to understand a bit more about the settings that make my system behave as it does. Start by trying a fresh user to verify it's a user settings problem, then, assuming it is, with kde shutdown for your normal user, backup and remove your $KDEHOME dir (~/.kde/ by default), then start kde, to verify whether the problem is in $KDEHOME or elsewhere, then repeat the process, each time splitting the problem space in half, until you've found the culprit file or even setting within the file. This bisect technique definitely takes a bit of patience, but little technical knowledge, and it works well for problems like this where the problem is either there or not (tho not so well for intermittent problems, since you never know for sure whether lack of the problem is because the test domain is clean or whether you've just not triggered the problem yet). Alternatively, try a bit of brain to avoid so much brute-force iteration. Combined with the above, an examination of the filenames can often eliminate 3/4 or 7/8 of the problem-space immediately (game stats and config files, for instance, aren't going to be where this setting is found), thereby replacing a round or two of the bisect algorithm. Or, it's not a given but there's a good chance that while the new power management doesn't have that option, settings are stored in the same place, and an strace -eopen power-config-command, probably piped to grep to eliminate most of the haystack and make finding the needle easier, could reveal the config file location directly, thus bypassing the whole bisect method mentioned above. Or temporarily downgrade back to the old version and strace it, since you know for sure it had to store the setting somewhere. I'd point you more directly at the file if I could, but I don't use that sort of powermanagement on my workstation, and I use laptop-mode-tools and scripted writes to the /sys/ based config files to control power management there, not the higher level kde stuff. So I don't know where it might be, except to observe that if it's stored in the normal kde config locations, you'll find the file in question in either $KDEHOME/share/ config/ or in an appropriately named subdir of $KDEHOME/share/apps/. But it's possible the config is stored elsewhere, possibly under ~/.config/ , for instance. But stracing has a reasonable chance of getting you a result, and if not, bisecting has a near 100% chance. Either way, you'll probably learn enough in the process to make the next time you need to find such a config option much easier to deal with. =:^) -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
[kde] Re: Cannot configure processor speed in KDE 4.6
Thanks, Duncan, I've certainly bisected ~/.kde enough times to know that the setting is most likely in ~/.kde/share/config. I've even narrowed it down to powerdevilprofilesrc I think. But I want to be sure that there is in fact no way to configure this the right way before I start surgery. I support quite a few users and I've learned that solving an issue the right way the first time makes me appear much more professional the next time. In any case, since when is KDE for users? Ever since KDE 4.0 was released the attitude is that KDE is not intended for uusers so I don't understand what this sudden outburst of remove an option in the user's interest is, especially as it leaves users stuck. -- Dotan Cohen http://gibberish.co.il http://what-is-what.com ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
[kde] Re: Cannot configure processor speed in KDE 4.6
I've been using powerdevil to configure CPU speed too, since KDE 4.5.0, but now, it does not seem to have any option to enable it (for example, in powersave profile). Now, all profiles are near the same, since they can't reduce/increase CPU speed, and thus, a bit useless in this matter. Or may I be missing some other app? ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
[kde] Re: Cannot configure processor speed in KDE 4.6
Dotan Cohen posted on Fri, 11 Feb 2011 16:34:21 +0200 as excerpted: Thanks, Duncan, I've certainly bisected ~/.kde enough times to know that the setting is most likely in ~/.kde/share/config. I've even narrowed it down to powerdevilprofilesrc I think. But I want to be sure that there is in fact no way to configure this the right way before I start surgery. I support quite a few users and I've learned that solving an issue the right way the first time makes me appear much more professional the next time. In any case, since when is KDE for users? Ever since KDE 4.0 was released the attitude is that KDE is not intended for uusers so I don't understand what this sudden outburst of remove an option in the user's interest is, especially as it leaves users stuck. For a bit of perspective, according to LWN and other articles I've read, gnome3 has a similar power-option related brouhaha going on. In their case, it's deliberately forcing (no exposed GUI option, tho apparently it's still a dig-in-the-registry option) the laptop-lid-switch to activate suspend. There's a lot of users that don't /want/ it to suspend, preferring instead to have it only turn off the screen, or do nothing. Of course I don't/won't have gnome installed precisely for such reasons in other areas, but I specifically did setup my laptop to only turn off the /screen/ when the lid is closed. I specifically purchased it in part as a music player (smaller netbook, one of the first to have 100+ gig storage, which I've always wanted in a music player, the bonus being it's a fully functional computer too, the negative being it's rather bigger than most mp3 players, if still smaller than most laptops and even later netbooks), tho of course I use it for other things too, but for that purpose, suspending with lid-close would rather defeat the purpose. Additionally, as many, I like to be able to close the lid and carry it around, then open and use without having to resume, even from RAM. So kde's not the only one with laptop power issues ATM. Meanwhile, AFAIK, the CPU frequency thing wasn't just kde. Apparently, that's been decided at the kernel/userspace plumbing level and with upower replacing hal, individual frequencies are no longer going to be passed thru to the user as choices. As I read it (I've not upgraded my netbook in awhile and my workstation doesn't use this stuff), they still expose the governer to the user, powersave (lowest speed), performance (highest), ondemand (scales up fast, down a bit slower), conservative (equally fast scaling both up and down), but apparently not the individual speeds (AFAIK, the userspace governor allows that, I believe it still will, but no mainstream tools will pass thru that exposure). The reason given is that there's technical implications, race conditions, timing, thermal, in the throttling case little actual power saving at all (AFAIK the older throttling choices are being removed from the kernel entirely, to be managed automatically for thermal, etc, their original intent and they do /not/ save that much power, tho real frequency scaling, which /does/ save power, remains, for the newer hardware that has it), that the user can't be expected to track, so the emphasis is now on automated tools that fuzz the UI details like specific speeds a bit, giving the automated tools more flexibility in managing all those technical issues. What may have happened, however, is that kde 4.6 is actually out in front of the other changes, particularly if you're not running equally new kernels and lower-level user-space, so the choice is removed, but the capacity hasn't yet been, so some upgrade installs are getting locked at the last set cpu frequencies, until either the rest of the system catches up, or until the last set config is removed. This isn't the first time that's happened with kde, either. Early 4.5 had the same problem for early kde upgraders that didn't keep the rest of their system equally updated, but with graphics. Many users running outdated (in comparison to the new kde they were running) xorg, kernel, mesa, and graphics drivers, found early 4.5 rather buggy, visually. Remember that? The lesson, then, is to try to keep the entire system generally in sync. Don't run the newest kde unless you're running the newest kernel and lower level userspace, as well. For users dependent on semi-annual (or slower) distribution release cycles, that can mean sticking with the kde they ship, since they usually don't update the kernel, xorg, mesa, udev, upower, etc, in sync with kde. The trouble is that kde's still developing rather fast, and for those with reasonably updated systems at least, newer kdes /were/ a significantly better user experience than older ones. However, with the maturity of 4.5 and now 4.6, that's becoming less of an issue than it was, so users already at about the 4.5.3 level or higher can more easily wait for their
