Some ideas

[Richard Brown]

Again I apologise about my previous letters.

I do have some other ideas which I think are better conceived and 
thought out, and could be useful to a lot of people. I would like to 
hear what X.org people thinking of these ideas.

1) A VNC server display driver which can be used simultaneously with 
other video drivers to display the same desktop. This driver already 
existed in Xfree86 4. this display driver would take the X server output 
and display it to VNC clients connected to the VNC server. yes, i do 
know of x11vnc external programs. The problem with these things is that 
they are very slow. We i am sure could get far better performance with a 
VNC server inside the X server in a output display driver. This would 
allow for very convenient remote desktop capabilities. I need to and i 
think a lot of people would want to log into their desktops remotely 
into a persistant desktop session. I currently use Xvnc but this has 
weaknesses. It is out of date and does not support recent extensions, 
and it is a seperate X server, i want to export my root desktop and get 
good performance, and have my applications have the benefits of 
displaying to the root display when i am at the local machine, without 
having to go through XVNC and vnc client, but still have the advantage 
of accessing the session through VNC remotely.

I have used x11vnc. it is is slow because it is a seperate program. Xvnc 
is faster as it has a a VNC server built into the X server, but wont 
allow to be export my main display. A vnc driver in X.org itself would 
combine the best of both, having the VNC server in the X server for 
speed and being able to export my main desktop.

This would be extremely useful.

2) Low priority: Dynamic runtime loadable and unloadable drivers. With 
the possibility of hot pluggable devices, has this been considered? May 
also allow certain display outputs, such as the VNC server or even the 
main video card display to be enabled/disabled while keeping the desktop 
session running.


3) Nice to have but not of great priority: Backwards compatibility in 
driver ABI to encourage third party vendors to produce drivers for 
X.org. I do agree that open source drivers are the best when available. 
However this will allow the user to use proprietary driver when there is 
no open source driver available Often it cn be that a vendor can release 
their driver simultaneous to the hardwarebut irt can take months for an 
open source driver to appear. This is a net benefits thing. By 
tolerating vendor drivers we can increase usability and uptake of X so 
that the overall usage of open source software is increased.  The vendor 
drivers can also can be used to back engineer open source drivers.

4) X proxy. THis proxy would allow a X client to connect to the main 
server, however the connection can also be forwarded to another X server 
as well. Perhaps could be implemented in a driver inside X server with 
an API provided by the server to monitor all X events between a certain 
client and the server. Maybe the API exists. X Record? And then events 
from the remote X server would need to be sent back to the X client. 
Xtest perhaps?  The user could then use a command line utility to allow 
the X client to proxied to another X server. Could be used for remote 
desktop to allow the user to forward X clients from their main server to 
remote servers they are using.Could alos be used to allow an X Client to 
be multiplexed and chained between many X servers. The same X client 
could be displayed to many servers at once.

I would like to hear views on this.

 I would like to help contribute to X but do not know the first thing 
about the internals of the X server. Any suggestions on a guide to X 
internals?

Thanks.
Richard Brown