The X Window System (commonly referred to as X or X11) is a network-transparent graphical windowing system based on a client/server model. Primarily used on Unix and Unix-like systems such as Linux, versions of X are also available for many other operating systems. Although it was developed in 1984, X is not only still viable but also is in fact the standard environment for Unix windowing systems. This article thoroughly discusses X.
one of the best articles i’ve read in a long time
Good, very good article! Simple and clean.
Maybe a follow-up discussion new features in development and future plans for X?
Thanks for the article. Scanning it, it seems to cover the basics well. What is currently of more interest to me, however, is to gain and understanding of the underlying architecture of X.org’s current X server. For example, there have been some stories here on X.org’s experimental render and composite capabilities. As well, with Jon Smirl’s recent announcement (Stopping Work on EGL and Xgl: http://osnews.com/story.php?news_id=11550), and the myriad of seemily competing and redundant projects relating in some way to linux’s graphical subsystem (ranging from Cairo, to Glitz, to mesa-solo, to Enlightenment’s libraries, DirectFB, and so on), I am both saddened and renewed with interest as to how all these pieces relate to one another and to X.
None of these are really ‘redundant’ except maybe for the enlightenment libraries. And even these aren’t really that redundant as they are likely used on E17 without many libraries from other projects.
My understanding of Xgl (or rather Xegl) is this. It uses the framebuffer to set the graphics mode. On this the stand alone openGL system runs. Glitz is used as the interface layer between this and the Xserver. Cairo also talks directly to this backend, and provides backend independence for applications that make use of it. Meaning that the exact same object on screen that is being drawn by glitz onscreen can be output to a PDF file.
EGL and Xgl were stopped because other frameworks for hardware acceleration of window-management tasks were making more progress and fit better into the X11 architecture and the current X.Org implementation. The ones of particular importance are xcompmgr (allows fancy window effects) XDamages (helps with the window effects) and XRender.
Glitz is a backend for Cairo. Cairo provides a standard interface for toolkits like GTK, then delegates the work to the backend selected by the user. This allows the user to select the backend most suited to their hardward (Glitz would make no sense on a machine without a 3D card). There is no duplication of effort between the two, it’s just a well-designed application stack.
DirectFB was never really a starter. The absence of collaboration between the Cairo/Glitz people and Enlightenment’s Evas people is a bit of a pity, but Enlightenment has always been a rather esoteric choice maintained by a rather esoteric bunch.
Meanwhile Cairo and Glitz are improving steadily, as is X.Org. For KDE fans, Qt has it’s equivalent of Glitz in Qt4’s Arther rendering engine which was released a few months ago.
You’ve nothing to be saddened about, the Linux desktop is making excellent progress, it’s just going to be another six to nine months before it all comes together.
Stopped? Most certainly not! One of the Xgl developers decided to stop, sure.
X on GL is the way forward. E.g., have a look at the “Xgl/Xegl future?” thread at the xorg-ml:
http://lists.freedesktop.org/archives/xorg/2005-August/thread.html#…
Where, amongst others, Owen Taylor chimes in with:
http://lists.freedesktop.org/archives/xorg/2005-August/009356.html
and also gives a link to:
http://mail.gnome.org/archives/gtk-devel-list/2005-June/msg00166.ht…
And those guys seem to be pretty interested and the Avalon scene graph model too.
http://lists.freedesktop.org/archives/xorg/2005-August/009416.html
Thanks Anonymous (IP: 85.224.73.—).
I didn’t know. Now I’m pleased.
PS
I don’t know all the ins and outs, but it seems like xgl, and eventually xgl on mesa-solo will be a huge boon to *nix’es.
That was a decent overview, but does anyone have links to more advanced usage? I was hoping to push some X-Windows clients on Linux out to Windows desktops (using Cygwin or hummingbird), but many of the more useful apps need to save user settings, access file systems, etc. Take for instance evolution. I could give my users access to the evolution mail client, but everytime they go to save or attach files, the file system would be that of the server, and not the client. I imagine I would need to mount all of the user’s directories on the server, but I haven’t seen any how-tos, or best practices from people already doing something like this.
That would be a big help.
You can’t use X11 to have a program running on a remote machine, but displaying on your local machine, save files on your local machine.
It’s important not to lose sight of the fact that the program is running on the remote machine, all that’s happening is that the display (and nothing else) is being re-routed onto a different machine. Allowing access from the remote machine (which is presumably a server) to your local machine (a client) doesn’t make sense.
In Unix setups this isn’t an issue, as the virtual file-system created by mounting and especially NFS blurs this distinction (as your home directory, which appears to be on your local machine, is really on the remote one). You’re best bet would be to duplicate this: using Samba on the remote machine to make a file-system available to your users on the local machine, and set it up so their “My Documents” folder is stored on that remote file-system. There’s more on folder redirection in this article: http://www.windowsdevcenter.com/pub/a/windows/2004/08/24/folder_red…
Thanks Bryan.
I am aware of the realities of where the applicatoin is running. I guess I was looking for a competitor to Citrix and hoping there was a decent way of duplicating that functionality using X. I experimented with using the NFS server in Microsoft’s SFU or mounting the directories using Samba, but neither support the necessary ACLs required by our business.
Cheers
NFSv4 supports ACLs very well, and this is taken care of on the server side, not on the client side. To mount the remote filesystems on Windows clients, you need an NFS client, not a server, and I don’t think it matters if it’s MS’s NFS client or otherwise.
Samba, however, is not robust enough for your application. I’m not sure if this is a limitation of the SMB protocol (and therefore a problem for Windows SMB servers also) or just a limitation of the FOSS Samba server.
I can’t wait for an enterprise-class solution based on Coda, the distributed network filesystem developed at my alma mater, Carnegie Mellon University. It still has some ways to go, but isn’t it an awesome prospect to have a truly next-gen distributed filesystem developing under the GPL?
I guess I was looking for a competitor to Citrix and hoping there was a decent way of duplicating that functionality using X
I think the NoMachine NX technology can be of help here. As far as I know it can forward additional protocols through its own connection, for printinf and local device access.
NoMachine ( http://nomachine.com ) has just what you are looking for. Their NX server performs at least as well as ICA/RDP over a LAN and better than either over a low bandwidth connection. The client handles X as well as audio and shares the local file system and printers of the machine running the client so your users can save files to their local hard disk/usb key and print to their own printers. Both whole desktops and individual apps can be published to NX clients.
Additionally, the NX server can be used to proxy ICA and RDP connections so that NX clients can access X, ICA, and RDP published apps.
NoMachine’s server products are very, very reasonably priced when compared to WinTS, and especially Citrix. Their NX client is free and available on Linux, Windows, and OS X.
If you’re looking to go the FOSS route, the underlying libraries used by NoMachine are gpl’ed and have been assembled into a working stack by the FreeNX project ( http://freenx.berlios.de ).
X is most useful when used to display a graphical environment remotely on terminals, but I would have thought that it would have been scrapped long ago for use on what are essentially single-user home desktops… instead of applying hacks to squeeze performance out of a system not designed for it.
I have been wondering this myself. X has some great features, and for general use stuff works fine. But I’m surprised, that with some of it’s performance limitations, it has be sidelined.
I meant “has not been sidelined.”
Perhaps this is because it doesn’t have any performance limitations. There was an article posted a year or so ago where someone did some in-depth profiling of the Unix display stack (from kernel-to-X11-to-Toolkit-to-Application) and found that most of the trouble was due to the toolkits not using X11 to the best of it’s abilities. X11 was actually doing pretty well.
Really, in this day and age, the idea that a loopback network device could be so poorly implemented that it would visibly slow down GUI performance is a bit silly. X11 performs perfectly well. The standard protocol performs less well on low-bandwidth network links, but NX fixes that.
Further, those problems that do remain are being actively worked on. For example the XDamages extension I mentioned in a previous comment allows X11 to determine exactly what part of an application needs to be re-drawn and what doesn’t, giving the appearance of improved app-redraw by reducing it. Likewise work is going into XRender and other extensions to offer more opportunities to toolkit vendors to improve their offerings. Qt’s work on Arther and GTKs planned Cairo transition are just one way in which the toolkits will raise to that challenge.
It’s the toolkits, more than X11, that need work for everyday performance. X11 is fine. The work that’s being done now on X11 is primarily for eye-candy.
Hi Bryan,
Do you have any more information on the article and/or author? What you are saying makes sense. I would be interested to do more reading on the subject.
thanks,
~Matt
I tried looking last night for the reference, and I tried looking again this morning (Irish time) but I couldn’t find the original article.
I did find a separate reference though, in this OSNews.com interview with Jim Gettys
http://www.osnews.com/story.php?news_id=5215&page=3
Here’s a quote
Rayiner Hashem: Will they have to change to better take advantage of the performance characteristics of the new design? In particular, should things like double-buffering be removed?
Jim Gettys: If we provide some way for toolkits to mark stable points in their display, it may be less necessary for applications to ask explicitly for double buffering. We’re still exploring this area.
But current Qt and GTK, and Mozilla toolkits need some serious tuning independent of the X server implementation. See our USENIX paper found here. Some of the worst problems have been fixed since this work was done last spring, but there is much more to do.
The USENIX paper can be found at http://keithp.com/~keithp/talks/usenix2003/
Among it’s conclusions, the mentioned that
while behavior is generally similar, there are major differences observed between toolkits.
Sorry I can’t do any better.
Plus, some stuff between a local X server and client doesn’t need to go over a socket. Xorg, and all X servers in the last decade, have the Xshm extension where images can be transferred through shared memory. There is also Xv which allows reading and writing video to the screen or video devices.
On Linux, the DRI allows OpenGL direct access to the hardware. All of these speed up the things which need to be fast, like images, video, and 3D, while keeping the flexibility of the X11 protocol.
Every once in a while someone posts an article
on X and there is considerable discussion on why
anyone would use X when clearly a “native” windowing
manager would be more efficient for local display.
It turns out though, that X really isn’t that slow when rendering a window for an application on your machine on your display. In unix there are 3 kinds of sockets you can use for connections (tcp/ip, udp, and unix domain sockets). When you access machine B from machine A and launch a program on machine B to display back on machine A, you’re using tcp/ip sockets to pass the X window data back and forth.
When you’re on machine A and launch an application that displays on X, you’re using unix domain sockets
to communicate between the X server on A with the X client on A.
It turns out that the unix domain sockets are incredibly lightweight, so you’re not hurting performance wise by using a server+client on the same machine. That’s why for example, you can actually
render decent OpenGL applications on a Unix box (so long as it has the OpenGL drivers to talk to the graphics card.)
As an experiment, try out for yourself the following
on a Unix box with accelerated 3d:
a) Run glxgears directly on your machine. See how many frames per second you’re getting.
b) Open a terminal, ssh from your machine to your machine (use the ip address, not the local loopback
address 127.0.0.1). Now run glxgears in this ssh’d
session from your machine to itself. How many frames
per second are you now seeing? (This — in spite
of the fact that the client and server are on the same machine, but in case b) you’re using a tcp/ip
connection instead of a unix domain socket.)
The point I’m trying to make is that X really isn’t inferior to the other window display systems (Microsoft’s and Apple’s) in terms of frames per second, and is actually superior in terms of remote display viewing. (I’m including technologies like
VNC and remote desktop protocol — these are inferior
in the sense that there is only 1 display on machine B, and that displaying back from machine B you’re not getting you’re own “individual” display but getting the same display anyone else displaying back from B would get, unlike X where you really are displaying
your own personalized view.
–Johnny
I’m including technologies like
VNC and remote desktop protocol — these are inferior
in the sense that there is only 1 display on machine B, and that displaying back from machine B you’re not getting you’re own “individual” display but getting the same display anyone else displaying back from B would get, unlike X where you really are displaying
your own personalized view.
That’s not really true of RDP. While the workstation version will only allow one [unique] session at a time, the server version (in either Windows Terminal Server or Citrix form) does allow multiple individual displays. In fact, after using X forwarding for so long, I was surprised at just how well RDP/Citrix/TS worked — performance is very good even when you’re halfway around the world from the server (and even when you’re using a Mac or *nix/X11-based client). Oddly, though, there’s always a small touch of lag, even when you’re RDPing to a server in the same room.
X, however, seems to work better (i.e., with less lag) when you’re in the same building (where it’s tremendously quick). But when I was using forwarded X sessions just across campus at Purdue I would find the lag mostly unbearable.
I haven’t used VNC or Apple’s technology enough to comment on performance.
X, however, seems to work better (i.e., with less lag) when you’re in the same building (where it’s tremendously quick). But when I was using forwarded X sessions just across campus at Purdue I would find the lag mostly unbearable.
Have you tried NX/FreeNX?
It’s not just about frames per second, what about responsiveness? Can a monothreaded server like X ever be responsive?
What about hardware configuration, when will X be able to properly detect and configure even the most basic hardware like my mouse or even my PnP Monitor display modes without me having to edit xorg.conf?
X already does autodetection to some degree if you don’t provide an xorg.conf file.
Otherwise, for custom configurations, this isn’t an Xorg job–the detection should be done by say, hald, and a userspace tool should make changes to the Xorg configuration.
In the end, we’ll have a flexible system where things can be specified directly in an xorg.conf if necessary, or things will be autodetected for those who don’t want to deal with the conf file. (Meanwhile, with this design you won’t run into “detection hell” as often occurs in Windows, where your only resort is to download tools like Driver Cleaner Pro or wipe out the registry hive for the HAL, and try to “beat” the autodetection scheme).
Actually you can have a VNC setup that creates a new display with each connection, and futher have this display start out at a login screen. It’s pretty simple actually with xinetd.
but I would have thought that it would have been scrapped long ago for use on what are essentially single-user home desktops… instead of applying hacks to squeeze performance out of a system not designed for it.
this criticism is bantered about on a pretty frequent basis, but the fact of the matter is that X really isn’t that slow…it’s the toolkits, window managers, and assorted applications on top of it.
Well… perhaps a “yes and no”. Nothing wrong with X per se but have a look at http://wiki.x.org/wiki/XorgPerformance .
X is most useful when used to display a graphical environment remotely on terminals, but I would have thought that it would have been scrapped long ago for use on what are essentially single-user home desktops… instead of applying hacks to squeeze performance out of a system not designed for it.
Well, isn’t ‘remote graphical environments’ what most ‘single-user home desktops’ are turning into?
X is most useful when used to display a graphical environment remotely on terminals, but I would have thought that it would have been scrapped long ago for use on what are essentially single-user home desktops… instead of applying hacks to squeeze performance out of a system not designed for it.
It is true that X was designed from the beginning with networks in mind, but why should this leave it out of the running for a desktop environment? Is there anything else available for UNIX that provides the same functionality or application support?
http://www.art.net/~hopkins/Don/lang/NeWS.html
“NeWS is the Network extensible Window System, written by James Gosling and David Rosenthal, at Sun. It’s a multithreaded PostScript interpreter with extensions to draw on the screen, handle input events, with an object oriented programming facility.”
Sort of a VHS verses Beta.
X drivers still are still buggy. We need to find a way to sue these manufacturers to open the specifications on their chips. The way they are doing business now is unacceptable because they are part of the WinMonopoly.
X drivers still are still buggy. We need to find a way to sue these manufacturers to open the specifications on their chips. The way they are doing business now is unacceptable because they are part of the WinMonopoly.
There’s a more realistic way. Support those vendors that do provide linux drivers and choose to buy their products. The vendors will only invest in development when they see a potential market, and don’t expect them to open their APIs anytime soon.
Didn’t Microsoft get sued ? Shouldn’t I get specs on hardware of something if it breaks or I choose to use another OS ? And the only reason they choose Microsoft is because it’s a monopoly. They should be gently directed to provide their specs.
“Shouldn’t I get specs on hardware of something if it breaks or I choose to use another OS ?”
No.
“And the only reason they choose Microsoft is because it’s a monopoly.”
Uh, huh. Like “that’s were the money is” didn’t have anything to do with it.
“They should be gently directed to provide their specs.”
Gentle’s fine. It’s when you start telling them how to run their business, that’s when the problems start.
We need to be able to reverse engineer windows drivers and X drivers so that DirectFb or other alternatives have a chance. I heard it’s a real bitch to reverse engineer these windows drivers. We need software that can help out.
Wrappers around window drivers ?
That’s got to be the biggest joke of the week.
X is a horrible patchwork in sore need of replacement by something modern and well designed.
Maybe the word you’re groping for there is, “modular”. Good designs are timeless and X is one that has been much imitated but never surpassed, outlived many os versions and just gets better with every fork.
I’m not familiar with the code. Could elaborate on why you think it’s a “horrible patchwork”?
By what I’ve read about the design it seems rather well designed. Why would you say that it needs to be redesigned?
X Windows predates MS Windows!
Gee, I guess if you can’t be original, you just copy from others.. oh, wait, but that’s what’s been happening ALL ALONG!
closed source = closed minds
“X Windows predates MS Windows!”
There’s many other things that predate MS Windows. As soon as technology allowed for the copying and distribution of software (magnetic tapes), this distribution took place under licenses/agreements that more-or-less resemble the modern open source definition. It wasn’t until computer platforms developed some standardization that closed source, binary software distribution became practical. Ironically (I guess), open standards at the hardware level made closed source software possible.
Bottom line: open source predates closed source!
mod down parent
Unfortunately the O’Reilly X Window series is no longer in print such as:
http://www.oreilly.com/catalog/v3/
http://www.oreilly.com/catalog/v8/
However, there is this book which is still in print:
http://www.oreilly.com/catalog/v3m/toc.html
I have Volume Threee and Eight (X Window System Users and Administrators Guides). These books got me through several window managers (twm, fvwm, olvwm) when I was working with Linux “back in the day”. The article reminded me of the “good old days” of configuring X by hand to get it to work.
I think you should make a series out of this. Other exciting entries could be: What is Linux? What is internet?
What I want when I visit a website that is ‘exploring the future of computing’ is really a collection of articles about random computer related things pooled from all over internet. del.icio.us, slashdot, etc just don’t link the same way you do.
Sorry about bring up Linux (on the desktop) but I always felt that X was keeping Linux from being successful on the desktop. There’s latency issues of having to communicate graphics over a network protocol on a native system. The example I use is that Mac OsX doesn’t use X and its desktop doesn’t seem to have perfomance issues as most Linux distros do.
The biggest advantage of X is that it allows X apps to be run remotely with a small performance hit compared to say using something like VNC or remote desktop to run an application.
I had to revert to using an older XFree86 when I installed Vector Linux. I had a problem trying to configure my Radeon 7200 using Xorg, just couldn’t get the desktop to fill the screen.
Sorry about bring up Linux (on the desktop) but I always felt that X was keeping Linux from being successful on the desktop. There’s latency issues of having to communicate graphics over a network protocol on a native system. The example I use is that Mac OsX doesn’t use X and its desktop doesn’t seem to have perfomance issues as most Linux distros do.
I think the bigger difference is that OSX has vendor support by way of proprietary drivers rather than reverse-engineered ones.
My linux desktop (actually, laptop) with nVidia’s own driver performs just as well as XP, no performance lag that I can see (and I’m running on 3 year old hardware). I don’t have OSX but have seen it in action, and again I can’t see that big a difference in performance. Not that I do heavy graphics editing or gaming mind you, just day to day use.
But I have seen linux desktops running native X drivers on less-well supported hardware and can understand your point. Still, I don’t think the issue is necessarily inherent to X.
But I have seen linux desktops running native X drivers on less-well supported hardware and can understand your point. Still, I don’t think the issue is necessarily inherent to X.
The lack of vendor support or poor vendor support will always be a problem for an alternative Operating System like linux.
But the only real issue I have with X is slow xcompmgr support right now. I want all those neat compositing tricks with speed.
The other issue is smoothness in the movement of windows X no matter what light window manager you use can seem a bit herky jerky in comparison to say OS X on a system with lots of RAM or XP.
The rest of the “performance” issues are pretty easily contributed to window managers and the desktop environments and finally the widget class.
It have said for a while it was high time to lock the X.org folks in a room with the GTK, XUL, QT people along with Window Manager reps and not let any of them out till they can come out with some serious performance improvements.
Oh yes, please do not fall back on the more features have to be slower performance stuff.
It is true only to a point and memory leaks are still memory leaks and please FIXME sections have to do with performance issues still need to be fixed.
Different strokes for different folks, I guess. I already have more eye candy on my desktop than I really like. Beyond the animation when I minimize a window, I find it distracting. Well, antialiased fonts are nice.
But transarency? Menu’s that fade in and out? Drop shadows? Please! Just let me get my work done, thank you!
But, a lot of people do like the eye candy and that’s fine by me. So, in consideration of the fact that the Universe does not revolve around me, X needs to do eye candy well.
When you get right down to it, X is a solid, highly extensible design. As has been pointed out, Unix sockets are quite light-weight and fast. XShm works well when the server and client are on the same machine, as does DRI. The network transparency is light-weight and can get completely out of the way when you don’t need it. The single-threaded design is a problem in theory, but in actual practice, I don’t notice it. X has shortcomings, but they are in the extant implementations and not the design.
There is no need to throw the baby out with the bath water.
I think that many of the complaints that people have about X stem from the fact that development stagnated for so long, thanks to David Dawes. Now that X.org is in the spotlight, I’d guess that in a year or two most of the valid complaints will be addressed. There will always be a contigent condemning X simply because it was designed a long time ago, and advocating that it be replaced by “fill in the blank”.
But any pretender to X’s throne needs to do everything that X does, plus have demonstrable advantages. Meanwhile, X, now freed from XFree’s shackles, is a moving target. X already has some impressive capabilities, and X has great potential. And now it has momentum, as well.
So I agree that any existing problems are fixable.
I also agree with your idea of locking all the developers in a room. In particular, the XUL guys. As I mentioned in a previous post, Mozilla Foundation apps are probably the #1 reason for people perceiving X as being slow.
Are there window systems alternatives to X Protocol for open systems (Linux/FreeBSD)?
Personally I dislike X family. Y like Mac OS X window system but is a propietary technology.
Open a firefow window, open http://www.osnews.com, move the windows down the right corner. Now drag the windows upp from that corner. What u get? A smearing effekt where all the graphics that was hidden is smeard all over the place. X is perfect. Think not.
> Open a firefow window, open http://www.osnews.com, move the
> windows down the right corner. Now drag the windows upp
> from that corner.
> What u get?
I don’t get any “smearing effekt”. Everything works fine with Xorg + GNOME here. Yes, X is perfect.
I do not get any smearing.
But I do know what you are talking about. On slower hardware, if you move a window that happens to have a Firefox/Mozilla/Thunderbird window in the background you can see it.
Now try the same thing with *any* application that is *not* Firefox, Mozilla, or Thunderbird. Then complain to the Mozilla guys.
In practical terms, though, I have no problem with X’s performance. I run about 20 users running 1.2 – 1.6 ghz durons with cheap on board video, running as X terminals across a 100mbit LAN, all running off of a 1266Mhz PIII server. The X terminals are running with the VESA driver to keep things standardized. I have never once gotten a complaint about the speed of screen updates. Though these same users do complain of OO.org’s startup time.
I have 9 more users at another location down in Dallas running off the same server via DSL and using NX. They felt that VNC was slow, but love the speed of NX. Since the switch to NX, I’ve had no complaints.
I would say that these represent “worst case” scenarios.
Of course, there are applications where performance is everything. For example, Doom3. A split second of latency can mean the difference between life and death. On my own home machine, I play at the “High Quality” setting with resolution set to 1600×1200, 4x 9-tap gaussian FSAA, and full anisotropic filtering, and rarely fall below 25 fps.
This is the sort of informative article that I love
Anyone post this view on it yet?
http://www.art.net/~hopkins/Don/unix-haters/x-windows/disaster.html
It’s a amazingly ignorant and malicious article, or chapter for that matter, although I found some parts very amusing and witty in a satirical sense.
X11 has room for improvements and so its open source implementations, but this article fails to cover them. Comparasions with other windowing implementations are left without any arguments on technical aspects. In a nut shell it’s a pure troll!
Just look at its title: “The X-Windows Disaster” It is X-Window system, not X-WindowS! I mean, if you are about to criticise someone or something you can at least learn his/her/its name, for the sake of politeness.
And even worse:
In all other client/server relationships, the server is the remote machine that runs the application (i.e., the server provides services, such as database service or computational service). For some perverse reason that’s better left to the imagination, X insists on calling the program running on the remote machine “the client.” This program displays its windows on the “window server.”
I do realize that this could be somewhat confusing but X-server provides drawing services to remote applications, therefore it is a server on a local machine.
Every physics/biology/medical and computer science discipline recognises and distinguishes structural and functional division.
This speaks a lot about author.
how I can get this window for my computer?