How to set up the screen saver to activate when the mouse is at a corner?

Duncan 1i5t5.duncan at
Mon May 16 00:41:36 BST 2011

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 

> 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 

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

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 

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:
More info:

More information about the kde mailing list