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