From ad02e15542abd55dd8bed89f4e267d5fd7f595b8 Mon Sep 17 00:00:00 2001
From: runge <runge>
Date: Sat, 9 Jul 2005 03:52:20 +0000
Subject:  x11vnc: -grab_buster for XGrabServer deadlock; fix scrolls and
 copyrect for -clip and -id

---
 x11vnc/x11vnc.1 | 19 ++++++++++++++++++-
 1 file changed, 18 insertions(+), 1 deletion(-)

(limited to 'x11vnc/x11vnc.1')

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
-- 
cgit v1.2.3