On Thu, May 26, 2011 at 2:18 PM, David Jackson <djackson...@gmail.com> wrote: > I was not able to find any documentation on a VNC loadable module anywhere. > Is there a place where one can find out about this?
My build was based on these instructions: http://xf4vnc.sourceforge.net/modular.html Pat --- > > On Thu, May 26, 2011 at 7:34 AM, Pat Kane <pekan...@gmail.com> wrote: >> >> I like VNC and have built both loadable module and DDX version. >> >> The main problem with the DDX version is that since VNC >> has a GPL license I can not merge the code into my Xorg >> source tree. >> >> Pat >> --- >> >> >> On Wed, May 25, 2011 at 6:07 PM, David Jackson <djackson...@gmail.com> >> wrote: >> > >> > >> > On Wed, May 25, 2011 at 4:36 PM, Glynn Clements >> > <gl...@gclements.plus.com> >> > wrote: >> >> >> >> David Jackson wrote: >> >> >> >> > 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, >> >> >> >> What sample size does your analysis use? How many different hardware >> >> configurations, and how many different applications? >> >> >> >> x11vnc has the drawback that it's reading a framebuffer which is >> >> typically in video memory, so the data has to be read over the bus. >> >> The speed of this operation may vary significantly depending upon the >> >> hardware being used. It may also vary depending upon the amount of >> >> activity (i.e. if it has to wait for the outstanding rendering >> >> operations to complete before it's allowed to read the framebuffer). >> >> >> >> Xvnc has the advantage that the framebuffer is in system memory. But >> >> this is also a drawback, as it means that all rendering is performed >> >> in software. Try running an application which uses OpenGL to render >> >> detailed scenes; you might want to reconsider your assertion about >> >> Xvnc is fast. >> >> >> >> IOW, it's a case of "choose your poison". x11vnc has fast rendering >> >> but slow export, Xvnc has slow rendering but fast export. A similar >> >> tradeoff exists for X11 verus VNC for remote display. >> >> >> >> > 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. >> >> >> >> Does the VNC driver read the framebuffer on the video card (which >> >> suffers from the same performance issues as x11vnc), or does it >> >> attempt to duplicate the framebuffer by emulating whatever video >> >> hardware is installed? If it's the latter, the application will be >> >> slowed to the speed of the VNC driver's software renderer (which will >> >> be extremely complex, as it will have to mimic every feature which is >> >> available in at least one hardware driver). >> >> >> >> > 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. >> >> >> >> The main "other one" being OpenGL, for which a software implementation >> >> will be much, much slower than a modern GPU. >> >> >> >> > 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. >> >> >> >> To do this at the protocol level requires a completely new protocol >> >> and significant support from the toolkit. The X protocol exposes a >> >> significant amount of implementation detail to the client. Much of >> >> that information is required to remain constant for the lifetime of >> >> the client. >> >> >> >> E.g. if the client queries the list of OpenGL extensions, and starts >> >> using some of them, there's no mechanism by which to inform the client >> >> that an extension is suddenly unavailable, which would be required if >> >> you were to "redirect" the window to a different server with different >> >> hardware. >> >> >> >> Even if such a mechanism existed, it's debatable how many applications >> >> would support it. Reconstructing the current server-side state from >> >> scratch is a lot of work, and toolkits can't always help (e.g. they >> >> won't help reconstruct the server-side OpenGL state, as the toolkit >> >> doesn't get involved in the rendering process). >> >> >> >> > 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. >> >> >> >> AFAICT, there are only two feasible approaches to window "mobility": >> >> >> >> 1. VNC-like framebuffer sharing. The application connects to a >> >> specific X server which performs all rendering. You have the option to >> >> forward rendered images to other systems for physical display. >> >> >> >> 2. Use GUI toolkits which offer an abstract, high-level interface to >> >> the client. The toolkit has the ability reconstruct and clone windows >> >> at will. >> >> >> >> -- >> >> Glynn Clements <gl...@gclements.plus.com> >> >> _______________________________________________ >> >> xorg@lists.freedesktop.org: X.Org support >> >> Archives: http://lists.freedesktop.org/archives/xorg >> >> Info: http://lists.freedesktop.org/mailman/listinfo/xorg >> >> Your subscription address: djackson...@gmail.com >> > >> > >> > x11vnc is noticeably slower. I think the really annoying thing that >> > makes it >> > hard to use is that there is a longer delay when typing for characters >> > to >> > display on the screen than there is with Xvnc. I can notice this. When >> > you >> > are typing characters do display much more quickly to the screen on >> > Xvnc. >> > That is a big issue, because, it is really hard to type when you have a >> > long >> > delay of characters appearing when you type them.Perhaps this is due the >> > polling of the framebuffer. >> > >> > The VNC driver could do its own rendering, get the graphics commands >> > from >> > the application directly. Yes, you are correct that is slow for many >> > complex >> > operations. You are correct, the other alternative is to grab the >> > framebuffer. You are correct it might be faster for those complex >> > graphics. >> > Grabbing the framebuffer inside the X server and feeding it out to VNC >> > clients via a VNC server in the X server, might save a little bit of >> > time by >> > avoiding having to be sent over a socket to another process, but i do >> > not >> > know if that is true. It may be it might do all that being interrupted >> > fewer >> > or no times, where with x11vnc you are gauranteed a task switch and some >> > time for x11vnc to get the CPU. I guess x11vnc asks for the framebuffer >> > over >> > an X connection, then wait for the X server to get the CPU to process >> > the >> > request, then wait again for x11vnc to get CPU and the data to be sent >> > to >> > VNC clients. if we have a framebuffer based VNC driver inside the X >> > server, >> > it may allow for tighter synchronisation and less delay. I cannot say >> > how >> > significant it would be. >> > >> > The other issue mentioned, about the window forward feature. You are >> > correct. I have been thinking about these issues. It would be best for >> > it to >> > be invisible to clients. Ive been thinking about these problems. >> > >> > I am know C, however I know little about X internals or X protocol. Is >> > there >> > a good source of documentation that would give a person a full >> > introduction >> > and overview of how the X server works,including how it all fits >> > together, >> > and a tour of the system and documentation of the internals such as >> > functions, variables etc? Basically everything need for a person who >> > only >> > knows C to learn all about how the X server works? >> > >> > >> > >> > _______________________________________________ >> > xorg@lists.freedesktop.org: X.Org support >> > Archives: http://lists.freedesktop.org/archives/xorg >> > Info: http://lists.freedesktop.org/mailman/listinfo/xorg >> > Your subscription address: pekan...@gmail.com >> > > > _______________________________________________ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com