Two comments on my last blog entry asked questions that I thought should be answered in a new entry so that it would be seen by more people, since I expect many people will want to know the answers.
And, in an area that concernes you more directly, whare is the current plan at Sun with those new versions? Will 6.9 or 7.0 make it in Solaris 10 at some point, or will it wait for Solaris 11?
One of the reasons we (X.Org) are doing 6.9 and 7.0 from the same codebase is to allow distributors to move quickly to 6.9, dropping it in their existing build and package setups as a replacement for 6.8.2. They can thus get the new hardware support, bug fixes, and features out to their users with 6.9, and work on migrating their build systems and packaging to 7.0 at their own pace, without worrying about holding their users behind. Hopefully, by the time 7.1 comes out approximately 6 months after 7.0, most distributors will be ready to adopt it.
So for Solaris, we (Sun) will probably take advantage of this, integrating 6.9 into our builds for Solaris Nevada (the development branch for the next full release of Solaris), and then once it's had some "soak time" there to shake out any issues, will backport that into the next available Solaris 10 Update Release (which will also involve building patches for earlier Solaris 10 releases, as you can see today with the patches to upgrade Solaris 10 from Xorg 6.8.0 to 6.8.2 which we produced in order to include 6.8.2 in Solaris 10 Update 1). It's too early to say exactly which update release that will happen in, as it depends on various schedules and priorities that aren't fully set yet.
Once that's in place, then we'll look at moving to the 7.0 build system. I'm tempted to use this migration as an opportunity to also move our customized build and packaging systems for X in Solaris to one more like those used in other Solaris consolidations such as the OS/Networking sources already released via OpenSolaris, or possibly to the RPM-inspired pkgbuild used by Sun's Java Desktop System teams, to reduce the number of build/packaging systems that people need to learn.
Andrew Watkins posted:
I am wondering what Sun will do about X.org on Sparc. I have not played with x86, but I beleive that X.org is better than Xsun and may even solve the memory leaks (500M currently) Any thoughts or is it X.org for x86 and Xsun for Sparc!
To answer this, it may help to understand some history. The group I work in at Sun is responsible for the core X technologies - the server, libraries, and clients. Before we shipped Xorg, we didn't ship any of the video card "driver" modules (except for really old cards - the only one left in our Xsun tree today is cg6, the last of the Sbus graphics). The SPARC hardware organization that produces the graphics cards for SPARC workstations makes the drivers for them, the Sun Ray group provides their modules as part of the Sun Ray Server Software, and the x86 platform driver team delivered the x86 modules for Xsun. With Xorg, we've worked with the x86 group so that we just ship the x86 drivers out of the open source tree builds we do. Unfortunately, the open source tree doesn't contain any drivers for modern SPARC graphics cards (I haven't dug out an old enough system, but think it could work on Solaris SPARC with the suncg6 driver in the Xorg source), nor for Sun Ray, so Xorg isn't useful on SPARC yet. Our group is working with the Sun Ray & SPARC graphics groups to try to change this in the future, but I can't say how long it will take for those groups to be ready to ship.
We would like to see Xorg available on all Solaris desktops, and believe it will bring both improved performance and new features - some already here, like dynamic desktop resizing, some still in the future, like Project Looking Glass - but Xsun is still important to us and many of our users. At this point, I'm not aware of any sizable memory leaks in Xsun that haven't been fixed (though the patches are still being tested for a recent fix, for pixmap leaks in Xinerama mode on Sun Rays, so you probably haven't seen those yet). If there are still leaks of a large size in Xsun, we want to know so we can fix them - but be warned that most reports of X server memory leaks turn out to be from one of two misunderstandings of X. Due to the way video card memory is mapped in X, X servers often appear in 'ps' and the like as using much more memory than the actual RAM or swap space used. On Solaris, you can use pmap to look at the various memory mappings to see which are from video cards and which are actual allocations. The other issue is that clients allocate space in the server for things like pixmaps, and the server can't free it up until the client either releases it or exits, so the "leak" could be in a long-running client, such as your web browser. The xrestop program can be used with Xsun on Solaris 9 or 10 (or on recent XFree86 and Xorg releases on other OS'es) to see how much each client has allocated.
And while I'm on that topic, in just over a week I'll be giving a talk on how to use tools like xrestop, xscope, dtrace, etc. to help track down issues with X clients at the 2005 Desktop Developer's Conference. Since I'm running on my usual schedule (a bit late, but I am on vacation this week), I haven't gotten it all put together yet, so if anyone wants to suggest additional tools to cover, or things you want to know how to observe in X server/client interactions, now would be an excellent time to drop me an e-mail or leave a comment here.