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.
