ndsd - network dual-head software daemon
ndsd [ -bg ] [ -master <master-machine-name:0.0> ] [ -slave <slave-
machine-name:0.0> ] [ -slaveright ] [ -masterleft ] [ -usekeysym ]
[ -wait ]
The Networked Dual-head Software Daemon, ndsd, enables a machine with
ndsd software, the "slave" machine, to accept keyboard and mouse input
from another machine on the network (the "master" machine). Conversely,
a "master" machine with ndsd software can also be used to control
applications on a remote "slave" machine.
Various configuration options can be specified by command line options or
in the ndsd configuration file /usr/nds/dh_config. Commands in the
configuration file will override any command line options.
The ndsd command has the following options:
-bg Tells ndsd to fork itself and run in the background. ndsd will
not fork until it has successfully connected to the slave
display, so scripts can use this option in situations that
require ndsd to be running before continuing (such as login
Tells ndsd which machine on the network it should accept mouse
and keyboard commands from. If no "master" machine is specified,
the value of the DISPLAY environment variable is used.
The same effect as -slaveright. By default, the "slave" machine
screen is assumed to be to the left of the "master" machine
screen. If this option is set, dragging the mouse off of the
left-had side of the "master" machine monitor will cause the
cursor to apperar on the right-most edge of the "slave" machine
Tells ndsd which machine on the network should passively accept
mouse and keyboard control from the "master". The specified
screen and display must support the "XTEST" X server extension.
If no "slave" machine is specified, ":0.0" (the first local
display) is used. If a null string is specified for the slave
display, the value of the DISPLAY environment variable is used.
Indicates that the monitors of the two machines are positioned
such that the "slave" machine monitor, the machine running the
ndsd, is to right of the "master" machine monitor. Dragging the
mouse off of the right-hand side of the "master" machine monitor
will cause the cursor to appear on the left-most edge of the
"slave" machine screen.
If this option is specified, keycodes from the master machine
will be translated by the X server prior to being fed to the
slave machine server. This option is necessary when the two
machines have different keycodes. Indigo2, Indy, O2, OCTANE and
Oynx2 machines use PC compatible keyboards, different from
previous SGI machines which used a SGI proprietary keyboard.
This option should be used if an machine with a PC keyboard is to
a machine with an SGI keyboard. This option may also allow the
master machine to be a non-SGI machine. There is a slight
performance hit for using this option, so use it only if you need
-wait This option causes the nds daemon to wait until a window exists
on the slave display before creating any windows or processing
input. It may be needed when nds is started from the
/usr/lib/X11/xdm/Xlogin file (see below) and used with the
standard xdm(1) login window. It is not needed for the clogin(1)
login window, which is the default on SGI systems. The xdm
window may be used if clogin is not installed or if the chkconfig
option visuallogin is off.
-debug The debug option will run the nds daemon in the foreground and
print out diagnostic info, helpful if problems arise.
All options may be placed in the file /usr/nds/dh_config, each item on a
separate line. The header in this file shows the format of the file.
ndsd is installed disabled by default. To enable it, provide a display
specification for the "master" machine in the /usr/nds/dh_config file and
issue the command:
chkconfig nds on
Perform these operations on the "slave" machine. You should not enable
ndsd on the "master" machine.
If a user wishes simply to have one keyboard on a desk to control two
systems, this can be accomplished by adding the following line to the
/usr/lib/X11/xdm/Xlogin file on the "slave" machine:
/etc/init.d/nds start silent
This will start ndsd whenever the server puts up the login screen,
allowing remote cursor and keyboard control upon successful login to the
"master" machine. This command can be issued at any time to start up
ndsd as a background daemon process. It uses the "-bg" option to ensure
that ndsd is up and connected to the slave display when it returns.
If you run into problems, issue the command:
This will cause ndsd to be run in the foreground and issue diagnostic
messages as to what it is doing.
To disable nds, issue the command:
chkconfig nds off
to prevent the nds daemon from starting up again. To stop the currently
running nds daemon, at the unix prompt type:
and it will not restart until the chkconfig flag is reset to on.
If the user wishes to have the machine more closely resemble a hardware
dual-head machine, running the slave_install script will configure the
machine to do so:
This will set up the machine so that none of the usual window
decorations, such as the 4Dwm tollbox, appear. To undo these changes,
de-install the slave software by:
This will restore the machine to its default behavior. Once you run the
slave_install script, you won't be able to use the normal window manager
functions, so don't run it unless you are sure you want to do so.
The ndsd daemon allows for mouse and keyboard interaction between the two
displays, but provides no additional X server functionality. Application
software that wishes to take advantage of a second display should take
into account that each machine is running it's own X server and allocate
Mouse and keyboard information is transferred between the ndsd daemon and
the "master" machine over the network connecting the two machines.
Unusally heavy network traffic can affect performance. A dedicated
network between the two machines will give maximum performance, though
most networks have sufficient bandwidth for good performance. The
"slave" and "master" machine should be on the same subnet, connections
through gateways between subnets can negatively impact performance,
though ndsd will work as long as the "slave" and "master" machines can
Applications that use XWarpPointer(3X11) to move the cursor between the
two displays may not function correctly. The ndsd maintains cursor
positions internally, XWarpPointer() calls will not update any ndsd state
information. Good X programming leaves pointer movement up to the user,
so applications should not generally call XWarpPointer().
The ndsd daemon controls cursor movement between the two displays by
monitoring the pixels at the edge of the two screens. Applications which
need single pixel accuracy at the edge of the screen may have problems
when running ndsd as ndsd may jump the cursor to the other display when
the user does not wish this to happen.
/usr/nds/dh_config the ndsd configuration file
chkconfig(1M), X(1), Xsgi(1), XWarpPointer(3X11), xdm(1), clogin(1)
PPPPaaaaggggeeee 4444 [ Back ]