After reviewing several solutions to a security problem regarding screen lockers, I’ve found that the easiest workaround for switching virtual terminals and killing the screen locker application is to start one’s X session with the following command:
exec startx
That way, even if someone switches to the virtual terminal that was used to start X and presses CTRL+C, he or she will only be presented with a login prompt (instead of having full reign of the user account responsible for starting the session). Now that there’s a reasonable workaround for that problem, I set out to make keybindings and menu shortcuts for Openbox that would take care of both locking the screen, and putting my displays to sleep. Conceptually, this was a straightforward task, and I accomplished it with the following:
Openbox menu item:
<item label="Lock screen + off">
<action name="execute"><execute>/usr/bin/slock</execute></action>
<action name="execute"><command>/usr/bin/xset dpms force off</command></action>
</item>
Keybinding:
<keybind key="XF86Sleep">
<action name="execute">
<execute>/usr/bin/slock</execute>
</action>
<action name="execute">
<command>/usr/bin/xset dpms force off</command>
</action>
</keybind>
The only problem is that it doesn’t work every time. Though it tends to work nicely, there are times where slock will start, but the displays will not honour the xset command to go to sleep (I guess that when it comes to bedtime, monitors are a bit finicky like children :razz:). I have tried adding a sleep time before the commands, thinking that there was some HID activity causing the wake, but that didn’t rectify the problem. If anyone has a proposed solution to the seemingly random failure of xset putting the displays to sleep, please let me know by leaving a comment.
Cheers,
Zach
5 comments
Skip to comment form
FWIW, there must be something specific to your setup that’s stopping the screen power-down, or more likely, immediately waking it back up, because I have something similar (tho without the lock, I just wanted a way to put the display to sleep) working here (on kde).
My solution is a simple two-line script with the following:
sleep 1
xset dpms force off
The sleep 1 was important, because I found that otherwise, the response was fast enough that the display would blink out when I still had my hotkey down, and the keyup event would wake it back up.
You mentioned trying sleep too, tho, so I’m not sure what the issue is… unless perhaps the executes are happening in parallel instead of serially (I don’t know openbox to say), in which case a solution that serializes the sleep and xset dpms (the two-line script being my choice) should work.
Otherwise, I’d look at what else might be waking it back up, since the sleep 1 was enought to avoid the keyup event here, and it has worked reliably for me for several years now.
(Meanwhile, thanks for coming back to the locker thing, reminding me to go back and look thru the comments to see what happened there. exec startx and backgrounded startx with a disown and exit are similar enough solutions to the issue that I’m happy others came up with it too, and that you found it to work for you too. =:^)
Author
Thanks for your thoughts for a solution to the problem. I think that sleeping in between the
slockandxsetcommands may have taken care of it.Cheers,
Zach
That’s raelly thinking of the highest order
Try doing slock first and then a sleep of 1s and then dpms off.
Author
Thanks for the recommendation. I have made the change, and so far, it has worked as intended! I will keep an eye on it over the next few days, but I think the sleep in between the two may have done it.
Thanks again!
Cheers,
Zach