News, tips, partners, and perspectives for the Oracle Solaris operating system
-
Perspectives
April 27, 2005
What should we give to X.Org first?
One of the interesting conversations I had at last night's inagural Bay Area OpenSolaris User's Group meeting was with Ben Rockwood who asked about our plans to contribute code from Sun's X code pool to X.Org. This is something we've been doing since the Xorg CVS tree opened on freedesktop.org a little over a year ago and plan to do more of as we can. Our primary limiting factor right now is mainly the time it takes to port the code into the CVS head, build it, test it, and commit it. There's a lot more things we can contribute and hope to get to than we have time to do while still working on improving the X software in Solaris. So the question arises, how do we prioritize the bits to give back? It's been pretty random so far, with code putbacks done because we needed to get extensions like Xevie out there for our joint projects with the GNOME Accessibility Project, or because we found issues in Xorg on Solaris we needed to fix for our release and it was easy to give back to Xorg at the same time, or because it simply was interesting or useful to someone at a certain time.
For instance, right now, I've got a couple of CVS trees with bits I'm getting ready to check into Xorg CVS "HEAD" in various states of preparation, including:
- An experimental AMD64 64-bit port of the Xorg tree for Solaris that Sun's performance team created to do some benchmarking. Most of the heavy lifting there in the OS-independent code was already done by the Linux & BSD distros porting, so this is mostly changes to the Solaris-specific bits.
- A "BuildLikeSun" Imakefile option for those who want to more closely mimic our builds where we differ from the community standards - things like install locations, Solaris library standards, and so on.
- Updates to the Solaris mouse & keyboard support modules, both to fix some bugs we've found and to add support for new features the Solaris kernel drivers for mouse & keyboard will be providing soon.
But we can also decide to work on things in a different order, if there's something we have in the X Window System in Solaris that would be useful to others to have. It's hard for us to know what that is in many cases though - so if there's something you know we have in X in Solaris, drop me an e-mail or comment here, and we can look at pushing that up on the list.
I should probably warn ahead of time that there are limits - our group can only do this for the code in our source trees, and can't control the decisions of other groups over what to give back or not. So if you're asking for something, it may help to understand how our trees are broken up internally:
- Main Solaris X11 source tree - originally done as a "fork" of X11R6, with Sun changes from previous X11 releases merged in, and then later X11 releases from the X Consortium & X.Org merged in later. Contains the Xsun server, most of the X11 "core" client applications and libraries, and various other bits - roughly equivalent to the SUNWxw\* set of packages in Solaris.
- New Solaris Xorg source tree - done much more like the style you see in Linux releases - we keep a copy of the unadulterated upstream source and a copy of the changes we've made for our builds, combine them at build time and package. This makes it much easier to bring in new releases from upstream than the previous model of having to merge every single file, even those we never change. Currently mainly used for the Xorg server and the libraries and programs specific to it, we eventually plan to migrate most of our X packages to being built from this tree to allow easier updates from the open source community.
- Xsun video device source trees - the SPARC graphics, x86 platform, and Sun Ray teams each keep their own source trees for the modules to support their devices under Xsun. (For Xorg, we currently only ship the drivers from the Xorg open source release, so those live in the Xorg tree.)
- Desktop environment source trees - OpenWindows, CDE, and GNOME/JDS all live outside our trees.
So while I'd love to release the source to our SPARC frame buffer modules, and let the community help port them to Xorg, it's out of my hands. There is still a bit of stuff we could contribute from the rest though, so if there's some feature we have that you'ld like to see us give to Xorg, let me know. I can't promise that we'll do anything more than listen and think about it, but we'll do that.
People would \*really\* love that.. :)