summaryrefslogtreecommitdiffstats
path: root/x11vnc/x11vnc.1
diff options
context:
space:
mode:
Diffstat (limited to 'x11vnc/x11vnc.1')
-rw-r--r--x11vnc/x11vnc.119
1 files changed, 18 insertions, 1 deletions
diff --git a/x11vnc/x11vnc.1 b/x11vnc/x11vnc.1
index ee330b1..9f2242c 100644
--- a/x11vnc/x11vnc.1
+++ b/x11vnc/x11vnc.1
@@ -2,7 +2,7 @@
.TH X11VNC "1" "July 2005" "x11vnc " "User Commands"
.SH NAME
x11vnc - allow VNC connections to real X11 displays
- version: 0.7.2, lastmod: 2005-07-06
+ version: 0.7.2, lastmod: 2005-07-09
.SH SYNOPSIS
.B x11vnc
[OPTION]...
@@ -1378,6 +1378,23 @@ Disable any use of the RECORD extension. This is
currently used by the \fB-scrollcopyrect\fR scheme and to
monitor X server grabs.
.PP
+\fB-grab_buster,\fR \fB-nograb_buster\fR
+.IP
+Some of the use of the RECORD extension can leave a
+tiny window for XGrabServer deadlock. This is only if
+the whole-server grabbing application expects mouse
+or keyboard input before releasing the grab. It is
+usually a window manager that does this. x11vnc takes
+care to avoid the the problem, but if caught x11vnc
+will freeze. Without \fB-grab_buster,\fR the only solution
+is to go the physical display and give it some input
+to satisfy the grabbing app. Or manually kill and
+restart the window manager. With \fB-grab_buster,\fR x11vnc
+will fork a helper thread and if x11vnc appears to be
+stuck in a grab after a period of time (20-30 sec)
+then it will inject some user input: button clicks,
+Escape, mouse motion, etc to try to break the grab.
+.PP
\fB-debug_grabs\fR
.IP
Turn on debugging info printout with respect to