Provided by: dxpc_3.9.2-3_amd64 bug


       dxpc - Differential X Protocol Compressor




       dxpc [common] [client | server] [connect]

       [common] options are:
            -p port_num -f -k -v -s debug_level -l log_file

       [client] options (valid for CLIENT process) are:
            -i compression_lvl -d display_num -u

       [server] options (valid for SERVER process) are:
            -D display -b(a|w)

       [connect] options are:
            hostname -w


       dxpc  is  an  X  protocol compressor designed to improve the speed of X11 applications run
       over low-bandwidth links (such as dialup PPP connections).

       dxpc must be run at both ends of a low-bandwidth link.  On  the  host  where  the  real  X
       server  is,  dxpc  runs in "Server Proxy" mode.  On the host at the other end of the link,
       dxpc runs in "Client Proxy" mode.  The Client Proxy dxpc must be started first.  When  the
       Server  Proxy  dxpc  is  started, it connects to the Client Proxy.  (Note that versions of
       dxpc before 3.3.1 used the opposite convention.)  If either of the two communicating  dxpc
       instances is subsequently terminated, the other one automatically shuts down.

       The  Client  Proxy  mimics an X server.  X client applications connect to the Client Proxy
       using display "unix:8"  (or  "<hostname>:8";  dxpc  supports  both  UNIX  domain  and  TCP
       sockets).  The Client Proxy receives X requests from the application, compresses them, and
       sends them to the Server Proxy.  The Server Proxy uncompresses the requests and sends them
       to  the real X server.  Similarly, the Server Proxy receives X events, replies, and errors
       from the real X server.  It compresses these messages and sends them to the Client  Proxy,
       which uncompresses them and sends them to the client application.

       The  compression  performance  of dxpc depends upon the types of X applications being run.
       For many applications, dxpc achieves between 3:1 and 6:1 compression  of  the  X  protocol


       dxpc  has two modes; the connection mode, which is either listening or connecting; and the
       X mode, which is either client or server.

       The listening process waits for a  connecting  process  to  initiate  the  TCP  connection
       between  the  two  processes.  The  listening  process  must  always be started first. The
       connecting process initiates the connection to the listening process. dxpc will run as the
       connecting  process  if  a  hostname  argument  is  supplied (see connect options, above).
       Otherwise it will run as the listening process.

       The server process is typically located on the same machine as the real X server,  and  is
       responsible  for  displaying  the  output of applications. The client process is typically
       located on the same machine as the X applications, and is responsible for  forwarding  the
       output  of  those  applications to the server process. By default, dxpc runs as the client
       process if it is the listening process (due to the lack of a hostname  argument)  and  the
       server process if it is the connecting process, but the -w switch reverses this.

       For  example,  the  command  dxpc  starts  dxpc as the connecting process
       (because a host name is supplied) and the server process (because  it  is  the  connecting
       process  and -w is not supplied). The command dxpc -w starts dxpc as the listening process
       (because no hostname is supplied) and the server process  (because  it  is  the  listening
       process, and -w reverses the usual logic).


       -b(a|w)     This  option  specifies  that  any  windows created should be created with the
                   BackingStore  option  set  to  Always  (-ba)  or  WhenMapped  (-bw),  if   the
                   application has not set the option itself.  Using the BackingStore option will
                   reduce traffic to repaint exposed regions of the window, at the cost of  extra
                   memory  use  in  the X server itself.  (This option is ignored in Client Proxy

                   NOTE: The -ba option can cause Expose events to be sent before the client  has
                   mapped  its windows.  This can confuse some client programs, notably GNU Emacs
                   version 20.3.  The "bug" in this  case  is  that  dxpc  shouldn't  be  setting
                   BackingStore  to  Always behind the application's back.  Neverless, the option
                   is available, if you want to try it; many client programs still function  fine
                   with it, and it will cause the contents of iconified windows to be retained.

       -d displaynum
                   This  option  specifies  the  number of the X display that dxpc imitates.  The
                   default value is 8.  (This option is ignored in Server Proxy mode.)

       -f          This option tells dxpc to fork and run as a daemon  process.   All  subsequent
                   non-error  output is suppressed, including statistics reports.  The daemon can
                   be killed by use of the -k option.

       -k          This option tells dxpc to read a pid from the  lockfile  in  the  user's  home
                   directory  and  then  send  a  SIGKILL to the old process.  It does some error
                   checking to try to ensure that the file contains a valid pid file (and nothing
                   else).  The pidfile will exist only if dxpc was started with the -f option.

       -l          This  option  is  used  to  tell  dxpc  to  write messages and statistics to a
                   logfile.  Very useful with the -f option.

       -p portnumber
                   This option specifies the TCP port number to be used for communication between
                   the Client Proxy and the Server Proxy.  The default value is 4000.

       -s(1|2)     Print a report on dxpc's compression performance for an X application when the
                   application exits.  In Client Proxy  mode,  dxpc  displays  a  report  on  the
                   compression of messages generated by the X client.  In Server Proxy mode, dxpc
                   displays a report on the compression of messages generated by  the  X  server.
                   The  -s1  option  yields a simple report that provides the overall compression
                   ratio.  The -s2 option yields a far more detailed report  on  the  compression
                   ratios  achieved  for all the individual message types in the X protocol.  The
                   -s2 option is the "hacker option"; most people  will  probably  want  the  -s1
                   report instead.

       -u -t       Normally,  dxpc  in Client Proxy mode imitates an X display, :8 by default, by
                   listening on both a UNIX domain socket and a TCP socket.  The -u option  tells
                   it  not to use the UNIX domain port, and the -t option tells it not to use the
                   TCP port.  (These options are ignored in Server Proxy mode.)

       -v          This option tells dxpc to print out its version number and  copyright  message
                   and exit.

       -w          Use  of  this  option swaps the connection sequence.  That is, the client will
                   initiate the connection to the server.  Thus, instead of starting  the  client
                   like dxpc -f and the server as dxpc -f workserver, you can start the client as
                   dxpc -w -f homepc and the server as dxpc -w -f.  This option is intended to be
                   useful for people running the client proxy on a machine behind a firewall.

       hostname    This  argument  must be used in Server Proxy mode to tell dxpc the hostname or
                   IP address of the machine where other dxpc (the one in Client Proxy  mode)  is
                   running.  (Note that the presence of this argument is what puts dxpc in Server
                   Proxy mode.  If this argument is not used, dxpc runs in Client Proxy mode.)

       -D display  Specify X host on which to display proxied applications. Defaults to value  of
                   the DISPLAY environment variable.

                   This  option  controls  bitmap image compression. This option is only valid on
                   the instance which is accepting connections; usually this is the  client,  but
                   the  -w  option  will  reverse  this,  making  the -i option valid only on the
                   server. The specified number is the image  compression  level;  higher  levels
                   offer  better  compression  at  the cost of greater CPU and memory utilization
                   (mostly on the client proxy). The actual  behavior  of  each  level  is  given

                   0  : No compression (except for the very limited compression supported in dxpc
                   3.7.0). In other words, behaves like 3.7.0 (but is incompatible with it)

                   1 : LZO lzo1x_1 compression; very fast, low CPU  and  memory  use,  reasonable

                   2-9:  LZO  lzo1c_... variant compression algorithms. lzo1c_2 actually seems to
                   be worse than lzo1x_1...

                   99: LZO lzo1c_99 algorithm. Slow, but pretty good compression. NB: I have seen
                   a couple of unexplained crashes when using this level. Not recommended.

                   999: LZO lzo1x_999 compression. Slow (but fast enough to feed a 128K ISDN link
                   when hosted on a Pentium II/300 without maxing out the  processor),  but  good
                   compression. This is the default and recommended value.


       Assume  that  you're  running a real X server on the console of a local workstation called
       homepc, and that you want to run some X applications on a remote system called  workserver
       and have them display on the console of the local system.

       On workserver, run
            $ export DISPLAY=homepc:0
           $ dxpc -f
           $ export DISPLAY=unix:8

       On homepc, run
           $ export DISPLAY=unix:0
           $ dxpc -f workserver

       Now on workserver,
           $ xterm&
           $ xemacs&


       If  you  use X authorization, with a .Xauthority file on the workstation where your real X
       server runs, you'll need to set up a .Xauthority file on the host  where  the  ClientProxy
       runs.  One way to do this is:

       Copy  your ~/.Xauthority file from the host where the real X server runs to the host where
       the Client Proxy runs.

           xauth list
       to see the authorization keys.  There should be one for your real X display.  It will look
       something like this:
           <hostname>/unix:0   MIT-MAGIC-COOKIE-1   <hex string>
       On  the  host  where  the Client Proxy is located, add a new entry to the .Xauthority file
       with the display name of the fake  X  server  (the  DISPLAY  where  the  Client  Proxy  is
       listening)  and  all of the other values from the entry for the real X display.  The xauth
       "add" command can be used, like this:
           xauth add <hostname>/unix:8 MIT-MAGIC-COOKIE-1  <hex string>
       where <hostname> is the name of the host where  the  Client  Proxy  is  running  and  <hex
       string>  has the same value as the <hex string> obtained for the real X display in step 2.
       Once you do this, you should be able to run X clients through dxpc successfully.


       Some windows don't appear.  This can happen if the  -ba  option  is  used,  and  a  client
       program  (such  as GNU Emacs version 20.3) does not request backing store and thus assumes
       that Expose events imply that the window has been mapped.  Use -bw, or leave  out  the  -b
       option altogether.

       No windows appear.  This can happen if you are using a newer version of dxpc with an older
       one, from before  the  client  and  server  roles  were  changed.   A  connection  can  be
       established between them, but both sides believe themselves to be the client side, or both
       sides believe themselves to be the server side.  Make sure you're using the  same  version
       of dxpc at both ends of the connection.


       Brian Pane


       Kevin Vigor (


       dxpc    has    adopted    many    good    ideas    from   the   HBX   and   FHBX   systems

       Thanks to all of the users of dxpc who have contributed feedback and suggestions.


       xauth(1), README file from dxpc distribution