(I BCC'ed a couple of off-list people on this, so if you're receiving this and you aren't on the mailing list, don't panic.)
I am writing this to solicit feedback from the TurboVNC user community regarding a general strategy for TurboVNC 2.0. Some issues have come to light in recent months that cast doubt upon my ability to continue supporting the latest & greatest Linux releases without a significant upgrade to the TurboVNC X server code base. Specifically, the following problems have been identified: -- Lack of an X Composite extension prevents Gnome 3 and Unity from working. Research shows that X Composite is too deeply-entwined in the X server code base to make it feasible to add that extension on top of the existing code. This prevents the default window manager on many modern Linux distros (including Ubuntu 13 and later, RHEL 7, Arch Linux, etc.) from working with TurboVNC. -- KDE Plasma seems to require XFIXES v5 (needed for the pointer barriers feature.) An earlier version of XFIXES (from Xorg 7.1) drops into the TurboVNC server code easily enough, but it unfortunately is insufficient to make KDE Plasma happy. This problem prevents the mouse from working properly when running KDE Plasma in TurboVNC. KDE Plasma is used in RHEL 7, Arch Linux, Kubuntu, and other recent distros. Unfortunately, the pointer barrier code has some pretty deep ties to the latest Xorg code (Xorg 7.7), and it can't be back-ported cleanly to our existing X server code base (I spent quite a bit of time trying.) -- KDE Plasma also requires a newer version of RANDR than is currently implemented, and as with the new version of XFIXES, X RANDR 1.2 has deep ties to the latest Xorg code and can't be back-ported cleanly into TurboVNC. -- Lack of an X Keyboard extension causes problems with certain applications (VMWare Workstation 10, for instance.) It can also cause key mapping issues with certain Gnome releases (although these are fortunately easy to work around by setting an environment variable.) I spent quite a bit of time trying to integrate the X Keyboard Extension from Xorg 7.1 into the TurboVNC X server, but to no avail. To make it interact with VNC properly is somewhat non-trivial. Most of this came to light in the process of trying to bring up TurboVNC on Arch Linux and RHEL 7 this week, but it also bubbled up in response to a rare but unsolved issue whereby the X socket in Xvnc will mysteriously shut down, leaving the TurboVNC server unable to process X commands (but with the VNC server portion still running.) This might be due to a window manager crash, but after numerous hours of diagnosis on a core file generated from a crashed instance, as well as extensive code review and numerous failed attempts to goad the server into reproducing the failure, I've had to pretty much admit defeat. Granted, this issue occurs very rarely and seems to be caused by one specific app or class of apps, but it's the first X server bug in four years that has left me completely clueless, and it kind of drove home the fact that I've painted myself into a corner with this X server code. What we're running now is a bizarre hybrid of XFree86 3.3.x (from TightVNC 1.3.x), XFree86 4 (from xf4vnc), and Xorg 7.1. I've done things this way in an attempt to maintain the stability of the X server as much as possible while adding necessary extensions. X RENDER was somewhat painful, as it required hacking up the extension code from Xorg 7.1 to allow it to use the older FB and MI libraries from XFree86 3 and 4. Where this pieced into the TightVNC code, I was able to use xf4vnc as a guide, but it can't guide me on other extensions like X Composite. There may be a few simple X extensions that could be added, if they are ever needed, but I don't think it's going to be possible to do anything else major to this X server. The choices are not particularly easy ones, and really they boil down to two options: (1) Do nothing. TurboVNC still works fine with non-compositing WM's like Xfce, and it still works fine on Ubuntu 12 LTS and RHEL 6. Many people are using it in that capacity and will continue to do so for years, but I do feel like it is a huge limitation to not be able to run either KDE or Gnome on the latest platforms (RHEL 7 and Ubuntu 14, in particular.) I feel like that's going to drive people away in the long term, and unfortunately, TigerVNC just isn't as good for 3D apps and may never be. (2) Fork the TigerVNC 1.3.1 server and add the TurboVNC features that it lacks -- but these features, including ALR, multithreaded encoding, and other 3D- and performance-related features, were the result of hundreds of hours of contract work over the last few years. The good news is that it probably won't take nearly as long to port the features as it did to develop them, but it's still a significant undertaking. The bad news is that the companies who sponsored the labor are largely still using older versions of Red Hat and don't really have a need for fixing something that isn't broken (nor do I blame them.) Trying to do any of this work within the bounds of the TigerVNC Project is a non-starter. One of the reasons why I quit that project was because their general development strategy was not focused enough on performance. On at least one occasion, performance regressed significantly because the developers were just trying to beautify the code, and on a couple of other occasions, it regressed because they were tinkering with some parameter and didn't fully test the ramifications. I felt like I was always standing guard over the inner loops, and I never could get across the importance of treating performance as a measure of quality. By virtue of having done this sort of thing for nearly 20 years, I can pretty much instantly tell when a code change will risk a performance regression. Maybe I can't expect everyone to have that ability, but that's why I tend to find it easier to work alone. Further, the other TigerVNC developers rejected the ALR and multithreaded encoding features, which are critical for 3D applications. As we did with the Java viewer, the idea would be basically to take a reasonably stable snapshot of the TigerVNC server code and do whatever work is required to clean it up, speed it up, and add the TurboVNC features. I would wrap it around a known good X.org code base (Xorg 7.7, most likely) and use that as the basis for an all-new X server. I would continue to build the X server in-tree and produce a self-contained Xvnc binary-- I have no interest in trying to support every single X server on every single platform the way TigerVNC does. I want one X server that works everywhere. It used to be possible to accomplish that with the old TurboVNC X server, but unfortunately, the Gnome and KDE developers have not made their latest window manager releases particularly VNC-friendly. Using the TigerVNC code base will help, but even that isn't a panacea. Gnome 3 on RHEL 7 and Unity on Ubuntu 13 won't run in TigerVNC, either, because they now require hardware 3D acceleration. Ultimately, we are now staring down the barrel of needing VirtualGL just to run the frickin' window manager. Apart from compatibility, migrating to a new X server code base will also give me access to additional support infrastructure. If there is an X server bug, I can actually report it to the X.org developers and have some reasonable hope of them reproducing it and maybe even fixing it. Same goes for any odd VNC/X interaction issues that may surface. The latest TigerVNC release has finally reached the level of maturity that TurboVNC had a few years ago when we first started getting some large-scale deployments, so I don't feel like it is so much of a science fair project anymore. I still do feel like the TigerVNC project, in general, lacks sufficient focus on performance, a sufficient eye for ease of use and ease of development, sufficient testing (or sufficient transparency into the testing Cendio does as part of their product releases), sufficient documentation, etc. However, it does have some enterprise-class deployments now, with sufficient numbers of people banging away on it that I can be reasonably confident in its stability. So it makes sense to me to take that code and try to stabilize it further, but it's going to be a painful process. I really need feedback on this, and particularly, if there are any organizations willing to sponsor the move, that would be awesome. I still intend to finish out the TurboVNC 1.3 release regardless. 1.3 will contain a fully working remote desktop resize implementation (the server portion of this is already done anyhow, and the client implementation will be useful regardless.) I have funding to add VeNCrypt support to the server as well, but if we end up forking TigerVNC, it already supports that feature, so it wouldn't make much sense to add it to TurboVNC 1.3. ------------------------------------------------------------------------------ Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft _______________________________________________ TurboVNC-Users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/turbovnc-users
