Re: gnome-network

[Havoc Pennington <hp redhat com>]

On Sat, Dec 07, 2002 at 06:13:01PM +1100, Jeff Waugh wrote: 
>   - rfb/rdp client: rfb is the VNC protocol, rdp is the Windows Terminal
>     Services protocol. We already have xvncviewer and rdesktop, so perhaps
>     just a frontend to these would be appropriate. TSClient [1] needs a bit
>     of UI love, but it's a good start for rdesktop.

Nice, I hadn't seen tsclient. Cool. I did some research on how to
write an RFB *server*, so that we can have a "share my desktop now"
feature - I'll append my conclusions. Combined with tsclient that
should give us a pretty sweet feature. (Spamming tsclient author too
;-))

I really like the way tsclient does both rfb and rdp, so many free
software UIs make the mistake of a different frontend for every
backend.

This RFB server project is pretty small, order of 1000 lines of code
to get it working, it will probably grow a bit more than that over
time. Requires some thought, some security awareness, but not rocket
science. So I'm hoping someone will go for it.

It should be integrated with the client, so they use the same
terminology etc.

Both client and server belong in the core GNOME desktop release IMO.

Havoc

First, there are two use cases:

 1. SunRay-style headless X server; you run the server, and
    use it via VNC exclusively. For stateless desktop access
    similar to "screen" with a terminal.

 2. "Share my desktop" with easy GUI, means we need to be able to add
    VNC to any X server without restarting the X server.

Existing software:

 libvncserver: GPL library, includes all the vnc server hard bits.
               I guess based on the original vnc code. you just
               forward it the framebuffer contents and forward from it
               the mouse/keyboard events.

 krfb: KDE client-side VNC server that uses libvncserver and
       thumbnails the screen in a timeout. Also includes the GUI
       pieces. Fairly KDE-specific, uses DCOP for IPC, KConfig, etc.,
       and also contains some extensions to the basic VNC server
       features.

 xf4vnc: a sort of controlled fork of XFree with an XFree86 driver
         that forwards a framebuffer to VNC, for headless usage, and
         an XFree86 loadable module that allows any driver to export
         VNC functionality. The VNC code here is I think based on the
         original VNC code and is similar to the code in libvncserver,
         but does not use libvncserver.

 vnc: Red Hat "vnc" package is an X server based on XFree 3.3.2, so (I
      think?) does not address use case 2, and will also not have any
      of the newer X features such as render. Kind of dead-end-ish
      right? I haven't looked at this closely.

My suggestion is: the main VNC server is on the client side, as with
krfb. It uses libvncserver so doesn't contain much "real" code.
It is basically just a thumbnailer app that pushes the thumbnail 
to libvncserver.

We add minimal hooks to XFree86 to make the client side VNC server
reasonably efficient, and get them into XFree. I believe these hooks
are:

 a) a headless driver that exports the framebuffer via shared memory,
    so the client side VNC server can get at it with zero copies (this
    is the SunRay-type use case). This should make the client side VNC
    server about as efficient as the server side one, or at least
    close enough. 

    The "xvfb" headless X server in XFree CVS already has this shared 
    memory feature ("man xvfb" for details). 

    Two possible work items are:

      - export some way for clients of xvfb to get at the 
        path to the mmap'd framebuffer (probably the 
        xvfb server just sets a property on all root 
        windows)
      - convert xvfb from deprecated framebuffer layer 
        to new framebuffer layer so new extensions work 
        right

    So to run a headless setup you just arrange for xvfb to fire up
    post-authentication, then you connect to it.

 b) an X extension to speed up thumbnailing on normal X servers
    (real hardware drivers, instead of the headless xvfb).
    This is used in the desktop sharing use-case. 

    I did a simple and easy extension called "X-DAMAGE," see xpert
    archives, but keithp wants to do something more complicated.  In
    any case it will probably be in the next XFree release (after 4.3).

    Before the extension goes in, we can poll the screen in a timeout,
    like krfb; that fallback code is needed anyhow. And most of it in
    krfb doesn't look Qt-specific, so could just ask the krfb guy to
    use it.