Actually, the Shared Viz team would like to be able to deliver the TurboVNC functionality otherwise, by adding TurboJPEG to RealVNC or via NX. There's just quite a bit of work to be done to make this happen, since as you noticed the TightVNC and RealVNC code has diverged a lot.
If someone were motivated to try to do this, I would be thrilled. Linda elw at stderr.org wrote: >>> ... how does this affect the chances of getting VirtualGL and TurboVNC >>> cleanly deployed within opensolaris, and later Solaris proper? >> I don't know that it does - getting those added rely on someone wanting >> them enough to do the work. > > :) > >> The primary reason I selected RealVNC was that it builds on the current >> Xorg sources, and don't introduce yet-another-Xserver source base, >> especially not the ancient XFree86 3.3.6 that is missing needed >> extensions for accessibility, JDS, compositing managers, and missing the >> last decade or so worth of security fixes and bug fixes. If one of the >> other Xvnc forks, such as TurboVNC or TightVNC could be similarly built, >> I would see little problem in replacing RealVNC with one of them. > > > I just poked around at the tightvnc source that debian is using. It does > rely on ancient XF86 bits. I expect that updating that would probably be > pretty painful, but a good project for someone with a lot more free time > than I have on hand... > > I took a poke around in the x11vnc sources as well - it seems to have many > much less ancient files inside it than the vanilla tightvnc does. > > --elijah > > _______________________________________________ > xwin-discuss mailing list > xwin-discuss at opensolaris.org -- ------------------------------------------------ Linda Fellingham x49322 Ph:(650)472-9561 Advanced Visualization Group, Sun Microsystems ------------------------------------------------
