You are not logged in.
Pages: 1
My laptop used to lock when the lid was closed, but ever since I removed gnome-screensaver (I've been xscreensaver as of late) it no longer locks.
In my /etc/acpi/handler.sh I have:
button/lid)
#echo "LID switched!">/dev/tty5
xscreensaver-command -lock
;;
. If I add a "touch /some/file" above the xscreensaver command, the touch comand gets executed, so I know that the handler.sh script is being run. If I execute xscreensaver-command -lock then my laptop does indeed lock. xscreensaver is already running as a daemon and works fine, and when the screensaver kicks in it locks like it's supposed to.
Where could the problem lie?
Last edited by B-Con (2008-02-24 00:55:54)
Offline
Might be that it cannot find the display.
Anyway, you can try 'xscreensaver-command -lock &> /tmp/logfile', that should capture eventual error thrown by xscreensaver.
EDIT: now that I think about it, it might not be connecting to your xscreensaver daemon, since that script is run by root (or even some other user). So you could try something like 'su <yourusername> -c <that xscreensaver command>'.
Last edited by bender02 (2008-02-24 02:23:24)
Offline
Very nice, you were correct on both thoughts.
Error output:
xscreensaver-command: warning: $DISPLAY is not set: defaulting to ":0.0".
No protocol specified
xscreensaver-command: can't open display :0.0
b-con@beacon-laptop:~/Desktop$ who
b-con vc/7 Feb 23 13:53 (:0)
My .xinitrc is what starts the xscreensaver daemon. I tried running the xscreensaver lock command as my normal user via su and it runs properly. However, I get a
LOCK client message received while already locked.
error in yellow text at the top of my screen now when I close my lid. I guess it's trying to execute twice for some reason? Maybe some other handler is trying to execute the lock?
Offline
Long shot: doesn't also opening the lid generate a button/lid event? (check /var/log/acpid.log)
EDIT: yep, I just tried myself, opening also generates button/lid event. But the numbers are different, so just add another condition to handler.sh.
Last edited by bender02 (2008-02-24 05:25:23)
Offline
Tried it myself, yep, they both generate the event.
I generated a few events and noted that the second and third parameters, LID and 00000080 respectively, but the fourth parameter is a counter, incrementing once on each event (increment on close, increment again on open). grep'ing the logs seems to show that only the button/LID event increments the count. I guess the (really) dirty thing to do would be to only execute the xscreensaver -lock on odd events, after converting the parameter to decimal from hex.
Offline
You could also do something like:
(replacing LID so that it is the correct path, in my case LID had to be replaced with C1AB)
if [ `grep closed /proc/acpi/button/lid/LID/state | wc -l` -ne 0 ]
then
su <yourusername> -c <that xscreensaver command>'
fi
Which is much more elegant Well actually a well scripted odd/even detection would be rather elegant indeed, but maybe a bit prone to bugging.
Last edited by bavardage (2008-02-24 10:17:05)
blog - github - facebook - google profile
Offline
Hi,
you can disable this xscreensaver messages in the xscreensaver config file (~/.xscreensaver).
captureStderr: False
overlayStderr: False
This works for me.
Last edited by New Face In Hell (2008-04-18 12:19:13)
Offline
Cool, thanks, that fixes it for me.
Last edited by B-Con (2008-04-21 20:02:22)
Offline
Pages: 1