Lock and Suspend

So I'd gotten the trick (actually I believe it worked out of the box) for getting my laptop to suspend to disk/suspend to RAM via the Thinkpad keys. My only issue was that if I wanted to lock the screen as well, I had to manually start the screensaver first, then hit the Fn-F4/Fn-F12.

Not a huge deal, but not an ideal solution. Earlier today I was hunting around for something else and came across a posting about Fn-F2 locking the screen. I thought it'd be nice, so I experimented a bit with the hibernate and sleep script that gets run when I hit the hotkeys but didn't have any luck.

Google to the rescue...a quick search shows the following:

dcop kdesktop KScreensaverIface lock

So I modified the script to run that right before the sleep command was issued, stopped/started the ACPI service, and voila!

Nothing. Just went to sleep.

So I tried running the command from the command-line as root since that's how the ACPI scripts run, and got the error:

ERROR: Couldn't attach to DCOP server!

Ah. Of course. Since I do the smart thing and run as a normal user, root doesn't have a DCOP (Desktop COmmunication Protocol) server running for itself, and so screensaver can't run. In fact, even if it was running a DCOP server, it would only lock the gui session that root was running. So:

root@doesitmatter:/home/slackwarehacker# dcop --help
Usage: dcop [options] [application [object [function [arg1] [arg2] ... ] ] ]

Console DCOP client

Generic options:
--help Show help about options

Options:
--pipe Call DCOP for each line read from stdin. The string '%1'
will be used in the argument list as a placeholder for
the substituted line.
For example,
dcop --pipe konqueror html-widget1 evalJS %1
is equivalent to calling
while read line ; do
dcop konqueror html-widget1 evalJS "$line"
done
in bash, but because no new dcop instance has to be started
for each line this is generally much faster, especially for
the slower GNU dynamic linkers.
The '%1' placeholder cannot be used to replace e.g. the
program, object or method name.
--user Connect to the given user's DCOP server. This option will
ignore the values of the environment vars $DCOPSERVER and
$ICEAUTHORITY, even if they are set.
If the user has more than one open session, you must also
use one of the --list-sessions, --session or --all-sessions
command-line options.
--all-users Send the same DCOP call to all users with a running DCOP
server. Only failed calls to existing DCOP servers will
generate an error message. If no DCOP server is available
at all, no error will be generated.
--session Send to the given KDE session. This option can only be
used in combination with the --user option.
--all-sessions Send to all sessions found. Only works with the --user
and --all-users options.
--list-sessions List all active KDE session for a user or all users.
--no-user-time Don't update the user activity timestamp in the called
application (for usage in scripts running
in the background).


Aha! The "--user " looks interesting. But wait, there's more! While specifying the user is fine and would work (I'm the only one who uses this laptop), it's still a bit of a kludge. So instead, I used the "--all-users".

I changed the scripts appropriately, and it worked perfectly. Now Fn-F2 or Fn-F12 locks the screen first, then sleeps or hibernates.

Getting all this working of course got me thinking about the other Fn keys, so I looked around some more for the trick to enable Fn-F5, which should be wireless on/off. I finally found that the key wasn't recognized unless I did:

echo 0x0000ffff > /proc/acpi/ibm/hotkey

Also, this is reset after reboot. So, I modified the wireless script called by the hotkey to determine the status of eth1, turn it off it it was on, and turn it on if it was off. If it was being turned on, the script also ran the tunnel script to open up my ssh tunnel back to my house (if necessary). Works pretty good now, and all the hotkeys I'm interested in are fully functional.