gene heskett posted on Sun, 15 May 2011 14:42:42 -0400 as excerpted:
> Marcelo, I have no clue, and despite asking here and there, no has told
> me yet why x/kde turns off the DPMS & such when it starts, leaving you
> only with the power wasting screen decorators.
I believe I missed that thread/subthread. FWIW I get the normal graphics
output powerdown and subsequent monitor suspend just as I always have, so
it's not a general kde thing.
> I made me a ~/bin directory years ago to hold the stuff that I need as
> the lone user of this machine
AFAIK that's pretty much standard, at least for users shell literate
enough to make any use out of it, single-user machine or not. That a user
has his own user bin dir (~/bin/ or whatever they've chosen to make it)
and that it's on their path has certainly been assumed by some of the
stuff I've read over the years. And actually, I believe many
distributions still come configured to create a skeleton user dir that
includes ~/bin by default, when their standard user creation tools are
used.
> Anyway
> ------------------
> #!/bin/bash
> xset +dpms
> sleep 1
> xset dpms 0 0 450
> ------------------
That looks much like the scriptlets I created, to be activated on-demand
when I want to immediately turn off the screen, or force it to stay on.
The stay-on is a one-liner. "xset -dpms"
The display-off I created a scriptlet for, as it needs a sleep, otherwise
it runs and shuts the display off before I've released the activation key,
which immediately turns it back on! But it's just a two-liner:
sleep 1
xset dpms force off
As you can see, I don't actually change the timers at all. They remain as
set by default. I simply force the display off when I want it off, or
disable the timers if I want it to stay on.
In kde3 I had khotkeys configured with two-key hotkeys, the first key (an
"extra" key on my inet keyboard) effectively launching a menu, the second
choosing which of the configured actions to run from it. kde4 broke that,
as it only takes a single hotkey at a time. But eventually I realized
that what I was effectively doing was two separate actions, the first
hotkey launching a menu applet, from which the second action was chosen.
So I scripted up a solution for the menu applet and used kde4's khotkeys
only to launch it, in a special konsole profile with special window rules
to force it centered and always-on-top. The menu shell script is
therefore launched by khotkeys in this centered konsole window, and takes
exactly one (possibly ctrl or shift modified) key, which in turn launches
the specified app.
My power management applets are then setup on the [] and {} (shifted [])
keys in the menu applet, setup so the left key ([{) applies to the display
only while the right key applies to the entire machine, and the shifted
version is the more "drastic" action. From my hotkey.lst file:
[ display-stayon xset -dpms
{ display-off displayoff
] standby sudo /l/sbin/standby
} s2disk sudo /l/sbin/s2disk
So all I do is <launcher>[ to disable the shutoff, or <launcher>{ to
trigger immediate display shutoff. Similarly, <launcher>] and <launcher>}
go into suspend-to-ram and suspend-to-disk mode, tho I only use those on
the netbook. (s2disk sometimes works on my main machine, but not reliably
enough to use it, so I just leave it running.)
I have similar two- or three-stroke shortcuts for the web-browser
(launch-w), nntp-client (launch-n), mail-client (launch-m), feed-reader
(launch-r), kcontrol/systemsettings (launch-s), text-editor (launch-e),
calculator (launch-c), filemanager (launch-f), patience and palapeli
(launch-p and launch-P), terminal (launch-t)... mounting/umounting my
auxiliary mounts, resetting krunner if it quits responding, to my bank's
secure-login website, to various bugzillas (kde, gentoo, pan, I need to
set one up for the kernel), gwenview, keyboard auto-repeat-rate changes
(fast or slow), router, VoIP-phone-ata and modem logins, alternative
browser...
So I obviously don't use the regular launch menu (kickoff or classic) that
much -- only for apps I don't use that often and need to go exploring the
menu to remember. (Apps that I do remember but don't have a hotkey
launcher for, I'll as likely launch from krunner, especially since all I
need is three letters to get a listing there, if it's in the menu. This
includes kruler, kolourpaint, etc. Or I'll launch-t (konsole) and use
bash's tab-completion if it's not in the menu.)
> If KDE had an init.d, which I haven't found
I thought we went thru that with the kmail script you wanted to run at
startup, and you had it working...
kcontrol (umm... systemsettings that aren't), system administration,
startup and shutdown, autostart.
The add-program button really means add *.desktop file -- it expects to
find a menu entry for it. This is actually a freedesktop.org standard.
For obvious reasons (starting *.desktop items at X shutdown??), these can
be run at startup only. Note that once an entry is added, with it
selected you can click the advanced button and control whether it starts
in other freedesktop.org compliant desktop environments (gnome and xfce I
believe do this) or only in kde.
Add-script lets you add a script (or symlink to a script), which should be
preexisting and end in .sh. The default is startup, but once you've added
a script, there's a dropdown in the listing which lets you change that to
pre-kde startup or to shutdown, if preferred.
If you prefer the less hand-holdy drop-it-into-a-dir method, the
directories for these locations can be found in various locations in your
home dir. (Shell scripts should be executable or they probably won't
run. Symlinks are fine, but make sure what they point at is executable.
kcontrol doesn't warn about it for startup scripts, but if you try to
change a startup script to pre-startup or to shutdown and the script name
doesn't end in .sh, it complains, so *.sh files are recommended or the
script might not run.)
The paths settings (kcontrol, common appearance and behavior, account
details, paths) allows you to check or set the scripts/autostart path.
The freedesktop.org standard *.desktop autostart directory path is
$XDG_CONFIG_HOME/autostart/. ($XDG_CONFIG_HOME is ~/.config if the
variable is unset.)
The shutdown path is $KDE_HOME/shutdown/. ($KDE_HOME defaults to ~/.kde
if unset, as shipped by kde upstream, but many distros change that to
~/.kde4.)
The pre-kde-autostart dir is $KDE_HOME/env/.
> I have no clue where in the startup DPMS gets shut off, according to my
> Xorg.0.log, it is still enabled at the end of the x startup logging, but
> it will not work, and never has since kde4 came out, until I either run
> this script or do the 2 important 'xset' lines by hand from a konsole.
As I said in my reply up-thread, monitor auto-suspend works just fine
here. I don't currently have the powerdevil app merged/installed and so
don't get any kcontrol settings for it (I think that's what they were
associated with), but even when I did, it worked fine. However, without
that installed I can't tell you where to look in kcontrol for the kde
settings.
But with the above info about autostart, given that you're reasonably
shell literate and have xset scripts already setup, it should be no big
deal to set them to run at kde start, if you can't find the kcontrol
settings or they're broken. One caveat. I'm not sure on ordering. You
may have to set a sleep 60 or some such before the xset, to be sure it
triggers after whatever kde setting is turning that off.
--
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.
