xtrlock.1x - Man Page

Lock X display until password supplied, leaving windows visible

Synopsis

xtrlock [-b] [-f]

Description

xtrlock locks the X server till the user enters their password at the keyboard.

While xtrlock is running, the mouse and keyboard are grabbed and the mouse cursor becomes a padlock.  Output displayed by X programs, and windows put up by new X clients, continue to be visible, and any new output is displayed normally.

The mouse and keyboard are returned when the user types their password, followed by Enter or Newline.  If an incorrect password is entered the bell is sounded.  Pressing Backspace or Delete erases one character of a password partially typed; pressing Escape or Clear clears anything that has been entered.

If too many attempts are made in too short a time further keystrokes generate bells and are otherwise ignored until a timeout has expired.

The X server screen saver continues to operate normally; if it comes into operation the display may be restored by the usual means of touching a key (Shift, for example) or the mouse.

Warning

Due to limitations in the X11 protocol, the xtrlock cannot intercept all keyboard and mouse events if run under a Wayland-based desktop environment. In this situation, applications that use the "legacy" X11 protocol will be locked whilst ones supporting Wayland can still be interacted with, even when xtrlock is in operation. Some keyboard shortcuts may also continue to function whilst the display is locked.

A warning is printed if such an environment is detected. For an alternative solution, please see swaylock(1) or similar.

Options

-b

blank the screen as well as displaying the padlock

-f

fork after locking is complete, and return success from the parent process

X Resources, Configuration

None.

Bugs

Additional input devices other than the keyboard and mouse are not disabled.

The timeouts, bitmaps and mouse cursor colour cannot be modified.

See Also

X(1), Xlib Documentation.

Author

Ian Jackson <ian@chiark.greenend.org.uk>