|
|
( 19.06.2004 )
|
|
|
|
( 18.06.2004 )
|
|
|
( 31.05.2004 )
|
|
|
|
( 14.05.2004 )
|
|
|
|
( 22.04.2004 )
|
|
|
( 17.04.2004 )
|
|
|
|
( 16.04.2004 )
|
|
|
|
( 05.04.2004 )
|
|
|
|
( 01.04.2004 )
|
|
|
|
( 01.04.2004 )
|
|
Prolong LCD life with Apple menu 'Display Sleep' feature
|
|
|
Top level
Mac OS X
knowledge base
unix
|
As the proud new owner of an Apple 17-inch Studio Display (soon to be the smallest model in their product line!), I wanted to find a way to prolong its life by turning off the backlight when I was away from the computer. This article describes the steps taken to put a "Display sleep" menu item in the Apple menu. Some third party tools are required.
|
Reasons for wanting to turn off the backlight
Unlike normal monitors, LCDs are working their hardest when they are displaying a black screen. This is because the LCDs (the diodes, that is) have to block all the light coming from the backlight in order to darken each pixel. As such, it's not enough to simply blank the screen or run a screen saver. Screen savers protect CRT monitors just fine and avoid the "burn in" problems, but for LCD monitors they're nothing more than entertainment, albeit cool entertainment.
The only way to really prolong the life of an LCD display is to put the display to sleep, turning off the backlight and putting the device in a very low power mode.
I leave my machine running 24 hours a day, but I certainly don't want the screen shining bright all that time. But neither do I want to use the Energy Saver preference pane to put the display to sleep after 10, 15, or however many minutes of activity.
So I was looking for a solution to put the device to sleep from the Terminal, and then somehow put a link to that in the Apple menu, so that I could put the display to sleep quickly and easily whenever I wanted, without having to open up the System Preferences pane every time and play with the Energy Saver settings.
How it's done
Make a couple of shell scripts that do the dirty work for us using the "pmset" command (where "pm" stands for Power Management). See the pmset man page for more info. Here are the scripts we'll use:
#!/bin/tcsh
/usr/bin/pmset -a dim 0
|
That's the first one. I chose to save it as "~/bin/displaysleepoff.sh". Note that if you don't already have a ~/bin directory you'll have to create it. This script simply calls the pmset command and tells it to never put itself to sleep. The "dim 0" effectively means "dim after an infinite amount of time". So when we run this script it will turn off display sleep. You could set this value to any number of minutes if you don't like the idea of having an unlimited setting here.
#!/bin/tcsh
/usr/bin/pmset -a dim 1
|
The second one is called "~/bin/displaysleepon.sh" and in this case the "dim 1" means go to sleep after one minute. It turns out that this is the closest we can come to instant sleep (for now).
Running the scripts elegantly
I like elegant solutions. So I needed to figure out the best way to run these scripts. If I saved them with a ".command" extension then double clicking on them would fire them up in the Terminal. This wasn't desirable to me because I didn't want to have a window flashing up every time I used them.
It turns out that the most elegant solution is to use the stunningly simple and effective shareware application, ScriptGUI. After downloading this little application (only tonight) I have fallen in love with it. ScriptGUI allows you to run any script that will run in the Terminal (any language that will run in the Terminal, ScriptGUi can use) and it will display the output (if any) in an unobtrusive Aqua window.
The two killer features that set it apart from the other graphical wrappers for CLI commands (like DropScript by the great Wilfredo Sanchez) are these:
-
It can handle STDIN, thus enabling you to write scripts that request user input and interaction. These scripts can be double-clickable and drag-and-drop aware!
-
You can save your scripts as "Scriptlets", which are tiny, standalone applications that you can send to people who don't have ScriptGUI. We'll be making use of this feature presently.
And the shareware registration fee on ScriptGUI is only $10.
Making the "Scriptlets"
After dutifully making my shell scripts and storing them in ~/bin, I realised I wouldn't be needing them. I simply copied the text from each script into ScriptGUI and then saved two Scriptlets: one for activating display sleep and one for turning it off. It couldn't be easier.
Now for the test run: click either of them and a status window comes up informing us that only root can run "pmset".
Getting around the root problem
We certainly don't want to store our clear-text passwords inside our scripts, or inside an AppleScript, so what will we do? Can we run something like Brian Hill's Pseudo to make Launch Documents that when double-clicked will fire up Pseudo and then get our little Scriptlets running as root?
The short answer is "no" (if you don't believe me, try it!) and the longer answer is that "we wouldn't want to do this anyway, because by the time we've chosen the Launch Document from the Apple Menu, watched Pseudo open, and then had our Scriptlets run (which in turn fired off their shell scripts!) it's starting to look like quite an ugly and convoluted chain.
The better solution here is to bypass Pseudo entirely and make use of Mac OS X's built-in sudoers facility to dispense with passwords entirely.
Why is that only root can run pmset? Probably because the settings made can affect all users on the machine. But if you're an administrator who can freely make those same settings through the GUI of the Energy Saver preference pane, then why shouldn't you be able to do it from the command line as well, and without a password at that?!
There are no good security reasons why we shouldn't be able to setup sudo to allow our administrator user to run pmset with root privileges.
So, in the Terminal, we start editing the "sudoers" file stored at /etc/sudoers. When you first look at it you'll see that it's almost empty:
# sudoers file.
#
# This file MUST be edited with the 'visudo' command as root.
#
# See the sudoers man page for the details on how to write a sudoers file.
#
# Host alias specification
# User alias specification
# Cmnd alias specification
# User privilege specification
root ALL=(ALL) ALL
%admin ALL=(ALL) ALL
|
Reading from left to right, these last two lines say: "root, from all hosts is allowed to execute as any user any command"; and "members of the admin group, from all hosts are allowed to run as any user any command".
As it says, we're best advised to use "visudo" to edi the file. If you don't know how to use "vi" and you don't feel like learning (it can be a steep learning curve), you'll need to make sure that your EDITOR environment variable is set before running the visudo command. In this way you can cause visudo to use a different editor. "pico" is often a good choice:
setenv EDITOR "/usr/bin/pico"
|
Now fire up visudo like so:
In the file we're going to add a line like this:
wincent santacruz = (root) NOPASSWD: /usr/bin/pmset
|
This means "user wincent on host santacruz (my machine) is allowed to execute as root, not using a password, the file /usr/bin/pmset". It's always a good idea to be as restrictive as possible when editing the sudoers file; give only the minimum privileges that you need to to permit the task. Note that we specify a full path, because otherwise a malicious user could compile a little app of their own called "pmset" and stick it in their path and execute it with root privileges, wreaking whatever havoc they would like on the system! In this case we elect the NOPASSWD option because we don't want to have to type in our password each time we run our scriptlets.
You can test this in the Terminal if you like. Before the edits, pmset won't let you make any changes; aafter the edits, you can do a "sudo pmset" and it will work just fine and not even ask you for a password.
You can also double click your scriptlets and they'll work as expected now also after making one small change to each of our source:
#!/bin/tcsh
/usr/bin/sudo /usr/bin/pmset -a dim 1
|
#!/bin/tcsh
/usr/bin/sudo /usr/bin/pmset -a dim 0
|
What pmset actually does is write to a file in "/var/db/SystemConfiguration". The actual Power Management itself is handled, I believe, by the login window.
You can try out your scriptlets and then verify that the changes are being written to the file:
cd /var/db/SystemConfiguration/
cat com.apple.PowerManagement.xml
|
Specifically, watch for changes in this key:
<key>Display Sleep Timer</key>
<integer>1</integer>
|
The finishing touch
The finishing touch is provided by another of my favourite, can't-live-without applications: FruitMenu. Now we just put our scriptlets in an out the way place, like ~/Documents/scriptlets, or similar, and add them to our Apple menu using the "File/Folder" option.
|
|
Display Sleep items added to Apple Menu
|
I chose to call them "Activate Display Sleep" and "Deactivate Display Sleep" put them lower down the menu near the standard Apple Sleep/Restart/Shutdown suite.
So after all that, the end result is a convenient way of putting the display to sleep, and of turning off the display sleep feature if you find it is coming on too soon while you are using the computer.
|
Comment List
There are no comments.
|
|
