KVM cards

Bill Freeman f at ke1g.mv.com
Thu Oct 10 11:00:05 EDT 2002


Michael O'Donnell writes:
 > In my imagination, our device would
 > 
 >  - Be implemented as a "standard" PCI card, small as possible.

	Do you really mean PCI card (the kind of thing that has
replaced ISA for expansion withing a desktop PC), or, as I suspect, do
you really mean PCMCIA, a.k.a. "PC-card" (sic, really sick, since that
name is still, for me, any "printed circuit card", a.k.a.  "printed
circuit board", a.k.a. "printed wiring board")?  The interface is
certainly related to the PCI design, but isn't the same.

 >    ALTERNATIVE: a USB-connected thingy, a-la the USB
 >                 serial-converters in common use by Mac owners.

	USB is probably the better modern alternative.  I believe that
I've seen some newer laptops without PCMCIA slots, but they nearly all
have USB, and if you're stuck with a laptop that has the reverse,
there are commercial PCMCIA cards that provide a USB interface.  The
USB dongle could be large-ish for early implementations, while a
PCMCIA design must be miniaturized enough to fit in the slot from the
get-go.  Serial ports are now frequently absent from laptops, but
ECP/EPP/SPP parallel ports are still commonly native, and represent
another alternative, but probably don't support adequate bandwidth for
mouse pointer tracking comfort.

 >  - Video connection would be the current "standard" SVGA
 >    D-shell connectors as found on current "commodity" cards.

	If that's what the targets have.  I was wondering if you had
particular targets in mind that you know about for sure.  The VGA D
connectors (the S in SVGA makes no difference in the connector) are
indeed the current standard.  If necessary, however, the older 9 pin
EGA/CGA/HGA/MDA connectors could be supported with a passive adapter,
since, if we have enough inputs to read VGA, we have enough inputs to
read the others.

 >  - Video resolution would be either 1024x768 or 800x600.

	I agree that this is probably an acceptible limitation.
Sadly, there are still a number of possible dot clock, vertical, and
horizontal rate and interleave combinations.  Usually the graphics
adapter can support multiple combinations to work within the
limitations of the monitor connected.  While you can usually change
between a few resolutions, to get different scanning rates for the
same resolution windows is probably going to ask for the installation
CD, or some such, so it would be good to be flexible about scanning
rates and dot clocks accepted.  Scanning rates and interleave are
directly measurable from the hsync and vsync signals, but dot clock
rate and phase may still have to be inferred or hand tuned.  It might
be possible to do a statistical analysis or where transitions in the
video occur in the post sampled stream across a number of dot clock
rates and come up with a good guess at dot clock rate and phase, so
long as the screen isn't currently nearly blank.

 >  - Keyboard and mouse would connect (electrically and
 >    mechanically) with current "standard" PS/2 style interface.
 >    ALTERNATIVE: USB (?) - is this common in commodity boxes?

	I've yet to see a motherboard without PS/2 (or in the past,
PC-AT or PC-XT) keyboard connectors.  Probably all the recent ones
also support PS/2 mouse.  But those with modern BIOSes and USB
hardware also support use of USB keyboard and mouse, even in BIOS
setup.  However, I have no experience with the N PC equivelents in a
1U rack boxes.  Aren't those the target?  Or have you seen a lot of
"tower" cased single PCs being run without keyboards moniters and
mice?  PS/2 is probably the interface with the largest guaranteed
availablity at the moment, but USB is a commer.  There may even be
enough spare pins to carry it on the VGA connector, allowing one cable
from monitor to computer, with keyboard and mouse USB plugged into the
monitor (apparently folks think that cable neatness is a big selling
point).

 >  - Host computer not constrained as to which OS it runs.
 > 
 > 
 > How does this device present itself to the host computer?
 > Are the grabbed frames presented as mem-mapped bit-array?
 > 
 > 
 > Should build on as much existing SW/subsystems as possible.

	I'm not sure which computer is the "host".  I presume that you
mean the laptop.  I'm going to try to use the terms "target" and
"portable", which I hope are clear.

	There is at the very least a user program that must run in
