Important capabilities needed

[David Jackson]

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 x.org 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
x.org 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg/attachments/20100921/a067340b/attachment.html>