dear X.org, Ive used X.org for many years. Being a user of XVNC as well it has become increasingly frustrating that there is no way export the main X.org display by loading some sort of VNC server driver module. x11vnc is too slow. It may also be the case that i will want to run several <a href="http://x.org">x.org</a> servers, and enable and disable output to video card on each and disable and enable VNC output independantly of that as well, and therefore switch which X server environment is currently displaying to the video card too, and run multiple X.org servers at the same time under the same user, displaying to different outputs, and being able to enable or disable outputs without restarting the server. The lack of support for Render in XVNC servers have badly broken some applications already as well. This includes KDE application. The best solution here is to simply have a VNC driver on the main X.org server, and if desired allow to configure multiple different x servers on the same user, for instance if X server is desired that displays only to VNC. It would be a good idea to allow multiple X.org servers run and then dynamically enable and disable display outputs on any single server while the server is still running, and to allow VNC support to be integrated as a display driver output of the main X.org server for best performance and to allow an up to date standalone or video card+VNC server as the user desires with dynamic enable and disable of video card and VNC output. The user can then set up an <a href="http://x.org">x.org</a> server as a VNC only output, and at runtime while the server run change the outputs as desired, adding or removing them. Secondly it it would be very useful to have a feature that would also allow output of an X server to be directed to an output that is an X client connection to another X server, and also allow the display of individual Windows on the X server to a VNC client, and to X client connections on other servers too (while at the same time those windows are being displayed to their native server, or they can be umapped into the background on their own xserver while still being able to be displayed via VNC or X client connections), and to be have output dispay enabled or diabled independantly at runtime to one or more VNC server, one or more X client connections to another X server, or to one or more video cards, and for these to be independantly and dynamically enabled or disabled at runtime, with any number of display outputs, being able to be created for a window or display, including many X client connections, allowing an X client to be multiplexed to many other servers. Mouse and keyboard input from these remote output displays should be able to be enabled and disabled on a per output display basis. Allowing many outputs to be dynamically created and removed, an output of an entire display, or just certain windows, to a backend, including display outputs including video cards, any number of VNC connections, and any number of X client connections, even multiple of each for each display or window to be output, woiuld greatly enhance the useability and flexibility of the system. For instance, display could be output from a single window to a VNC client, for instance, if this is what the user desired, and as well at the same time output a single X window to several X windows on several other X servers. The different ways that this could be useful for are endless. This follows a philosophy of providing mechanisms that enhance and create a highly flexible system, and wouild lead to a far more versatile and flexible system The fact that the Xprint mechanism is no longer avialable simply perplexing and concerning. The xprint mechanism allowed a fast and quick way to print documents and this feature should be restored. There should also be mechanisms to capture keyboard and mouse events into an application and to generate such mouse and keyboard events for an applications, to capture x protocol commands coming from an application and to it, or generate such commands, however, it is also a good idea to allow this functionality to read or generate events for other xclients should be enabled on a per x client basis to prevent security problems, however the user should have the option of a complete enable or disable of this as well, disabling all security, or enabling it, allowing for as fine or course grained security as they desire. X does need a security model that allows security limits to be ablled to xclients on an xclient by xclient basis for accessing resources in other xwindows controlled by other xclients. This is especially important when x clients running under different users are displayed to the same x server. It may be important for some applications for one xclient to intercept or generate input or output events of another Xclient or xwindow. However, there are also situations where this is not wanted. Users should be able to develop a security policy determining which programs should be allowed to do these things, this can include for instance giving one xclient permission to access data of only certain particular other xclients/xwindows. This requires a more fine grained security model. Following a mechanism not policy philosophy, there should be no forced limits on mechaism, but provide the user a mechanism by which they can implement their own fine grained policies. It is important that X.org maintain backwards compatability so that older applications can continue to run properly. It should be a primary goal of X.org to maintain backwards compatability.