[ANNOUNCE] util-macros 1.14.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This release of the common autoconf macros for X.Org software adds some support to help check for different compilers and enable more code checking features in them. It also reduces warnings generated when autoconf-2.68 is used to generate configure files using the XORG_RAW_CPP macro. Most end-users will not need to install this software - it's only needed to generate or regenerate the autoconf files in X.Org packages, such as when building from a git checkout or from a tarball after patching files such as configure.ac. Alan Coopersmith (5): Create XORG_COMPILER_BRAND macro to centralize compiler checks Make XORG_STRICT_OPTION always set STRICT_CFLAGS XORG_STRICT_OPTION: add -Werror=attributes to STRICT_CFLAGS for gcc Add AC_LANG_DEFINES_PROVIDED to XORG_RAW_CPP to silence autoconf warnings Version bump: 1.14.0 git tag: util-macros-1.14.0 http://xorg.freedesktop.org/archive/individual/util/util-macros-1.14.0.tar.bz2 MD5: 112dac41150d56206aab995bed780d88 SHA1: e9863638cc9119a7b8d77b554de30a99a3611075 http://xorg.freedesktop.org/archive/individual/util/util-macros-1.14.0.tar.gz MD5: cbe57cd7cc492a762466f5280a7ffba8 SHA1: 3d1f0a83bb36aa284a6208928e8729212b292658 - -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (SunOS) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3gXnsACgkQovueCB8tEw5u4wCcCN5cLFipSXS1+3po/n000QFL fzQAnRqrpCcwaBWugbLl5cxqd+xgTc6f =Bb7Q -END PGP SIGNATURE- ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
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.
David Jackson wrote: 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. 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 is the first option, ensure that the new X server will behave exactly like the old one. 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. XMX, Xmux, XTV and SharedX are discussed in A Survey of X Protocol Multiplexors. The only reference I can find to Xshare is a brief description from its author on a page which hasn't been updated since 2001. I'm sure there have been more recent attempts, but none of those seem to have been any more successful. The main reason why these projects never go anywhere is that it's difficult if not impossible to make them work once you stray beyond the core features of the core X11 protocol, and the simplest applications. If you're only dealing with the core protocol, it's not too hard to reasonably approximate the capabilities of one server on all of the others. Having said that, all of the programs described in the above paper had some problems even with the core protocol. But this falls down when you try to handle something like OpenGL, where the client queries the capabilities of the server and adjusts its behaviour accordingly. It's simple enough for a client to use a feature if it's available and avoid it if it isn't. It's a different matter for a proxy/mux/etc to try to forward a connection from a client which is using a feature to a server which doesn't have it (or which has a more limited implementation). It also starts to fall down when you move beyond a single, isolated application to something which integrates with a complex desktop environment. E.g. if client A communicates with client B, do you proxy client B as well, and have each instance of client A communicate with the matching instance of client B, or just have the primary instance of client A communicate with a single instance of client B? Of the four programs in the paper, only Xmux got a strong pass for supporting cut and paste. -- 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.
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.
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.
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
Re: Ideas for X improvement.
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 -- -Alan Coopersmith-alan.coopersm...@oracle.com mailto: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: anto...@nagafix.co.uk ___ 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
[no subject]
http://www.tunamagisterio.uji.es/new.php ___ 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 05/27/11 04:43 PM, David Jackson wrote: 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 current developers have mostly inherited a massive, 25-year old code base. We have been working on improving the documentation, and have made huge improvements, but there is much still to do.There's a documentation sprint being planned for later this year at the time of our annual conference to get a bunch of people together to put together a new developer guide as well. 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. http://wiki.x.org/wiki/Development -- -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.
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: arch...@mail-archive.com
[ANNOUNCE] util-macros 1.14.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This release of the common autoconf macros for X.Org software adds some support to help check for different compilers and enable more code checking features in them. It also reduces warnings generated when autoconf-2.68 is used to generate configure files using the XORG_RAW_CPP macro. Most end-users will not need to install this software - it's only needed to generate or regenerate the autoconf files in X.Org packages, such as when building from a git checkout or from a tarball after patching files such as configure.ac. Alan Coopersmith (5): Create XORG_COMPILER_BRAND macro to centralize compiler checks Make XORG_STRICT_OPTION always set STRICT_CFLAGS XORG_STRICT_OPTION: add -Werror=attributes to STRICT_CFLAGS for gcc Add AC_LANG_DEFINES_PROVIDED to XORG_RAW_CPP to silence autoconf warnings Version bump: 1.14.0 git tag: util-macros-1.14.0 http://xorg.freedesktop.org/archive/individual/util/util-macros-1.14.0.tar.bz2 MD5: 112dac41150d56206aab995bed780d88 SHA1: e9863638cc9119a7b8d77b554de30a99a3611075 http://xorg.freedesktop.org/archive/individual/util/util-macros-1.14.0.tar.gz MD5: cbe57cd7cc492a762466f5280a7ffba8 SHA1: 3d1f0a83bb36aa284a6208928e8729212b292658 - -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (SunOS) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3gXnsACgkQovueCB8tEw5u4wCcCN5cLFipSXS1+3po/n000QFL fzQAnRqrpCcwaBWugbLl5cxqd+xgTc6f =Bb7Q -END PGP SIGNATURE- ___ 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.
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
[ANNOUNCE] resourceproto 1.2.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Version 1.2 of XResource protocol adds two requests: XResQueryClientIds and XResQueryResourceBytes. They can be used for more exactly determining which resources are used by which clients. Support for these requests is planned for integration in the 1.11 X server release cycle. Alän Coopersmith (2): Add missing XFree86 copyright notice to COPYING Distribute install resproto.txt with the release Erkki Seppälä (2): Protocol records for XRes v1.2 Bumped version number: 1.1.1 = 1.2.0 Rami Ylimäki (1): Added protocol description for XRes v1.2 git tag: resourceproto-1.2.0 http://xorg.freedesktop.org/archive/individual/proto/resourceproto-1.2.0.tar.bz2 MD5: cfdb57dae221b71b2703f8e2980eaaf4 SHA1: 9ff9bb9243b0474330959dc3853973523c9dd9ce http://xorg.freedesktop.org/archive/individual/proto/resourceproto-1.2.0.tar.gz MD5: 33091d5358ec32dd7562a1aa225a70aa SHA1: bb13a8fd7292c1118d6959aaebd5d1c8d96b1ea2 - -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (SunOS) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3ge2gACgkQovueCB8tEw4SsgCeM2IO/winIEmokZ2ayu6H+FXn P6UAnjbbKXsPC65HF+uY8/STfORW2h4h =Q1Fy -END PGP SIGNATURE- ___ 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
