x2x is a little program, released by DEC in the late 90's, that allows you to multiplex your input devices across two X11 servers. It's intended for users who have two computers, with two monitors, but who don't want to switch constantly between two keyboard/mouse pairs. It is basically the coolest little X hack I have ever seen.
Since it's all in software, you sidestep the annoying cross-platform and hardware compatibility issues that arise with KVM ("Keyboard-Video-Mouse") switches. For example, the Sun Blade 100 on my desk requires a Sun USB keyboard and USB mouse in order to boot up clean; the Linux PC under my desk requires a PS/2 keyboard and mouse. No KVM switch that I'm aware of can handle this combination gracefully, even with arbitrary numbers of dongles and adapters. If I use a KVM switch, either the Sun PC or the Linux PC will boot improperly.
With x2x, I just leave the native keyboards and mice plugged in, and launch x2x after I login to the two machines. From then on, I just use my PC keyboard (which is also much more ergonomic than the Sun keyboard) and mouse for both displays. To switch displays, I mouse off the left edge of my PC display, and the pointer appears on the Sun's display. It works amazingly well, and on our department's 100Mbps switched network there's no noticeable latency. Even on a much slower network, two machines that sit right next to each other would probably have negligible latency.
To build x2x, unpack the archive and run the following commands inside the unpacked directory:
xmkmf make
If you run the x2x executable resulting from the above
procedure, you'll get a description of command-line options. You
can also read the Unix man page x2x.1, which comes
with the distribution (use less or man).
But, basically, if you're on the machine with the input devices
that you want to use, just run
./x2x -to hostname:0.0 -east
changing hostname to the name of the host where
you want to share input devices. You must be logged into the X
display on this host, of course, and the local host from must be
in the remote host's list of machines allowed to set up X
connections (e.g., through xhost).
Note that, when run "raw", x2x is completely insecure: anyone with a packet sniffer on your network can see everything you type or mouse on the remote machine. See below for instructions on tunneling x2x over ssh.
In order to keep your x2x session private, you should tunnel the X11 connection over SSH. I guess if you're a real masochist, you can dive into the x2x source (it's about 2KLOC of really ugly pre-ANSI C) and hack it in, but through the magic of shell scripts and ssh tunneling, we can do almost as well using scripts.
UPDATE 17 May 2004: Cameron Blackwood writes in to note that there's a much simpler way to tunnel x2x over ssh than what I outline below:
>From the host with the keyboard & mouse ssh -X client_to_send_mouse_to /usr/X11R6/bin/x2x -east -to :0. &
The bad, old, stupid way is documented below for posterity.
Disclaimers:
That said, anybody who's already able to sniff your LAN for a while has probably broken something on your network already. So, let's proceed. The instructions below assume the following:
sshd runs on both hosts.To generate a fresh ssh identity keypair, and make it an acceptable identity key, type the following commands at the console:
cd ~/.ssh ssh-keygen -b 1024 -t dsa
At this point, ssh-keygen will try to generate a key pair.
This may take a while, because it's trying to gather randomness
from your system. Bash on your keys and move your mouse around to
gather entropy for /dev/random. After a minute or so, it should
finish generating a key pair, and ask you for a filename and a
password. Use an empty password and choose a name for your
keyfile; I suggest x2xid, because this is what I use
for the rest of these directions.
Next, do the following:
cat ~/.ssh/x2xid.pub >> ~/.ssh/authorized_keys2 chmod 600 ~/.ssh/authorized_keys2
Warning: These two steps enable anyone in
possession of your freshly generated private keyfile
x2xid to login as you without a password. Therefore,
you should be very careful with this private keyfile. This
shouldn't be much of a problem, since anyone who has access to
your ~/.ssh directory has probably broken into your account
already. However, you should be aware of the risks. Properly
paranoid people never use password-less identity files. However,
there's no easy way to make secure x2x convenient if you have to
type in a password every time.
Place this file: x2xconfig in your ~/.ssh directory.
Aside, for those who know how ssh works: the reason I'm using a separate config file from ~/.ssh/config is that my default config sets my ssh connections to use compression, which trades off worse latency for better throughput. For the forwarded X connection, we'd rather make the opposite tradeoff. Also, the reason I set blowfish-cbc to the default cipher is that blowfish is known to be extremely fast (much faster than 3des, for example) on average microprocessors.
Place this file: rex2x (short for "rerun x2x"; rename it if this name annoys you) somewhere in your executable path (PATH environment variable). Edit the HOST_FROM and HOST_TO variables in this file appropriately.
Note: With this script, the HOST_TO machine's X server doesn't need to listen on the network at all, because it all gets tunneled through ssh.
Having edited rex2x, you should be able to run it normally in the background:
rex2x &
You may want to edit the X2X_CMD value in the rex2x script---for example, you may want to enable -resurface, or use -east instead of -west.
I have setup a shortcut to rex2x on my KDE desktop panel, so it's easy for me to start or restart x2x if needed.
-resurface option, but this can cause bad
interactions with some other programs (e.g., the KDE screen
saver). I'd rather just restart x2x as needed.