Two Computers, Two Displays, Together and Apart: TeamViewer, KVM, and Input Director

I had just installed Windows 7, after working out networking hassles between two computers.  I had set up a home network.  Now, following up on a previous post, I wondered whether I could use TeamViewer and Input Director to permit smoother use of those two machines.  The general idea was that I had two networked computers, each with its own monitor, and I wanted to use one or both of those programs to facilitate a seamless desktop experience.  This post describes my exploration of related possibilities.

I decided to start with Input Director.  The purpose of this program was to let me use a keyboard and mouse on computer A to do work on both computers A and B, without needing a keyboard-video-mouse (KVM) switch.  To give this a whirl, instructions advised installing Input Director (ID) on each computer.  I started ID on computer A, turned aside for a moment to attend to something else, came back to computer A, and found that ID had disappeared.  I restarted it and clicked "Enable as Master," and likewise enabled computer B as slave.  I started to change the default hotkey from the way they had it set up, which looked very complex but apparently just meant left-Ctrl-Alt-Break -- but then ID disappeared again!  It wasn't in the system tray either.  It had just died.  But on retry, it was OK.  I wasn't sure what happened there.  I went into Master (or Slave) Configuration.  Not to much to do there.  On computer A, I clicked Add and then tried to figure out what I should use as Hostname and Port for the slave I was trying to attach.  I tried just using the name of computer B.  This brought an error, "Slave 'ComputerB' didn't respond," and on computer B I got a popup balloon saying this:

Unauthorised access
A request to direct input by the unauthorised system ComputerA was rejected.

I thought maybe this was because computer B wasn't set up yet.  So in its Slave Configuration tab, I clicked "Allow computers only on this subnet to take control."  It asked for Network and Mask, which I wasn't sure of, so I clicked "Select from list."  I had VMware on this computer, so there were a couple of options for that, but I went with the one for the Realtek PCIe GBE Family Controller.  I also clicked on Add and typed in the name of computer A as Master Hostname.  Now both computers were visible in the Master Configuration tab on computer A.  In the Master Preferences tab, I cleared hotkeys, since I didn't think I would want to use them and didn't want them interfering with other programs.  And then, what do you know, it was working.  The mouse on computer A was able to keep going rightwards, past the right edge of the computer A display, and move across onto the monitor for computer B and do things there.  The keyboard was still going where my KVM set it, so I unplugged it from the KVM and plugged it directly into the computer.  Wow, just like that, the monitor that I selected with the mouse was also the monitor where the keyboard was active.  If I moved the mouse to the monitor that was plugged into computer A, I had a keyboard on computer A.  If I moved the mouse over to computer B's monitor, I had a keyboard there instead.  Basically, a mouse-controlled KVM.

To get adjusted to this new arrangement, I unplugged and rearranged mice and keyboards and rebooted both machines.  Now, suddenly, computer B was unable to go online.  It had been fine until now.  I disabled Input Director and rebooted.  The disabling was not persistent; ID was back.  I uninstalled Input Director and rebooted again.  Now, for a moment there, my customized Start Menu was broken.  I still was not able to go online.  Unfortunately, I now discovered that System Restore had somehow gotten turned off -- on computer B only, despite having set it up from a mirror of computer A, where System Restore was still working -- so I had to restore an image of computer B.  While nothing is certain, these problems were new.  They seemed likely to be due to Input Director.  As soon as the mirror was restored, I uninstalled ID.  The problems did not recur in the next 24 hours of fairly intensive work, so it looked like ID was the culprit.

Without Input Director, I hoped that something of my multiple desktop vision would remain.  From my understanding of TeamViewer, it did not seem that I would have the option of switching my two computers and two monitors back and forth between dedicated and dual-monitor formats.  But maybe I still could, with a KVM.  To investigate that, I had to get TeamViewer working first.  I installed and ran it on both computers A and B.  It started with a dialog that gave me a Remote Control tab containing a session ID.  I typed the session ID appearing onscreen in computer A into the dialog box on computer B and chose the Remote Control option.  It said, "You have entered the ID of your own computer."  Well, that was true.  Both machines were showing the same ID.  So apparently I was not doing this right.  But there did not seem to be an alternative.

I stepped back and reviwed the concept.  I wanted to use computer A to control either computer A or B.  This, again, was to be a KVM-type solution without using a KVM.  Instead of switching between computers (e.g., changing the focus of my mouse and keyboard from computer A to computer B) by hitting a hotkey or physical button linked to the KVM, I would switch between computers by clicking on a button onscreen or by hitting a hotkey linked to Teamviewer via the network cable.  In this way, I would not need the KVM.  But I was not sure TeamViewer was ready to play this game.  The solution, someone said, was to click on Extras, at the top-right corner of the first Teamviewer dialog, and go into Options > General tab > Incoming LAN connections > accept.

