![]() ![]() Note also that "this requires that user sessions correctly report the idle status to the system". Note that this is for a global system (so this is not ideal for a multi user environment). This will trigger a DBUS notification, that will have to be processed (for example by xsslock) to lock the session. In nf(5), you can configure the IdleAction to lock. This notification can then be processed, for example by xss-lock. Using loginctl lock-session, or the lock action in nf(5), you can notify the system through DBUS that you want to lock. Swayidle listens for idle activity from the Wayland compositor, as well as systemd events, and executes commands accordingly. One nice feature of xautolock is the corners. It might be necessary to add -detectsleep to prevent xautolock from locking the session after resuming. Note: xautolock has restrictive timer limits: # Dim the screen after three minutes of inactivity, lock the screen two minutes later using i3lock:Īn example dim-screen.sh script can be found in /usr/share/doc/xss-lock. Using DPMS signaling, you can set a second timer, for example to notify the user or to dim the screen. # Trigger screensaver after 10 minutes of inactivityĭPMS signaling can also be configured in /etc/X11// in the Monitor section. You can trigger a manual lock using loginctl lock-session. You can prevent xss-lock from being triggered by suspend and hibernate using -ignore-sleep. To execute an action on one of those events:īy default, xss-lock subscribes to suspend, hibernate, lock-session, and unlock-session with appropriate actions (run locker and wait for user to unlock or kill locker). The advantage of this is that you can control a lock issued manually, by inactivity, and by a suspend command at the same place. Xss-lock is triggered by one of two things: You might want to detect if you are in a graphical environment, otherwise your GUI terminals might start disappearing without you understanding why. Without a trap, it will just terminate the shell. You can combine it with a trap on the ALARM signal to execute the lock. To execute a command after terminal inactivity, you can use the TMOUT environment variable. So far this can only be done using systemd. from the event trigger, add the lock to the event chain.get the action trigger to execute your lock, then to execute the initial action.The last point (triggering a lock from an event) is the trickiest, because you can do it in one of two ways: systemd events (suspend, hibernate, etc.).inactivity (using systemd, xss-lock or xautolock).You can lock a session using different methods: You can lock the session with swaylock or waylock. Most desktop environments come with some way to lock the session. xscreensaver-command -lock in the xscreensaver package.xsecurelock, in the xsecurelock package.There are many ways to lock the session under Xorg, so this section is likely to be incomplete. You can use vlock or physlock to lock a virtual console. (Discuss in Talk:Session lock) Virtual console ![]() Notes: Same purpose, only split into categories. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |