X.org needs to listen to users on X Window System flexibility. X has always been about mechanism, not policy, that allows users choice and flexibility, such as in window manangers. Many people I talk to, including myself, find remote desktop capabilities extremly useful and greatly increase the useability of the X Window System. Network transparency, backwards and forward compatability are all vital features X.org needs to maintain a commitment to. I urge the X window system to increase flexibility and provide mechanisms that allow people to use X Window System as they want, to implement the following features. A display driver that contains a VNC server. The problem with x11vnc is that it is slow, very slow. XVnc server, which is a X server that contains a VNC server but has no hardware drivers, is much faster since the VNC server is built directly into the X server, however this does not allow one to export their main X display which is also displayed directly to video hardware. The solution here is to include a driver in the X.org main server distribution for a VNC server that can be loaded into the X server. The VNC server driver should be able to be dynamically loaded while the server is running and the output of the server displayed simultaneously to VNC clients and to the local video hardware. This can be controlled from provided command line and GUI utilities. One of the very severe problems I have been having is that Xvnc does not support Render extensions, and many applications no longer work without the Render extension. VNC driver with X.org therefore must support the Render extension and other ones. Dynamic runtime enabling and disabling, configuration and setup and removal of display output and input drivers while the server runs without server restart. this allows for instance, the user to have the X server display to a new target while the server runs, or display to many different display outputs at the same time This includes the VNC Server driver above, this allows a person to easily swtich the VNC on and off from displaying to certain outputs, such as they could turn off display to the local monitor and then turn it back on again, or turn on and off VNC display. Another feature that increases flexibility to the user would be to allow the user to direct display of a certain window or the entire root window and display over an X client connection to another server, or any number of other servers. This would also forward the windows children who would also be displayed on the remote server inside the parent window. The forwarded window could be displayed at any location inside of any window on the remote server. This allows, for instance, the user when they are using an X server away from home, to direct applications running on their home X server to also be displayed simultaneously on their remote X server. This also allows windows and displays to be multiplexed, displayed to multiple X servers at the same time. The Window could also be unmapped or minimised on one server while being displayed on another server. There is flexibility that comes from a mechanism, not policy approach here, such as chaining a series of servers to together through daisy chain sharing of certain windows. This whole thing would likely work by an expose event on the servers being propogated back through the servers to the original application, and X protocol. GLX and other X commands being forwarded from one server to another. Many users, including myself, want to have many X servers running at the same time and then at run time be able to change to where these servers are being displayed, and as well when an app is started, to which server it is displayed with the -display option. Each server must be allowed to have a different configuration, including different driver configurations and display configurations, and input device configurations. Users must be allowed to have headless and VNC only servers. While improving and enhancing programming facilities availaible to developers and enhancing features and flexibility to users, X.org needs to commit to full backwards compatability with the X11 protocol and the extensions to it, including binary compatable at the protocol level and backwards compatability at the xlib API level. Backwards compatability is always a must. It has become clear that X graphics primatives today are outgrown today by some applications today which have intense graphics needs. Current X protocol must continue to be supported however new mechanisms can always be offered. The solution to this that provides the most flexibility for users is for the X Window System to provide more advanced and more diversity of vector graphics rendering facility over the X protocol, and that is already being done to an extent with GLX. The X Window System xlib, xcb, glx libraries and so on provide access to these features. The reason for this is that it applications should be encouraged to offload as much graphics operations and processing to the X provided library APIs as possible and do as little of that as possible in the applications own code or in 3rd party toolkits. It should be recommended that applications avoid in application and 3rd party toolkits rasterisation and rendering as much as they can. This means that more data is being sent as higher level vectors which use less bandwidth over the wire rather than the application sending bitmaps it has created in application code and 3rd party driver code. That increases flexibility when display an application remotely and locally, and also allows as much vector and 3D graphics processing to be done by the video card as possible. Another feature that can speed up and increase flexibility of displaying locally or remotely is allowing the application to upload a frequently used bitmap once and storing it in the server, adn referring to it later on with a token. The application can delete the bitmap when no longer needed, and if the user sets a limit to X server memory usage, the X server could delete long unused bitmaps and ask for the bitmap again if the application uses the token for it. The user could also completely disable this in which the server will ask for the bitmap (or just the damaged region) with each redraw. This concept could also be used for vector graphics as well or any other data the client sends to the server. By avoiding placing low level graphics rasterisations in applications own code or 3rd party libraries and having apps use X window system provided libraries for that whenever possible, it makes it more flexible to use applications over different mediums and display targets. It works well for both local desktop display and remote display. the above plan preserves the ability to do both network transparent display, direct rendering, and also preserves the ability to do rasterisation in the server, in the application, or in the hardware. This is due to the fact that applications should use Xlib, XCB, and GLX libraries API for rendering provided by the X Window System. The Xlib libraries can then according to a users runtime selection, send graphics it recieves over X protocol to a remote X server, or do direct rendering one of two ways: rasterise the graphics in application into bitmaps to send directly to video hardware, or send the vector graohics commands directly to video hardware. The applications still have an X socket connection to the server in the case of direct rendering, the server can still coordinate things. The rasterisation in the X server as well can either utilise its own rasterisation facilities in server or send the vector commands to video hardware to be rasterised there. and quite a bit of that is done already with GLX. Alpha transparency, blurring and antialiasing are common features needed by many apps, and an application needs these as well as complex vector graphics provided by further expanded GLX capabilities. The user can then select at runtime the target the aplication should display to, with the -display flag to select their X server. if the X server supports direct rendering, it will notify the X client of this over the X connection, then the graphics API calls from the application to xlib can be sent directly to video hardware. The X server can manage and coordinate. Both remote X socket apps and direct rendered apps could co-exist on the display.