Instead of doing that, at this point I decided that I was already getting the functionality I needed for the time being.  Hence, I decided to shelve this project until later.  The KVM situation was acceptable.  GoodSync had recently begun to provide much of what I had thought I wanted from Teamviewer.  Also, that brief taste of Input Director had caught my attention.  That seemed to be the next step forward in this area.  The Teamviewer concept, or an alternative, seemed to be something that I should review later, after I had some experience with this setup, and after waiting a bit for possible improvements to Input Director or for good alternatives to it.

Windows 7: Multiple Monitors, Multiple Computers: Possibilities

I planned to be using Windows 7 on two computers.  At the start, I had two monitors, each dedicated to its own computer.  I wondered if I could set up the system so that I could use both monitors for computer A, and could also use both monitors for computer B.  I also wondered if I could use monitor A to see what was happening on both computers A and B at the same instant.

My first search led to ads for KVM switches, but that wasn't what I wanted.  I did look into KVM switches at Newegg, just in case someone had invented a switch that would do everything.  But then realized I wasn't going to read through all those product descriptions to see if any of them had the possibilities I wanted.  A different search got closer to what I wanted.  Actually, it went well beyond it.  There were possibilities I hadn't even imagined.

One possibility was that of Synergy, which had originally been Synergy and then became Synergy-Plus and was now back to being Synergy.  It looked like the Synergy concept ws that I could have two or more computers, each having its own monitor, and I could have just one keyboard and one mouse, and would move among these computers simply by moving the mouse to the left or right, until it left one monitor and then appeared on the next.  No KVM switch; just move the mouse to switch computers.  The connection was by ethernet -- just get all computers on the same network.  They said you could also copy and paste between the computers.  But apparently Synergy wasn't entirely stable yet; that was their stated goal for 2012. For that reason, I decided I would prefer a KVM for now, if necessary.  Presumably a problem with the network would render all computers other than the server (i.e., the one to which the keyboard and mouse were connected) unavailable.  Bruce Tyson pointed out that there would also be a problem if the user wanted to access the BIOS of a slave or client computer during bootup.  It seemed like it might be a good idea to have a spare keyboard and mouse handy.  Another possibility:  Input Director.  This Windows-specific freeware application seemed to have the same concept as Synergy.  These sorts of programs seemed to have the same idea as a KVM switch that would allow one keyboard (e.g., that on a laptop) to take control of another computer even if it did have its own keyboard and mouse.

Bruce Tyson also pointed me toward web-based sharing services, Virtual Network Computing (VNC), and remote desktop software.  These apparently all were, or could be, variations of "headless" computing, where the keyboard, video, and mouse (KVM) are all connected to just one computer, which is then linked to others whose contents may display on that monitor.  He also noted that some monitors have dual inputs, which could be plugged into separate computers, but that the user would have to switch between them using buttons on the monitor.  That would prevent simultaneous viewing of two computers and would also be klunky in daily use.

It seemed that GoToMyPC.com was one of the leading web-based services.  But when I looked into it, these appeared to be simply ways of accessing the computer remotely.  At $10/month or more, it was pricey.  LogMeIn and others seemed to offer good free alternatives.  I decided I didn't want a web-based service, even if it did exactly what I wanted, because it would be relatively slow and it would be vulnerable to anything that might go wrong with the modem, the network connection, etc.

According to Wikipedia, VNC was both platform-independent and remote-capable, and some versions were "optimised for Microsoft Windows."  A list of versions indicated that UltraVNC (free) was the most advanced mainstream version and was the basis for several others.  Current alternatives for connecting a few Windows PCs included EchoVNC (free), RealVNC (free+), SmartCode VNC Manager ($129+), SupportAnyPC ($149), TeamViewer (free), and TightVNC (free).  Among these, a RealVNC feature comparison page indicated that its free version was not compatible with Windows 7.  Wikipedia pages for the free versions indicated that RealVNC was similar to UltraVNC, but the latter had more features; EchoVNC differed from UltraVNC in being more firewall-friendly; Teamviewer was mostly for remote control of computers; and TightVNC likewise had spun off a firewall-friendly variant, RemoteVNC ($25 per computer), among others.  A Wikipedia comparison page, only in it formative stages at this point, named Skype, TigerVNC, and xpra as other free Windows-compatible remote desktop programs.  The Wikipedia pages just linked for those additions indicated that TigerVNC was a fork of RealVNC; that Skype was (of course) primarily for VoIP; and that xpra (currently a beta product) used an approach that differed from that of VNC; but it later looked like xpra was not for Windows.  For my purposes, the survivors of this discussion were EchoVNC, TigerVNC, TightVNC, and UltraVNC.

