X Windows to X Windows
- works between 2 computers
- free and open source
x2x allows the keyboard and mouse on one ("from") X display to be used to control another ("to") X display. Since x2x uses the XTEST extension, the "to" X display must support XTEST.
If x2x is built under Cygwin (on Windows XP or Windows 2000) then the -fromwin option may be specified to allow the "from" display to be the Windows desktop. (The Cygwin build also supports use of an X display for the "from" screen). Use of -fromwin sets the default behaviour as if the -big -west -capslockhack options had also been given.
In the default interface, x2x puts a window on the "from" display. This window is labeled with the name of the "to" display. Keystrokes typed into this window go to the window on the "to" display that has the input focus. Clicking on the x2x window causes the mouse on the "from" display to control the cursor on the "to" display. Performing a subsequent multiple button click on the "to" display returns control to the "from" display.
If the -fromwin, -north, -south, -east or -west options are specified on the command line, x2x starts up with a different interface. When the mouse moves to the top, bottom, east side or west side of the default screen on the "from" display, the cursor slides over to the "to" display. When the mouse returns to to side of the "to" display that it entered, it slides back onto the "from" display.
Unless the -nosel option is specified, x2x relays X selections from one display to the other. (If -fromwin is specified then the X selection is relayed to and from the Windows clipboard as text strings).
Here are a few hints for eXcursion users (based on Intel version 2.1.309). First, use the -big option. Second, in the control panel, under mouse, check the box that enables "Automatically Capture Text on Button Up." X selections will then automatically move into the Windows clipboard. As is the case with all X applications running on 2.1.309 (including x2x), you will need to do an extra mouse click after performing the X selection for this operation to work. x2x is known to work poorly with eXcursion running on Windows 95, probably due to the Windows 95 task scheduler. x2x does work well with eXcursion running on Windows NT.
The hints for eXcursion are also valid for Exceed, with the exception that X selections work better, as long as you are using x2x version 1.25 or later.
Command 'x2x' can be installed with:
sudo apt install x2x
You only need to install x2x on the slave machine, the one whose keyboard and mouse you are NOT using.
On the SLAVE computer you will want to enable X11Forwarding
sudo vi /etc/ssh/sshd_config
# ForwardX11 no
This is remarked out so X11 forwarding is already enabled
X11Forwarding yes
SSH to the SLAVE computer from your MASTER computer and run x2x:
ssh -X 192.168.x.x 'x2x -east -to :0'
Where -X option tells ssh to enable X forwarding. The EAST indicates which side of your screen will pass the mouse to the second display. Now you should be able to move your mouse between the two X sessions by moving your mouse off the screen to the right (east).
Instead of using -east or any screen pass parameter you can use the box window method. The -geometry argument is only to be used if you don't use north, south, east or west. It pops up a X window which, when you click in it, will activate the mouse and keyboard on the "to" desktop. To leave that desktop, you have to press two mouse buttons whilst over the x2x X window on the "from" desktop. (The mouse still moves over your home "from" desktop whilst in the remote "to" desktop.)
In this example we still use a separate mouse on the slave computer and we share a keyboard. A window appears we can click to control the slave computer.
ssh -X 192.168.x.x 'x2x -geometry 320x200 -nomouse -to :0'
Disable annoying "The authenticity of host can't be established" error messages: In this example we can move the mouse off the screen to the right onto the next computer, and when we launch this we are not hassled about adding an ECDSA key for the host. If it is your private LAN and your two hosts, the extra security is likely not necessary.
ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -X 192.168.x.x 'x2x -east -to :0'
As you already know, your ssh hosts file is typically at /home/username/.ssh/known_hosts and thus we can choose a null file to avoid "REMOTE HOST IDENTIFICATION HAS CHANGED" messages.
