Using synergy: Trips and Traps

Synergy is a program to combine a number of host displays together (using one keyboard and mouse). Using the network, it allows you to move your mouse seamlessly from one system’s display to another – including combining many displays in this way. However, there are some trips for the unwary – or just plain surprises. None of this should make you stop using synergy; but knowing about it and what to do about it can make your use of synergy better. If you aren’t already using synergy, you should be.

The network data used by synergy is unencrypted. This means when you type in passwords on a synergy client, the passwords are sent in the clear across the network. To take care of this, use an ssh tunnel:

$ ssh -R 24800:syn-server:24800 syn-client

Then on the synergy client host, use for the synergy server address:

$ synergyc

This will encrypt the traffic between the two hosts.

If any process hogs the processor on the machine your mouse is active on, you won’t be able to switch to another display. This makes sense when you think about it, but it still can come as a surprise. What is happening is that the synergy client program is not able to run, so it doesn’t respond when you hit the edge of the screen. Still, it would be nice if the server would recognize a client in this state and relocate the mouse somewhere you can use it.

The mouse can spontaneously relocate. This can happen for a variety of reasons – the most common is that while the synergy “mouse” has a different location than the actual mouse. When you switch from one to the other, the operating system thinks the mouse has “jumped” and moves the mouse pointer on screen accordingly. On inactive systems (where synergy does not have a pointer) the “physical” mouse pointer is usually put at the center of the screen (and usually hidden). Again, this is a little bit of a surprise, but not damaging.

The Windows-based synergy server may stop handling remote clipboards. This has been a bug with the Windows version of synergy, and can be “fixed” be restarting synergy.

XWindows clipboards may appear to not transfer. This is because XWindows has two clipboards. When you select a string of text in an xterm, for example, the data is put into a particular clipboard. However, this is not the primary clipboard and thus synergy does not transfer it. You can copy the selected text with a right-click menu and selecting “Copy…” or you can use a program like xclip to move the clipboard data into the right place.

With all of those desktops together, you’ll find that you may lose the location of the mouse from time to time. This is where the capability of “locating” the mouse with the press of a key comes in handy. Windows will do this, as will GNOME and KDE. Windows is configured to answer to a single press of the Control key. Some systems show you where the mouse is with a ever-shrinking set of rings (Windows) or squares (Fedora); Linux Mint is set up to flash a disk around the cursor.

When moving the mouse cursor across all of the different desktops, the speed and acceleration of each controls how the mouse moves when it is in that desktop. This can present itself in the form of a desktop acting like “quicksand” – the mouse moves fast until it gets to a desktop, then on that desktop the mouse moves slower until it gets to the other side. Adjust the mouse properties of each system until the mouse acts appropriately. You still won’t be able to (probably) shove the mose over and have the mouse go all the way from right to left (or vice versa) but moving will be nicer.

Watch where your mouse focus is. When you select a text box on one system, you typically then may move the mouse “out of the way.” However, if “out of the way” means the mouse is now on another system, then when you type the characters will go somewhere you don’t want them to go. This can be dangerous if you are typing in a password; don’t let your password go out over IRC or something because the wrong system’s desktop is active. It may be a good idea to break off the habit of moving the mouse off to the side; you don’t need to do this.

Bug: synergyc freezes

If you are using Synergy in your daily work, you may have noticed that the Linux client is not working as it should. A bug (Bug #194029) reported to the Ubuntu development team provides extensive reports about the problem and possible resolutions. The biggest problem is sifting through all of them, as well as the realization that they don’t seem to have it fixed yet.

Admittedly, my problems are with Fedora 9 and Windowmaker (which shows that its not Ubuntu-specific, nor is it specific to GNOME or KDE). However, the resolutions seem to work under Fedora just as well as under Ubuntu.

The resolutions recommended are:

  • Run synergy as root: sudo synergyc. This resolution seems to be one least likely to work.
  • Run synergy with the highest priority possible using chrt: chrt -p 99 synergyc. This method can be incorporated into a startup script thusly: /usr/bin/synergyc myserver; pgrep synergyc | sudo xargs chrt -p 99
  • Recompiling the Linux kernel with a different scheduler: instead of configuring with CONFIG_FAIR_USER_SCHED use CONFIG_FAIR_CGROUP_SCHED.
  • Patching synergyc to fix the problem.
  • Enabling (for Ubuntu only) the hardy-proposed repository and updating the kernel to 2.6.24-16 or 2.6.24-17-generic seemed to work (although there were complaints that the desktop became sluggish).

In the case of Fedora 9 at least, this bug remains present even though it is almost a year old. I don’t use synergyc on a Ubuntu client – my Kubuntu host I use almost entirely at the console directly.

So what is the answer? I’d try using chrt first (for me that lessened the problem dramatically) and try upgrading to a new kernel configuration.