x2x allows the console (keyboard and mouse) on one X terminal to be used to control another X terminal. It also provides ancillary functions like clipboard sharing.
David Pendell has been working with computers for the last 23 years in a variety of capacities, including for programming and audio and video processing. He has been using Linux since Red Hat 5.1 and has used a variety of distros.
The software was developed in 1996 by David Chaiken at DEC. It is currently maintained by Mikhail Gusarov.
x2x joins a pair of X displays together, as if they were a single multiheaded display. The pointer can be warped between displays, or, depending on how you start x2x, can slide from one display to the other when it runs off the edge of the screen. Keyboard focus also moves between displays in the way you'd expect, and the X selection propagates around. At least one of the displays involved (specifically, the one being controlled remotely) must support the XTEST extension. (The servers shipped by Debian support this.)
x2x is useful when you have two displays on the same desk, as you can use a single keyboard and mouse to control both. If you want to propagate your selections between displays which are not sharing a desk, you might be more interested in the package propsel. Propsel does not link the displays' keyboard and mouse, which would be confusing in some cases, and can propagate between up to 8 displays, whereas x2x can handle only two at a time.
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 exten-
sion, the "to" X display must support XTEST.
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 -east or -west options are specified on the command line, x2x
starts up with a different interface. When the mouse moves to the
(east 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.
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 per-
forming 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.
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 exten-
sion, the "to" X display must support XTEST.
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 -east or -west options are specified on the command line, x2x
starts up with a different interface. When the mouse moves to the
(east 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.
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 per-
forming 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.
x2x is a software alternative to a KVM switch.
Unless you have fully embraced the virtualization movement, you probably have more than one machine in your home or office, particularly if you run more than one operating system, and you probably have more than one keyboard and mouse on your desk. If you would like to regain some desk space without having to purchase a KVM switch, x2x may be the solution. Simply put, x2x takes advantage of the X Window System's ability to run a display over a TCP/IP network. In this case, you are not running a display as much as you are taking charge of another display's mouse and keyboard.
You can run x2x over SSH, which is easy and secure, or connect x2x directly to the remote X server. The second method is a bit more difficult because it requires some reconfiguring of your X system, but it gives you the ability to cut and paste between the systems. If you want x2x to be as secure using the second method as it is with the first, you have to resort to SSH port forwarding, which may be difficult because x2x does not use a consistent port on the primary machine. In either case, the machines that run x2x have to support the XTEST X Window extension. Most Linux distributions do; to see if yours does, run the command xdpyinfo | grep XTEST in a terminal. If you get any response, you are over the first hurdle.
To install x2x in Ubuntu or any Debian-based distro, run the command sudo apt-get install x2x. Unfortunately, Fedora 9 does not include x2x, but Fedora 8 does, and it installs in Fedora 9 without dependency problems. I used the package from the Dries RPM repository. For any other distro, look for x2x in the package manager. Compiling from source may not be an option, because the download links on the project's home page don't lead you to the code. The project hosts a Mercurial repository, but the code there is for the unstable 1.30 beta version. If you want the stable 1.27 code, you will have to look for it in a distro repository. The two versions of x2x use different protocols, so make sure the versions on your machines match.
To use x2x, you need to have a secure shell daemon running on the remote machine. For both Ubuntu 8.04.1 and Fedora 9, the SSH daemon should already be installed. If it's not, in Ubuntu, either install it using Synaptic, or run the command sudo apt-get install ssh. For Fedora, run the command sudo yum install openssh.
One additional caveat: If you are using a login manager such as gdm, you must enable remote TCP connections to the X server. In Ubuntu 8.04.1 run the command sudo /usr/sbin/gdmsetup. Select the Security tab and uncheck the "Deny TCP connections to the Xserver" checkbox. For Fedora and other distros, consult the documentation for the X server and login manager. A quick check of netstat -a | grep x11 will tell you if you need to investigate further. If the result comes back containing LISTEN, you should be ready to go.
Once all of the dependencies are satisfied, setting up method one is simple. First, determine the orientation of the displays -- will the remote display be north, south, east, or west of the primary machine? On the machine that hosts the keyboard and mouse, run the command:
ssh -X remote_machinename_or_ip_address x2x -direction_of_the_remote_display -to :0
On my test machine, since the remote display was to the left of the primary display, I used the -west option. If all goes well, a prompt for your password on the remote machine should follow. Enter it, and you should be able to move the mouse to the edge of the primary display and have it appear on the remote display.
One advantage to this method is that the only machine that requires x2x to be installed is the remote machine. As a test, I disabled x2x on the primary system and tried connecting and running x2x through SSH. It worked perfectly. This is very handy if the primary machine limits your access to configuration files.
Method two is a little more complex, but potentially worth it if you can gain the ability to do cut and paste between machines. On my test rig I was never able to get that functionality working, and unfortunately, good documentation for x2x is limited.
With the second method, before you can connect to the remote display, you have to add the IP address or hostname of the primary machine to the xhost authentication on the remote machine or the primary machine will be denied access. To do so, run xhost IP_or_hostname at the command line on the remote machine. If there are no errors, carry on; otherwise, look into security settings on the remote machine. Once you're successful, run the following command on the primary machine:
x2x -to IP_or_hostname:0.0 -direction_of_the_remote_display
You should then be up and running. Move the mouse to the edge of the screen in the direction that you chose. If all goes well, the mouse will disappear from the primary machine and appear on the remote machine. Try cutting and pasting; if it works, great! If not, well, don't say I didn't warn you.
If all you want is quick access to more than one display on different machines with one keyboard and mouse, x2x works well, particularly if you have root access to only the remote machines. If you absolutely must have cut and paste, or your machine mix includes Mac OS X, you may want to consider Synergy instead.
The software was developed in 1996 by David Chaiken at DEC. It is currently maintained by Mikhail Gusarov.
x2x joins a pair of X displays together, as if they were a single multiheaded display. The pointer can be warped between displays, or, depending on how you start x2x, can slide from one display to the other when it runs off the edge of the screen. Keyboard focus also moves between displays in the way you'd expect, and the X selection propagates around. At least one of the displays involved (specifically, the one being controlled remotely) must support the XTEST extension. (The servers shipped by Debian support this.)
x2x is useful when you have two displays on the same desk, as you can use a single keyboard and mouse to control both. If you want to propagate your selections between displays which are not sharing a desk, you might be more interested in the package propsel. Propsel does not link the displays' keyboard and mouse, which would be confusing in some cases, and can propagate between up to 8 displays, whereas x2x can handle only two at a time.
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 exten-
sion, the "to" X display must support XTEST.
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 -east or -west options are specified on the command line, x2x
starts up with a different interface. When the mouse moves to the
(east 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.
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 per-
forming 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.
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 exten-
sion, the "to" X display must support XTEST.
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 -east or -west options are specified on the command line, x2x
starts up with a different interface. When the mouse moves to the
(east 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.
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 per-
forming 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.
x2x is a software alternative to a KVM switch.
Unless you have fully embraced the virtualization movement, you probably have more than one machine in your home or office, particularly if you run more than one operating system, and you probably have more than one keyboard and mouse on your desk. If you would like to regain some desk space without having to purchase a KVM switch, x2x may be the solution. Simply put, x2x takes advantage of the X Window System's ability to run a display over a TCP/IP network. In this case, you are not running a display as much as you are taking charge of another display's mouse and keyboard.
You can run x2x over SSH, which is easy and secure, or connect x2x directly to the remote X server. The second method is a bit more difficult because it requires some reconfiguring of your X system, but it gives you the ability to cut and paste between the systems. If you want x2x to be as secure using the second method as it is with the first, you have to resort to SSH port forwarding, which may be difficult because x2x does not use a consistent port on the primary machine. In either case, the machines that run x2x have to support the XTEST X Window extension. Most Linux distributions do; to see if yours does, run the command xdpyinfo | grep XTEST in a terminal. If you get any response, you are over the first hurdle.
To install x2x in Ubuntu or any Debian-based distro, run the command sudo apt-get install x2x. Unfortunately, Fedora 9 does not include x2x, but Fedora 8 does, and it installs in Fedora 9 without dependency problems. I used the package from the Dries RPM repository. For any other distro, look for x2x in the package manager. Compiling from source may not be an option, because the download links on the project's home page don't lead you to the code. The project hosts a Mercurial repository, but the code there is for the unstable 1.30 beta version. If you want the stable 1.27 code, you will have to look for it in a distro repository. The two versions of x2x use different protocols, so make sure the versions on your machines match.
To use x2x, you need to have a secure shell daemon running on the remote machine. For both Ubuntu 8.04.1 and Fedora 9, the SSH daemon should already be installed. If it's not, in Ubuntu, either install it using Synaptic, or run the command sudo apt-get install ssh. For Fedora, run the command sudo yum install openssh.
One additional caveat: If you are using a login manager such as gdm, you must enable remote TCP connections to the X server. In Ubuntu 8.04.1 run the command sudo /usr/sbin/gdmsetup. Select the Security tab and uncheck the "Deny TCP connections to the Xserver" checkbox. For Fedora and other distros, consult the documentation for the X server and login manager. A quick check of netstat -a | grep x11 will tell you if you need to investigate further. If the result comes back containing LISTEN, you should be ready to go.
Once all of the dependencies are satisfied, setting up method one is simple. First, determine the orientation of the displays -- will the remote display be north, south, east, or west of the primary machine? On the machine that hosts the keyboard and mouse, run the command:
ssh -X remote_machinename_or_ip_address x2x -direction_of_the_remote_display -to :0
On my test machine, since the remote display was to the left of the primary display, I used the -west option. If all goes well, a prompt for your password on the remote machine should follow. Enter it, and you should be able to move the mouse to the edge of the primary display and have it appear on the remote display.
One advantage to this method is that the only machine that requires x2x to be installed is the remote machine. As a test, I disabled x2x on the primary system and tried connecting and running x2x through SSH. It worked perfectly. This is very handy if the primary machine limits your access to configuration files.
Method two is a little more complex, but potentially worth it if you can gain the ability to do cut and paste between machines. On my test rig I was never able to get that functionality working, and unfortunately, good documentation for x2x is limited.
With the second method, before you can connect to the remote display, you have to add the IP address or hostname of the primary machine to the xhost authentication on the remote machine or the primary machine will be denied access. To do so, run xhost IP_or_hostname at the command line on the remote machine. If there are no errors, carry on; otherwise, look into security settings on the remote machine. Once you're successful, run the following command on the primary machine:
x2x -to IP_or_hostname:0.0 -direction_of_the_remote_display
You should then be up and running. Move the mouse to the edge of the screen in the direction that you chose. If all goes well, the mouse will disappear from the primary machine and appear on the remote machine. Try cutting and pasting; if it works, great! If not, well, don't say I didn't warn you.
If all you want is quick access to more than one display on different machines with one keyboard and mouse, x2x works well, particularly if you have root access to only the remote machines. If you absolutely must have cut and paste, or your machine mix includes Mac OS X, you may want to consider Synergy instead.
Custom Search
If you liked this article, subscribe to the feed by clicking the image below to keep informed about new contents of the blog:
0 comments:
Post a Comment