Re: X Window system on Handheld devices
You are making assumptions, that no company will ever produce a hardware device that has a monochrome screen. Yet, a monochrome screen would be suitable for ereader devices such as a kindle. As for code, memory today is cheap. I've looked closely at X memory useage and it seems from what i can see anyway that X server code consumes less than 10 MB, with all of the compability infrastructure. Maintaining code for compatability and backwards compatability has value greater than saving some kilobytes or a megabyte in the age of hundreds or thousands of megabytes. If a handheld device manufacturer has very limited memory to work with, maybe they could do their own custom compile X, if necessary, without some sections of code. But I am doubtful that will often be the case that this is necessary. But, for a desktop system today, it simply does not make sense whatsoever, the backwards compatability with older X applications is far more valuable. Ive been using X since the days of 90 MB of RAM. X memory usage has never been a big issue, the idea that X, including code for backwards compatability, uses a lot of RAM is an old lie that refuses to die. Blowing up baclwards compatability to save a megabyte or 2 of RAM makes no sense whatsoever. On Sun, Jul 17, 2011 at 2:33 AM, Alan Coopersmith alan.coopersm...@oracle.com wrote: On 07/16/11 06:43 PM, David Jackson wrote: Has the X.org organisation ever thought of promoting X.org for use by companies on thier handheld devices such as phones? You mean like back in the days when Jim Gettys was one of the leaders of handhelds.org and doing research at the Compaq/HP labs on the iPaq? Yes, I think there might have been a bit of thinking, especially when they hosted the X.org Developers Conference there - as hard as it is for some people to believe we ever do any thinking here. Or perhaps you mean the last couple of years, when Nokia's (now Intel's) Meego developers have been one of the major contributors to X.Org. Years ago, in their infinite wisdom, X.org developers removed monochrome support and low colour support, Nope, sadly, both are still there, though I think the mobile developers like those on the Meego project wish we'd dump more code like that which just bloats their embedded systems, since no one wants to browse the web or play Angry Birds on 1, 4, or 8 bit screens. -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ 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
X Window system on Handheld devices
Has the X.org organisation ever thought of promoting X.org for use by companies on thier handheld devices such as phones? X has really missed the boat on this one. Years ago, in their infinite wisdom, X.org developers removed monochrome support and low colour support, things that would have been perfect for many handheld devices such as kindles. There is really no good reason why X cannot be used on handheld devices and it woule encourage more use of a standardized platform like X rather than yet more proprietary systems. Another issue with possible use of X by other companies is the need to provide a device driver facility that supports backwards compatability, that a device driver will continue to work on newer X servers, without being recompiled. That would go for all drivers for all parts of an OS. One thing corporations do not want to do is have to distribute 40 different versions of a device driver and end up with a huge mess where device drivers packaged with older devices no longer work. In relation to Linux and X, the only way to get these systems to be useable for most people is to have hardware companies provide drivers for it, since they can do all of the testing to make sure the driver works well with the hardware. This is the only way to get timely hardware support. Average people dont want to use Linux because of how shoddy the hardware support is. If its anything slightly unusual, it wont work. Some corporations may want to distribute binary drivers, thats just a necessary evil to help get an open source OS more widely used, and as well, eventually open source replacements would still get developed anyway. In fact binary drivers from companies would make Linux more useable to more people, so we would see in increase in user use of Linux, and more opportunities for open source companies to be able to fund open source driver development. Ive been watching Linux for over 10 years and I have seen virtually no progress on the desktop. The big reason it still is not useable is the hardware problems. And the attitude of the Linux community as a whole is the cause of that, the reason why so few people use Linux today, I have to recommend people who want to use Linux to not use it and stay with Windows, because I know what a hassle it is, it really is still hard thing to use because it does not work right with so much hardware out there. And thats due to the attitude of Linux developers who have a knee jerk reaction against 3rd party drivers, when 3rd party drivers could make Linux useable to far more people and actually increase potential to fund Linux development. Both Linux kernel itself and X.org, if they were really serious about making Linux practical to common users, would make it easier for third party drivers to be developed, including better documentation of the APIs so a company does not need to spend a year trying to understand it. ___ 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
Re: Ideas for X improvement.
sorry i was wrong On Sat, May 28, 2011 at 2:35 AM, Evgeny M. Zubok evgeny.zu...@tochka.ruwrote: David Jackson djackson...@gmail.com writes: As far as I know NX is a tunneling and compression technology but will not maintain a persistant X applications or session. The applications are started when you connect from a remote location. NX, along with compression and caching technologies, provides session persistence, desktop sharing and session shadowing. Do you mean that or anything else? Section 4.4 from http://www.nomachine.com/documents/getting-started.php 4.4 Session persistence NX allows you to disconnect a session, either a desktop or a floating-window session, from the remote display, i.e the proxy agent will no longer be connected to any X client. But this doesn't have any implication on your remote applications, which will continue to be running. You will be able to reconnect the session later, even from a different machine. More information about the NX session reconnection policies are available here(link). ___ 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 ___ 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
Re: Ideas for X improvement.
I have recently started running x11vnc on an Xrfb server. This pretty much seems to solve my problems I had with Xvnc. Xvnc did not support render. It appears xrfb does and that konqueror runs fine on Xrfb, it would not run on Xvnc. So now I just run Xrfb and then x11vnc on that, and that gives me the same sort of capability i had with Xvnc. Using x11vnc on Xrfb I have so far noticed no latency problems with typing on the keyboard, characters appear immediately after I type them. All seems to be well. Everything seems to be fast and responsive even when using it remotely. On Sat, May 28, 2011 at 8:02 AM, David Jackson djackson...@gmail.comwrote: sorry i was wrong On Sat, May 28, 2011 at 2:35 AM, Evgeny M. Zubok evgeny.zu...@tochka.ruwrote: David Jackson djackson...@gmail.com writes: As far as I know NX is a tunneling and compression technology but will not maintain a persistant X applications or session. The applications are started when you connect from a remote location. NX, along with compression and caching technologies, provides session persistence, desktop sharing and session shadowing. Do you mean that or anything else? Section 4.4 from http://www.nomachine.com/documents/getting-started.php 4.4 Session persistence NX allows you to disconnect a session, either a desktop or a floating-window session, from the remote display, i.e the proxy agent will no longer be connected to any X client. But this doesn't have any implication on your remote applications, which will continue to be running. You will be able to reconnect the session later, even from a different machine. More information about the NX session reconnection policies are available here(link). ___ 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 ___ 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
Re: Ideas for X improvement.
rootless operation is a big advantage in certain cases. But you are right, it does not forward any vector graphics data, such as GLX commands, which probably are somewhat faster than rasterised data. Currently, i am using xpra and x11vnc on Xvfb. When you use x11vnc on Xvfb, it seems to work much more quickly than it does on the main hardware X server does. I used to use Xvnc but now I use Xvfb and x11vnc, xvnc did not support render, xvfb does. Konqueror does not work without Xrender. So it seems to solve my problems. I tried x11vnc with my hardware xserver and it seemed to have latency with keypresses not displaying to screen quickly. With Xvfb and x11vnc there is no latency problem, it is plenty responsive enough. So I so far am happy with the x11vnc and Xvfb combo. Xvfb does seem to support GLX, and the GLX works over x11vnc. GLXgears runs acceptably over xvfb and x11vnc. Since Xvfb does not use real video hardware, I am guessing it uses Mesa software inside Xvfb rendering of the OpenGL. On Sat, May 28, 2011 at 9:14 AM, Glynn Clements gl...@gclements.plus.comwrote: Alan Coopersmith wrote: http://en.wikipedia.org/wiki/Xpra http://code.google.com/p/partiwm/wiki/xpra This is the VNC approach (render locally, forward raster data), but done on a window-by-window basis using compositing. As such, it suffers from most of the same problems as x11vnc (acceleration requires local video hardware, limited by frambuffer read speed, inter-client communication needs explicit handling, etc). AFAICT, the only advantage is rootless operation. -- 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: arch...@mail-archive.com
Re: Ideas for X improvement.
I meant to say, xvfb. not xrfb. The xvfb and x11vnc combo works great and is better than Xvnc. So far it has fixed my problems with not being able to use konqueror on VNC. On Sat, May 28, 2011 at 8:35 AM, David Jackson djackson...@gmail.comwrote: I have recently started running x11vnc on an Xrfb server. This pretty much seems to solve my problems I had with Xvnc. Xvnc did not support render. It appears xrfb does and that konqueror runs fine on Xrfb, it would not run on Xvnc. So now I just run Xrfb and then x11vnc on that, and that gives me the same sort of capability i had with Xvnc. Using x11vnc on Xrfb I have so far noticed no latency problems with typing on the keyboard, characters appear immediately after I type them. All seems to be well. Everything seems to be fast and responsive even when using it remotely. On Sat, May 28, 2011 at 8:02 AM, David Jackson djackson...@gmail.comwrote: sorry i was wrong On Sat, May 28, 2011 at 2:35 AM, Evgeny M. Zubok evgeny.zu...@tochka.ruwrote: David Jackson djackson...@gmail.com writes: As far as I know NX is a tunneling and compression technology but will not maintain a persistant X applications or session. The applications are started when you connect from a remote location. NX, along with compression and caching technologies, provides session persistence, desktop sharing and session shadowing. Do you mean that or anything else? Section 4.4 from http://www.nomachine.com/documents/getting-started.php 4.4 Session persistence NX allows you to disconnect a session, either a desktop or a floating-window session, from the remote display, i.e the proxy agent will no longer be connected to any X client. But this doesn't have any implication on your remote applications, which will continue to be running. You will be able to reconnect the session later, even from a different machine. More information about the NX session reconnection policies are available here(link). ___ 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 ___ 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
Re: Ideas for X improvement.
The code bases for the X multiplexers/proxies were actually Xmove, Xmx and XTV. Sorry about the confusion. I gave the wrong names. Xmx was developed at brown university. I had tried Xmove before and it works with 16 bit displays but apparently does not work with 24 bit displays. None of them are likely up to date to support Render, etc. The concept of being able to forward one window and its children to be displayed inside another window on another server is an interesting and versatile concept. The idea of these tends to be to keep the xclient connected to the same psuedo/middleman-Xserver, which then opens connections to destination X servers. The psuedo/middleman X server performs manipulations to keep the xclients or the destination xserver from knowing whats going on. The psuedo/middle-man server could be a real server as well, with a special driver for forwarding. On Thu, May 26, 2011 at 2:29 PM, David Jackson djackson...@gmail.comwrote: The client wouldnt have to be moved between servers at all, it could be the same proxy server, the proxy server could then open up connections to actual X servers and forward things to the real X servers. The proxy would massage and rework data as necessary to trick the X client and hide the fact it is being displayed to many X servers and also keep the X servers in the dark about what is really going on as well. This requires no protocol changes and no changes to the clients or servers. There are already two or more codebases that this has already been done on, one is something called Xmux, the other was something called Xshare or something, and I am aware of a possible third that was called XTV. None are actively developed at this time. On Thu, May 26, 2011 at 11:26 AM, Glynn Clements gl...@gclements.plus.com wrote: David Jackson wrote: 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? How a specific implementation works doesn't really matter, as that's something which can be changed. What can't be changed (without breaking compatibility) is the protocol. The relevant documentation can be found here: http://www.x.org/releases/X11R7.6/doc/ The main thing to bear in mind is the client-server model. If you want to migrate a connection to a different X server, you either have to ensure that the new X server will behave exactly like the old one, or make the client adjust to the change. The former is somewhere between ridiculously difficult and completely impossible, while the latter requires significantly changing the protocol, libraries, toolkits, and applications. -- 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: arch...@mail-archive.com
Re: Ideas for X improvement.
Thank you for the information. As I mentioned, I was previously aware of Xmx, Xmove and XTV.. On Fri, May 27, 2011 at 11:44 AM, Alan Coopersmith alan.coopersm...@oracle.com wrote: On 05/26/11 12:29 PM, David Jackson wrote: The client wouldnt have to be moved between servers at all, it could be the same proxy server, the proxy server could then open up connections to actual X servers and forward things to the real X servers. The proxy would massage and rework data as necessary to trick the X client and hide the fact it is being displayed to many X servers and also keep the X servers in the dark about what is really going on as well. This requires no protocol changes and no changes to the clients or servers. There are already two or more codebases that this has already been done on, one is something called Xmux, the other was something called Xshare or something, and I am aware of a possible third that was called XTV. None are actively developed at this time. http://en.wikipedia.org/wiki/Xpra http://code.google.com/p/partiwm/wiki/xpra -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ 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
Re: Ideas for X improvement.
THanks for the info on XPRA. I will give it a try. It looks promising and the way they use the compositing manager sounds genius. It sounds like they get basically final rasterised data from the compositor, so basically it seems like a huge bitmap, if I am correct. Or maybe I am not. If hardware is being used to generate rasterised data from opengl commands, then, i suppose the compositer would need to get rasterised data back from the hardware for individual windows, rather than the whole display. I am guessing that some hardware may not support that but I am not sure. Some hardware i guess just provides a video array for bitmap data and does not take OpenGL commands. I am guessing more advanced hardware takes OpenGL commands and generates rasterised data ready for the screen from them. I suppose depending on hardware design the hardware may allow the programmer to give opengl commands to the graphics card and it renders them to screen, or it may give the programmer the opportunity to rasterise opengl scenes, and instead of hardware displaying them to screen, the programmer get the bitmap back and save them or use them in some way in programs, and then feed the bitmap back to the video card when desired. That way the programmer could render individual windows one at a time, get the bitmap data, then do whatever composite or process need for the windows data, then dump all of the windows bitmaps to the video hardware. It is unlikely the entirety of each window would need to be rasterised as well since some windows may be partially or fully non visible. I have not had the opportunity to study modern video hardware so these are guesses. On Fri, May 27, 2011 at 12:23 PM, David Jackson djackson...@gmail.comwrote: Thank you for the information. As I mentioned, I was previously aware of Xmx, Xmove and XTV.. On Fri, May 27, 2011 at 11:44 AM, Alan Coopersmith alan.coopersm...@oracle.com wrote: On 05/26/11 12:29 PM, David Jackson wrote: The client wouldnt have to be moved between servers at all, it could be the same proxy server, the proxy server could then open up connections to actual X servers and forward things to the real X servers. The proxy would massage and rework data as necessary to trick the X client and hide the fact it is being displayed to many X servers and also keep the X servers in the dark about what is really going on as well. This requires no protocol changes and no changes to the clients or servers. There are already two or more codebases that this has already been done on, one is something called Xmux, the other was something called Xshare or something, and I am aware of a possible third that was called XTV. None are actively developed at this time. http://en.wikipedia.org/wiki/Xpra http://code.google.com/p/partiwm/wiki/xpra -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ 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
Re: Ideas for X improvement.
This advice is valid for all software projects. if you want people to help develop software, document the software code with documentation. Explain how the parts of the software fit together, how the code operates, explain what the different parts do, document functions and variables and what each of those do. Explain the processes involved with several of the code paths, such as the code path followed at startup, and when a message or event is recieved, and so. provide documentation that will allow a person with only a basic understanding of C or Python or other language used to become an expert in the software, without having to do detective work to try to backengineer how the software works. With software, it can take months to figure out how complex software work by looking at source code, with good documentation this can be reduced to days or weeks. The X.org developers should also listen to this advice. in the case of X, this also includes not only documenting fully how the server works and its internals, but also how video hardware works. On Fri, May 27, 2011 at 4:08 PM, Antoine Martin anto...@nagafix.co.ukwrote: On 05/28/2011 12:39 AM, David Jackson wrote: THanks for the info on XPRA. I will give it a try. It looks promising and the way they use the compositing manager sounds genius. It sounds like they get basically final rasterised data from the compositor, so basically it seems like a huge bitmap, if I am correct. Or maybe I am not. I happen to maintain an enhanced xpra (not quite a fork yet). Upstream has not made any releases since 2009, but we do make regular releases, including one today: http://article.gmane.org/gmane.comp.window-managers.parti.general/511 This latest version includes an exciting new feature: bandwidth constrained adaptive JPEG compression (thanks to Arthur Huillet). Although xpra is designed to work with Xvfb, we have done some work to make it easier to run against Xdummy or even a full blown graphics accelerated server. Hopefully, we can take this further. Help is always welcome ;) Cheers Antoine If hardware is being used to generate rasterised data from opengl commands, then, i suppose the compositer would need to get rasterised data back from the hardware for individual windows, rather than the whole display. I am guessing that some hardware may not support that but I am not sure. Some hardware i guess just provides a video array for bitmap data and does not take OpenGL commands. I am guessing more advanced hardware takes OpenGL commands and generates rasterised data ready for the screen from them. I suppose depending on hardware design the hardware may allow the programmer to give opengl commands to the graphics card and it renders them to screen, or it may give the programmer the opportunity to rasterise opengl scenes, and instead of hardware displaying them to screen, the programmer get the bitmap back and save them or use them in some way in programs, and then feed the bitmap back to the video card when desired. That way the programmer could render individual windows one at a time, get the bitmap data, then do whatever composite or process need for the windows data, then dump all of the windows bitmaps to the video hardware. It is unlikely the entirety of each window would need to be rasterised as well since some windows may be partially or fully non visible. I have not had the opportunity to study modern video hardware so these are guesses. On Fri, May 27, 2011 at 12:23 PM, David Jackson djackson...@gmail.com mailto:djackson...@gmail.com wrote: Thank you for the information. As I mentioned, I was previously aware of Xmx, Xmove and XTV.. On Fri, May 27, 2011 at 11:44 AM, Alan Coopersmith alan.coopersm...@oracle.com mailto:alan.coopersm...@oracle.com wrote: On 05/26/11 12:29 PM, David Jackson wrote: The client wouldnt have to be moved between servers at all, it could be the same proxy server, the proxy server could then open up connections to actual X servers and forward things to the real X servers. The proxy would massage and rework data as necessary to trick the X client and hide the fact it is being displayed to many X servers and also keep the X servers in the dark about what is really going on as well. This requires no protocol changes and no changes to the clients or servers. There are already two or more codebases that this has already been done on, one is something called Xmux, the other was something called Xshare or something, and I am aware of a possible third that was called XTV. None are actively developed at this time. http://en.wikipedia.org/wiki/Xpra http://code.google.com/p/partiwm/wiki/xpra
Re: Ideas for X improvement.
As far as I know NX is a tunneling and compression technology but will not maintain a persistant X applications or session. The applications are started when you connect from a remote location. As far as X peristant session, an up to date XVNC that supports Render would probably be fine a On Fri, May 27, 2011 at 7:22 PM, Evgeny M. Zubok evgeny.zu...@tochka.ruwrote: David Jackson djackson...@gmail.com writes: The client wouldnt have to be moved between servers at all, it could be the same proxy server, the proxy server could then open up connections to actual X servers and forward things to the real X servers. The proxy would massage and rework data as necessary to trick the X client and hide the fact it is being displayed to many X servers and also keep the X servers in the dark about what is really going on as well. This requires no protocol changes and no changes to the clients or servers. There are already two or more codebases that this has already been done on, one is something called Xmux, the other was something called Xshare or something, and I am aware of a possible third that was called XTV. None are actively developed at this time. Look also at NoMachine NX technology: http://www.nomachine.com/documents/getting-started.php There are free NX server implementaitions: FreeNX [1] and NeatX [2]. Also look at the project x2go [3]. [1] http://freenx.berlios.de/ [2] http://code.google.com/p/neatx/ [3] http://www.x2go.org/ ___ 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 ___ 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
Re: Ideas for X improvement.
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? 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
Re: Ideas for X improvement.
The client wouldnt have to be moved between servers at all, it could be the same proxy server, the proxy server could then open up connections to actual X servers and forward things to the real X servers. The proxy would massage and rework data as necessary to trick the X client and hide the fact it is being displayed to many X servers and also keep the X servers in the dark about what is really going on as well. This requires no protocol changes and no changes to the clients or servers. There are already two or more codebases that this has already been done on, one is something called Xmux, the other was something called Xshare or something, and I am aware of a possible third that was called XTV. None are actively developed at this time. On Thu, May 26, 2011 at 11:26 AM, Glynn Clements gl...@gclements.plus.comwrote: David Jackson wrote: 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? How a specific implementation works doesn't really matter, as that's something which can be changed. What can't be changed (without breaking compatibility) is the protocol. The relevant documentation can be found here: http://www.x.org/releases/X11R7.6/doc/ The main thing to bear in mind is the client-server model. If you want to migrate a connection to a different X server, you either have to ensure that the new X server will behave exactly like the old one, or make the client adjust to the change. The former is somewhere between ridiculously difficult and completely impossible, while the latter requires significantly changing the protocol, libraries, toolkits, and applications. -- 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: arch...@mail-archive.com
Ideas for X improvement.
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
Re: Ideas for X improvement.
X Server is a complex piece of software and thus there are complex issues involved with its implementation that warrant the message length. I did put most of my concerns in this message so there is not much more I need to add. The message is not that long though, its not a 50 page technical document. On Wed, May 25, 2011 at 3:25 PM, Corbin Simpson mostawesomed...@gmail.comwrote: /me trudges through the rest On Wed, May 25, 2011 at 12:53 PM, David Jackson djackson...@gmail.com wrote: 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. Hey, cool, sounds like you discovered Xrender and Xft. Yay! We already know why Xrender's far more awesome than core rendering. Nobody's disputing that, and our current plan *is* to keep core rendering for protocol compatibility while encouraging application developers to use toolkits which offload rendering and use modern rendering techniques. You also seem to have guessed that backing store is no longer used by the server. Or I think that's what you said; that's a really big wall of text to dig through. 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
Re: Ideas for X improvement.
On Wed, May 25, 2011 at 3:07 PM, Alan Coopersmith alan.coopersm...@oracle.com wrote: On 05/25/11 12:53 PM, David Jackson wrote: X.org needs to listen to users on X Window System flexibility. X.Org does listen, but we don't have developers sitting around with nothing to do, but instead have far more things to work on than people volunteering to work on them. 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. TigerVNC provides a vnc.so loadable module for the X.org server already that does this. Dynamic runtime enabling and disabling, configuration and setup and removal of display output and input drivers while the server runs without server restart. Done for input drivers several years ago. Output drivers is a much harder problem. 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. The core protocol Xlib API has been completely backwards compatible for 24 years now - how much better can we get? (Sorry, the rest was way too long, and given that it's clear you're not even aware what's already being done, I doubt anyone is going to trudge through it all.) -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System Alan, I looked for information on vnc.so on Tightvnc's website. There are no instructions or documentations there on how one would even use it. I suspect it probably wouldnt work at all if it exists, or would be difficult or impossible for a user to get it to work. X.org should ship a driver for VNC server access. This is something that everyone could use. Again, it is important that X be flexible and useable, otherwise its not really useable. Many people need network transparency and may want to have many X servers running, maybe a headless one with only VNC server in it, maybe one with both VNC server and display to hardware. Xvnc is quickly becoming useless. KDE apps no longer really work with it anymore. x11vnc is useless and too slow. Why not add flexibility and options so X is not so limited in how it can be used? ___ 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
Re: Ideas for X improvement.
On Wed, May 25, 2011 at 4:30 PM, Alan Coopersmith alan.coopersm...@oracle.com wrote: On 05/25/11 01:54 PM, David Jackson wrote: I looked for information on vnc.so on Tightvnc's website. Tiger, not Tight, and yes, their website doesn't publish the documentation for their software, complain to them. There are no instructions or documentations there on how one would even use it. I suspect it probably wouldnt work at all if it exists, or would be difficult or impossible for a user to get it to work. Wow, won't even try, just assume it can't possibly work? I wonder why so many Linux distros ship it then - must be mass delusion. X.org should ship a driver for VNC server access. Feel free to write and submit one under a suitable license, keeping in mind that all existing VNC code is GPL, so you'll have to write it from scratch. Meanwhile, the rest of the world will be happily using the existing code that works. Xvnc is quickly becoming useless. KDE apps no longer really work with it anymore. Sounds like you're using an obsolete version of Xvnc. -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System I did download and build tigervnc. No vnc.so anywhere to be seen. None. Nada. Also no documentation or mention of such a thing or how it would be used anywhere in the distribution. x11vnc does not work well. it is markedly slower than Xvnc I have the latest version of Xvnc from RealVNC. I also tried tightvnc Xvnc, it supported even fewer extensions and even fewer applications worked properly on that. Neither works properly. Konqueror fails to run on both. Flash videos have also stopped working. Qt applications are not working. If people are using Xvnc and x11vnc, i dont know how they can tolerate it. ___ 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
Re: Ideas for X improvement.
On Wed, May 25, 2011 at 4:36 PM, Glynn Clements gl...@gclements.plus.comwrote: 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
