This is like either −activate or −cycle, depending on which is more appropriate, except that the graphics hack that will be run is the next one in the list, instead of a randomly-chosen one. If the screensaver is active (the screen is blanked), then stop the current graphics demo and run a new one (chosen randomly.) If the screen is not blanked, then this simulated user activity will re-start the countdown (so, issuing the −deactivate command periodically is one way to prevent the screen from blanking.) If the screen is locked, then the password dialog will pop up first, as usual. This means that if the screensaver is active (the screen is blanked), then this command will cause the screen to un-blank as if there had been keyboard or mouse activity.
This tells xscreensaver to pretend that there has just been user activity. (Because if you jiggle the mouse, xscreensaver will notice, and deactivate.) To be sure that you have time to take your hand off the mouse before the screensaver comes on. It is useful to run this from a menu you may wish to run it as Tell xscreensaver to turn on immediately (that is, blank the screen, as if the user had been idle for long enough.) The screensaver will deactivate as soon as there is any user activity, as usual.
Like the no-argument form of −demo, but brings up that program’s Preferences panel by default. (The first hack in the list is numbered 1, not 0.) When the −demo option is followed by an integer, it instructs the xscreensaver daemon to run that hack, and wait for the user to click the mouse before deactivating (i.e., mouse motion does not deactivate.) This is the mechanism by which xscreensaver−demo(1) communicates with the xscreensaver(1) daemon. This just launches the xscreensaver−demo(1) program, in which one can experiment with the various graphics hacks available, and edit parameters. Prints a brief summary of command-line options. Xscreensaver-command accepts the following command-line options: This program, xscreensaver-command, is a command-line-oriented tool the xscreensaver−demo(1). Xscreensaver(1) has a client-server model: the xscreensaver process is a daemon that runs in the background it is controlled by other foreground programs such as xscreensaver-command and xscreensaver−demo(1). The xscreensaver−command program controls a running xscreensaver process by sending it client-messages.
So how can I force XScreenSaver to lock immediately, ignoring xscreensaver.Xscreensaver-command - control a running xscreensaver process SYNOPSIS This is brittle since I need to keep the settings in sync, and makes suspend take longer. Since I've set xscreensaver.lockTimeout I have to make sure to sleep longer than the setting to avoid showing the screen contents on resume. Since this process is interrupted (by sleeping) on resume the screen shows up slightly greyed (as it would be after a second of fade-out) and stays like that seemingly until the 10 seconds are up (fading seems to stop working), at which point the password dialogue shows up. Unfortunately it's not this simple with XScreenSaver - it will take until xscreensaver.lockTimeout to fully blank the screen. Adding a small delay via ExecStartPost=/usr/bin/sleep 1 helps prevent this. The article states:Īs screen lockers may return before the screen is "locked", the screen may flash on resuming from suspend. Related to xscreensaver doesn't stop fadeout correctly, I've set up a service which runs /usr/bin/xscreensaver-command -lock to lock the screen when closing the laptop lid.
0 kommentar(er)
