Cannot configure processor speed in KDE 4.6

[Duncan]

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 u"users" 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 
distribution refresh, without suffering the still relatively broken kde 
that <~4.5.3 was.

-- 
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.