support of the application on the portable, and it is clearly OS
sepcific, unless written in something like python/tkinter that pushes
the OS specific issues off on someone else.  I.e.; python/tkinter is
widely available for a variety of platforms already, and with the
speed of modern portables the performance might be adequate.

	  PCMCIA or USB interfaces might avoid the need for kernel
specific custom driver level by appearing at the interface to be a
mass storage device, where you write to files to press keys and move
the mouse, and you read from a file to find out what bits are on the
target's screen.  My presumption is that any OS that we care to run on
a portable will now have support for USB and PCMCIA MSDs without the
need for a vendor supplied driver (like you can plug in a USB keyboard
and mouse without the need for specific drivers).

 > I'm currently ignorant about USB.

Nutshell mode: USB 1.x supports two raw data rates: 1.5 and 12 bits
per microsecond.  USB 2.0 will support 480 bits per microsecond, but
I'll believe that it will be commonly available when I see it.  The
intention is to support full motion video as part of the payload, as
the 12MHz rate already supports stereo sound (for those who can't
stand running separate wires to their speakers).  The bandwidth is
shared across all devices and both directions, and given packet
overhead and propagation delays during change of direction, somewhat
less than the full bandwidth is delivered to application data.
Several modes are included offering various levels of bandwidth
reservation (so you can have sound without interruptsions, and the
regular polling of human interface devices (HID)), down to "bulk"
transfers that get the bandwidth that's left over.  Detection of newly
connected devices is supported, as well as high level definitions that
let them identify themselves, by specific manufacturer and model, and
by class, allowing automatic driver selection.  Detection of
disconnection is also supported, and disconnection does not interfere
with other communications (it's not really a bus, but a tree).  The
host hardware interface controller hides all the low level protocol
from the CPU.  Both existing desings present a model where data from
OS designated memory buffers is transfered to devices, and data from
devices shows up in such buffers.  It's not my favorite external I/O
device interface design, but it's becomming ubiquitous.

 > I don't foresee this as a shoestring project, either.  And, no -
 > unfortunately I don't think the target market is likely to be large.
 > Mostly geeks like me going on-site to do troubleshooting, etc.
 > It's not like everybody will want one in their den...

	Unit price is not going to be small then.  I can see hacks to
make the keyboard and mouse jobs easy, by using existing keyboard and
mouse chips and driving the pins that normally connect to the array of
keyswitches, the mouse buttons, and the shaft encoders.  That avoids
the need to develop our own code and hardware to directly speak the
poorly (publicly, at least) documented PS/2 protocols.  That plus one
of the available USB development boards, maybe an extra PIC or SX
microcontroller, and a little bit of assembly code, and you have
keyboard and mouse solved.  (But all this saves you is carrying around
one of those folding keyboards and a mouse.  I carry a mouse anyway
because I don't really like the touchpad on my laptop.)

	The video capture is still a problem.  At a minimum I see an
additional dedicated fast micro controller, three fast sample and hold
A to D converters, a big memory with control circuitry to allow
arbitration between writing by one micro controller and reading by
another, and a very clever time base generator, and that to just be
able to capture one frame per several (5 to 100) frame times.  The
pointer will still lag the mouse significantly.  (Over the USB
interface it might be possible to just send changes, but examining the
pixels is probably dominated by the A to D conversion time, if not by
the best micro controller code you can write to drive them.)

	Flash A to Ds and multiple PALs could keep up better, and
custom ASICs even better.  I'm thinking that you need sales on the
order of 1000 and 10,000 units, respectivly, to justify these two
higher developement models, and the PAL based design would have
relativly high parts, size, and power costs, making the unit price
high.  There would have to be additional applications.  If there are
additional applications for the video half, then there should be
existing commercial hardware to apply, and I haven't heard of it.

	There's an outside chance that if one could do the A to D
conversions in real time, then one might leverage some of the LSI
that's been made for building display adapters, controlling memory
addresses for writing from the raster in the way that they were
intended to control them for reading.  They generate, rather than
respond to, sync signals, so you still need something clever outside
playing with their clocks to get their sync outputs to line up (with
appropriate fixed delay) to those of the incomming signal.  That might
cut the development cost of the PAL scheme slightly.

	USB 2.0 video, if it becomes common for such rack boxes, could
make things more possible, but it isn't there today, in so far as I
know.

							Bill



More information about the gnhlug-discuss mailing list