swittams "at" cix.compulink.co.uk
Wed, 25 Feb 1998 22:53:48 +0000
VNC is a pretty cool app.
I had some probs with the X version of vncviewer ( seg faults),
but a quick recompile sorted that. I think it was libc6, or something.
I've been thinking about possible new features:
Windows server: this could probably be better done as a graphics
adaptor. (Are the win32 graphics drivers integrated across NT &95 yet? I
don't think so...)This either incorporates (as another thread) or
communicates with a VNC server. It could also pass the GDI commands
along to an existing graphics card driver. This could be selected in an
additional tab on the display properties box. This fake driver would
have to interrogate the real driver in the same way the Win32 GDI does
at present, then pass the information back to the true GDI when it
itself is interrogated for capabilities. The problem with this lies in
the fact that the graphics card may interpret some random graphics call
( e.g. Direct3d stuff) windows makes that the VNC server can't. This
could be handled in two ways : 1. Ignore capabilities of the card that
the VNC server cannot handle - a bit annoying if you have some hugely
powerful 3d accelerator 2. Allow the graphics card to draw the bit of
the screen that it can handle, and steal it in the usual way - probably
and of course headless windows boxes could just have no graphics card
selected in the new tab... though some machines need one to boot...
Protocol: Add an 'observer' mode .... uses ip multicast ( preserve
bandwidth) to display a desktop to multiple viewers. Good for training,
and things like that..
Have a distinct password for observers. The connection response from the
server needs to be different, then if the client is 'observer aware' it
can send an acknowledgement signal, and then not send any more signals
of input to decrease traffic. If the client does not respond as observer
aware, then ignore all input signals from it, and use unicast for it, to
preserve backwards compatibility.
The clients acknowledgement signal should also include the maximal
transfer rate, so it only gets sent what it can handle... would probably
incur a performance penalty on the server, as it would have to handle
more than one multicast group, maybe needing whole screen refreshes more
often than with single bandwidth...
In the distant future: add 3d & sound encodings - in order to port the
whole environment? Both are hard. How would you catch these events? For
sound : maybe another fake driver in win32, and a rerouting /dev/audio |
mixer | dsp in unix (or NAS).... hmmm.