I looked at a Wikipedia page showing a comparison of Java remote desktop projects. I was not sure what this was about. The project that seemed most feature-rich at this point was WallCooler VPN, so I looked into that. This actually led to a page for Vedivi, which seemed to be in the business of giving people access to remote computers at a low monthly price.

Eventually I figured out that there are many remote desktop protocols.  VNC was one; Remote Desktop Protocol (RDP) was a Windows-specific alternative.  There were others.  I eventually found a chart that, although officially for Mac, pulled together some of this.  Revisting the Synergy and Input Director webpages (above), I saw that Synergy was not a VNC project; I was not clear what type it was, and likewise for Input Director.  Supposedly Microsoft's own version of RDP was currently called Remote Desktop Services, previously Terminal Services; but when I went looking for it, I wound up in Remote Desktop Connection (RDC).  A search led me to a description that sounded like what I was looking for.  I wondered why someone would have bothered creating Input Director, with its Windows orientation, if this feature already existed in RDC.  I decided to start by trying to use RDC, to see what would happen.  That would be the subject of another post.

Multiple Computers: Remote Desktop Connection, Input Director, TeamViewer

In a previous post, I looked at various ways to control two computers with one keyboard, and for mixing monitors among computers, without using a KVM switch.  I came away thinking that I should start with the Remote Desktop Connection (RDC) option in Windows 7 (not available in Home editions).  I had lots of questions about the best way to combine two computers for maximum efficiency without too much complexity.

As I revisited RDC, I now wondered whether it offered the best solution for my purposes.  RDC would apparently give me just what its name implied:  a way to connect to the desktop on one computer while working at another.  In a home network setting, I would be looking at the same physical display unit(s) as I switched my attention between the two computers located under the desk.  It was tempting that RDC came built-in with Windows 7.  I was not entirely sure what its "continuous resolution" feature was about, but it sounded interesting.

To get a clearer understanding of RDC, I looked at some YouTube video demonstrations.  The ones I looked at were more in the nature of tutorials on how to set up RDC, as distinct from what it was like to use it.  They were still informative.  I hadn't fully registered that I could use RDC in Windows XP, in case I wanted to do that.

The basic idea seemed to be that, in RDC, I would choose to be working in computer A, or perhaps in computer B; and whichever I chose would be the one I would see onscreen.  If I chose to work in computer A, I would see the computer A desktop.  So then hopefully I could rig up multiple monitors to show a big spread of what was happening on computer A, and I could switch and have those monitors show a big spread of what was happening on computer B.

A video of Input Director clarified things somewhat.  Input Director had preliminarily seemed, to me, to be the leading alternative to RDC.  The difference that I found striking was that Input Director would let me move from one computer's dedicated monitor to the next, just by moving my mouse, and the keyboard would tag along.  So computer A would have its own monitor(s), and computer B would have its own separate monitor(s).  The other nice feature of Input Director that emerged in that video was that you could copy text in one computer and paste it into the other.  Unlike RDC, where the computers could be halfway around the world from each other, the computers in Input Director would be more or less next to each other, connected by a router (in e.g., a home network), so that the user could view their respective displays.

As I was browsing around, I found a discussion containing enthusiastic endorsements of TeamViewer.  I had actually used that in a tech support call a few months earlier, when someone basically used it to take control of my computer and make changes so that the item in question would work.  So I wound up watching a video about TeamViewer too.  It seemed to be similar in concept to RDC, though at this point I was thinking TeamViewer might be a better-quality option than RDC, and was available across multiple operating systems.

For purposes of tinkering and initial investigation, then, it was a choice between Input Director and TeamViewer.  There was no question the latter was vastly more widely spread around the world.  For me it was mainly a question of which features I wanted or needed most.  If I always wanted to see displays that would show me what was happening on two or more distinct computers, then it had to be Input Director (or, someday, maybe Synergy).  If I wanted to focus both (or all) of the available monitors on one computer, then it would be TeamViewer.

There seemed to be a way to use both.  I could start with two separate computers at my desk.  Events on computer A would appear on display A; events on computer B would appear on display B.  In that setup, Input Director would let me switch the focus of the keyboard between computers, as I moved the mouse back and forth between displays.  Then, that situation could be changed.  I could equip display B with a KVM switch.  As long as I left display B connected with computer B, the situation would be as just described.  But if I pressed the button to change the focus of display B so that it would be covering computer A, now I would have a dual-monitor presentation of events on computer A.  Finally, if I had TeamViewer running on computer A, then I could use it to provide a dual-screen view of computer B as well.  In other words, by using the KVM switch I would free display B from having to follow along to whatever computer TeamViewer was focused on.  The switch would make it possible to *not* do multi-monitor work, in which case Input Director would be useful.  This approach would let me switch display styles to match the nature of the task and my preferred work style, without needing the cost and desk space required for a third display.

Whether the reality would match the theory was another question.  But this was the scenario I would explore further in a subsequent post.