Re(2): Looking for a hardware version of VNC

[Shawn T. Rutledge]

> Yup, determining what gets sent to the client is the tricky part.

Not that tricky.

> Res-switching would have to be built into the client and/or protocol I

You could do that, yes.  Personally I think PC frame buffers ought to be
fixed-resolution anyway; this project just provides one more good excuse.
All that matters is that text mode is emulated; you can still do it with
high-res fonts.

> guess, unless you predefine a res that any other modes get
> "translated" into by the server before you finally switch to your
> final mode (when the GUI loads, or whatever).

Since you have to have a processor or gate array anyway, just have it do that.
You can either scale the video (tricky), or line-double/triple/quadruple 
and pad any extra space with black.
> 
> > Anyhow the ethernet card would have to be integrated into a video card so 
> > you can always intercept the display and send it across the 'net.  The
> > "boot ROM" on the 'net card would have to try and find an interested
> > client, maybe, so that if your client is already running you will see the
> > whole boot process right from the beginning.  That's backwards from usual
> > VNC architecture.  I'm pretty sure an ISA card can trigger arbitrary
> > interrupts, so it should be able to masquerade as the keyboard or mouse.
> > Not sure about PCI - they have to register what resources they want
> > at startup, and likely the BIOS will say "sorry" if it tries to grab 
> > the keyboard interrupt.
> 
> Don't do that at the bus level.  Stick the keyboard and mouse
> interfaces out the back of your VNC card and just use a short cable to
> go from there to the real keyboard and mouse interfaces already

Yeah you mentioned that already.  It seems klugey.

> present.  Trying to do this entirely at the bus level is bound to
> create problems in certain scenarios and is totally unnecessary except

Maybe but it's also cheaper and more self-contained.  Experimentation 
would determine if it's workable or not.

> Leave that for another NIC of your choice and let the VNC card have
> its own private NIC.  Sure, you'll have two Ethernet cables hanging

egads.  If you only have one NIC, the only issue is can the VNC hardware
share it with the software running on the PC.  I'd think that would be
easy enough.  Anyhow since it is a hardware implementation of VNC, you 
can guarantee that that part will still work regardless what the software 
does.  I think the one NIC might be able to have two IP's anyway (? not 
sure...)  Anyhow the netcard should look "normal" to the OS so you
don't have to modify it.

> tack our VNC server hardware in place of the RAMDAC on the video card
> of your choice.  Keep the RAMDAC if you want a local monitor too.  

As described below...

> The external version would just convert the analog signal from
> whatever display adaptor you have installed in your machine back into
> a digital picture and stick it in some VRAM and you continue from
> there (basically).  The only difference between the external and

Another "if all else fails" solution... kindof like LCD monitors
with analog inputs.  I bet we will see them get a lot cheaper after 
the digital connection has been standardized.

Definitely non-intrusive though.

> internal (card) VNC servers would be the internal version is tacked
> onto the back of some display adaptor, leeching from its VRAM, and no
> digital->analog->digital conversion takes place.
>  
> > You'd need a processor capable of reading from VRAM, diffing that against
> > the last known version (available in its local memory) and sending out the 
> > changes via the ethernet chip.  Actually maybe a PLD would be more appropriate
> > since it's so time-critical.  It'd have to avoid trying to access the same VRAM
> > chip at the same time as the RAMDAC is accessing it.  And you'd have to have
> > double the VRAM (a copy for the RAMDAC plus a last-known copy for doing
> > comparisons).  Err... maybe you could just have the PLD monitor the 
> > VRAM bus, and capture all write operations into a buffer, and send
> > a VNC packet every time a complete hextile-area has been generated or
> > a timer expires, which ever happens first.  That could save all the
> > extra VRAM - you only need enough for one tile not the whole screen.
> > (In addition to the main framebuffer VRAM.)  There would be be a 
> > possibility of the changes happening much faster than the network 
> > permits transmission of the VNC packets, so there would have to be a
> > buffer with outgoing packets, and untransmitted packets could be dropped
> > if they cover the same tile as a newer packet.  What a project.
> 
> <dream>
> Definately a project, but feasable.  I actually envision this as a
> two-chip solution (plus a few discrete components), with one of the
> chips being common to both internal/external versions, especially with
> today's VLSI techniques. :-)
> </dream>

Oh, custom IC's for this too?  Just try to get VC funding for that.  :-)
It'd be the ideal way to implement it though.

---
  _______                      KB7PWD @ KC7Y.AZ.US.NOAM   ecloud "at" bigfoot.com
 (_  | |_)   Shawn T. Rutledge    on the web: http://www.bigfoot.com/~ecloud
 __) | | \__________________________________________________________________

---------------------------------------------------------------------
The VNC mailing list     -   see http://www.orl.co.uk/vnc/intouch.html
---------------------------------------------------------------------