I recently picked up a few Avocent DSR4020s off eBay for pretty cheap. They're IP KVM switches which I'd hoped to get up and running over my network so I could do remote administration of the machines, but it turns out that the networked part requires proprietary software which you pretty much can't get from Avocent (now owned by Emerson) for the boxes in question, possibly even if you offer to shell out wads of cash. The general feeling on the internet is that the IP client was not that great anyway.
On the bright side, they have a local port for VGA + PS/2 keyboard/mouse which makes for a pretty nice 16-port KVM switch if you get the dongles, some of which can also be quite cheap. For $30-50 on eBay, you can get the switch, plus $8 or so each for the PS/2 version of the dongles (the USB ones seem to be somewhat more, but they also have plain serial and Sun versions as well).
That's all well and good, I figured I could use it on my Macs with ADB->PS2 adaptors since decent ADB KVMs are pretty hard to come by now, but that's kind of clunky. Besides, I was curious to see what made the dongles tick; they connect over Cat5, so I figured even at the price they originally went for at retail, there's no way they would stick a triple 100+ MHz ADC on each of those dongles (for one thing, you probably would have had a hard time powering it off of 500 mA). So I opened one of the pods for the PS/2+VGA dongles up (required a Vise-Grip to crack it, but it worked).
I'll post pictures later, but it's actually a pretty simple setup.
It uses an EL4543 to amplify the analog video and send it out over three of the Cat5 pairs; that's actually a really neat little chip, it sends the sync bits over the three channels by playing with the common mode voltages. That also explains why there's no DVI or other digital versions of the pods.
It then takes the PS/2 signals in to a bog-standard 8051 compatible micro, the SST89E516RD2, which is the main controller in the pod; there's an EEPROM hanging off the micro, and it communicates with the KVM switch through an RS485 converter (ISL485EIBZ, which looks to be an Avocent-specific version of the ISL8485). Curiously, probably because they needed a reference ground for the common-mode voltages of the DAC, it only uses the positive leg of the converter, with the negative leg driven to 1/2 VCC; at that rate, they might as well have used an RS232 converter if not for the half-duplex mode.
There's just a cable coming into a socket for the video and the PS/2 lines, which suggests to me that there may be a common board for at least their PS/2 and Sun versions, since those are mostly at least electrically compatible.
Nicely enough, they provided test points that hook up to the microcontroller reset line and all 4 relevant comms lines (Tx, Rx, TxEn, RxEn), which should make it pretty easy to hook up a logic analyzer to start looking at the protocol. I have the USB version coming in and will probably get the Sun version soon as well to see the differences (PS/2 and Sun (and ADB for that matter) are bit-bangable 5v signals, but that micro doesn't have USB support and there's no controller for it on the board, so clearly their implementation isn't totally universal; there's no provision for an RS232 converter on there for their serial version, either).
In any case, my assumption is that all the interesting keyboard/mouse data comes over the RS485 line encapsulated in a custom protocol. There's some intelligent device querying in there; individual dongles remember their names that you assign them, among other things. I'm willing to bet that there's some sort of copy protection/lockout scheme in there as well, though it'll have to wait until I get time to look at the communications before I know for sure. The micro they use supports some pretty potent code protection schemes, so it may be impossible to read the code out to disassemble, but just in case, I've ordered a compatible programmer/reader and TQFP test/programming jig off eBay.
I'd like to see about making a dongle (should be relatively cheap) that can do ADB directly since these switches can be bought for a song on eBay. There's no reason a "universal" dongle couldn't be made that handles all the popular modes, perhaps with a DIP switch for selecting the type. I also don't think the ISL4543 supports sync-on-green natively, which is essential for some 68k Macs, so full support for that and the Mac sense codes a la the Griffin MacPnP adaptor would be swell as well.
Yeah, I've been a fan of the older VGA based NTI KVMs. No IP aspect, but they natively support PS2, Sun, and ADB keyboard/mouse protocols and all the keymapping to go from any one of those three, to any other of the three protocols. And the PS2 implementation supports SGI's, which is nice. Also supporting SoG for all the OSD support.
They have Sun connectors on the KVM for the keyboard, and then you get cables to go from that to PS2 or ADB. I guess they recently stopped selling the ADB cables, but sometimes you can still find some. They're entirely passive cables, so making your own is entirely feasible.
You can sometimes find these on ebay for relatively cheap, and I've managed to collect several of the multiplexing matrices, like a 2x16 and 4x48 one.
As KVMs go, I'm a huge fan of these ones for the wide variety of old computers they support.
Like I said, no IP capability. I ended up getting an iPEPs KVM IP device, which takes a single vga/ps2 keyboard/mouse and lets you connect to that via VNC. Their VNC server then has its own set of OSD settings to let you tune/configure the VNC session. I connected that to the output of the NTI KVM, to let me VNC to the KVM and subsequently get access to all the machines its connected to. The problem I have is VNC is (usually, more on that in a sec) absolute positioning of the mouse. That is, when you move your mouse inside the VNC client, the VNC cursor gets absolute positioning of the host's cursor inside the host's window. All the mouse acceleration is the host's, otherwise the host and the remote vnc cursors would get out of sync, and when one reached the edge of the VNC window, there would be confusion.
This gets problematic for KVMIP because the PS2 protocol is all relative mouse movements. So when VNC says "move the mouse here", the KVMIP device needs to know how many mouse movement units to send over PS2 to accomplish that. The fallback is just to send the delta x/y, but then the machine the KVMIP is connected to interprets that however it wants, and applies its own mouse acceleration formula, and VNC gets out of sync quickly.
So, the iPEPs KVMIP device attempts to find and track the mouse cursor by interpreting the VGA signal, and then tries to generate approximate PS2 mouse x/y deltas to keep the VNC cursor and the cursor it finds in the VGA signal, in sync. Unfortunately, the iPEP's ability to locate the cursor within the VGA signal is limited, and is tuned specifically for Windows. When it works, it usually works OK. But most of the time it doesn't work, and it falls back to the VNC cursor's x/y deltas and it gets all out of sync, making it very frustrating to use. It's possible in an emergency, but it's definitely not something you'd use as a console substitute.
Another option there is the VNC protocol supports sending relative mouse offsets. Most clients don't support this, because it's an odd user experience for the client. Basically to make it work, you have to capture the cursor inside the VNC client window, and essentially remove the host cursor entirely. I haven't found many VNC clients that support this, but RealVNC does with the right settings. That usually works OK, but again is a bit jarring to not have the VNC client integrated with your host's workflow.
Hey, so it's been a while since I posted on this, but I finally took a bit of time to try to break into the KVM box. So far, it's been pretty successful, though there's still a long way to go; I'm logging my efforts on Twitter here if you want to track them. The summary so far:
The main CPU on the KVM board itself is a PowerQUICC II, which is PPC-based
There's an internal UART port which lets you access the system console, which will drop you to a root shell if you ask nicely
It looks like the CPU JTAG port is exposed as well
The system is running on a VERY stripped-down MontaVista Linux on kernel 2.4.2, but fortunately has all the parts built in to mount NFS; modern PPC busybox runs on it just fine, which is good because it didn't come with 'cat' or 'cp' or 'chmod' or basically anything else
All the KVM services seem to run under one monolithic executable (ugh) that serves 4 ports: the K/M service, the discovery service, the authentication service and the video service
There is a tiny bit of public code out there that details the protocol for the authentication service
So anyway, now I have the actual executable for the service (which doesn't seem to validate SSL certs to make sure they come from the real DSView service), so it's going to be a matter of many long nights with IDA Pro going through it. Fortunately, even though the executable is stripped, they put in a LOT of debug strings for the log, so it should be reasonably easy to trace where the different parts live.
Here's hoping some day I can a) use this as a remote KVM server instead of just the local console I've been doing, and b) build a Mac input pod that deals with ADB properly.