X

News, tips, partners, and perspectives for the Oracle Solaris operating system

More on Xorg in Solaris

Alan Coopersmith
Senior Principal Software Engineer

Didn't mean to take so long before writing more, but life and work interferes...

First, answers to the comments on my last post:

Drawbacks of using Xorg: - Xinerama support in the Xorg server isn't nearly as good (just think about GLX and Xinerama - right now only the Xsun server in Solaris gets this right)
Actually, it's the OpenGL implementation in Solaris that gets this right. It's separate from the Xsun server (and actually delivered by a different group). The X server implementations aren't all that different.
The Shared Memory transport isn't supported by the Xorg server (which means: slower communication between client and server, usually resulting in lower rendering performance and higher latency)
No, it's not yet, but we're not just delivering the Xorg server and quitting. We're looking at the extensions currently in Xsun that aren't in Xorg and seeing which ones should be ported (and maybe even open sourced in the process). We haven't decided yet on the Shared Memory transport (aka SUN-SME ).
The SolarisIA stuff (a special class in the Solaris kernel scheduler which gives the application of an active window a priority boost) is not supported by Xorg
It's not supported by the open source Xorg, but as I noted in a blog entry several months ago, it ported to Xorg easily and is supported in the release in Solaris. (Now you know the real reason for doing that port. 8-)
DPS is gone.
True. But few clients used it, and it was increasingly out of date. Adobe stopped supporting it years ago and I think most other Unix vendors who did support it are moving away as well.
And the SUN_OVL (overlays) and SUN_ALLPLANES extensions are gone, too...
See above note about evaluating the other extensions for future releases - since these are primarily used by SPARC graphics, they were put off until we were ready to tackle SPARC graphics support and then evaluate if they are still needed.
Does that mean that it'll be possible to switch X servers just like that? No impact on the applications linked to X libraries? Or would they need to be linked specifically against one of the two?
Mostly. We're only shipping one set of X libraries right now - the libraries are insulated from the server by the network protocol, so have always worked with any standards compliant server, and Xorg is no different there. Some extensions will only be in Xsun or Xorg, but any correctly written client has always had to check to see if an extension is supported by the X server before using it or it would never run over network display to another platform.

Perhaps the main response to the comments above is that, while one of our main goals is to more closely track the open source releases so we can take advantage of new features, fixes, and drivers, we're not constraining ourselves to only shipping exactly what's in the open source release and we're not stopping work on enhancing X. We still have a good bunch of talented people in the X group at Sun (don't tell them I said that!), and we were very active in the reformation of X.Org and the new open source releases that have come from it so far. We're slowly going through what we have in our Solaris X trees and seeing what we have to contribute and will continue to do so. Like the project to open source Solaris, we've got constraints from other licenses and can't open everything, but are seriously looking at what we can and cannot do. That which is still valuable, but can't be open sourced, can still be shipped in our Solaris releases.

Some examples of changes, big and small, we've made to Xorg in Solaris above what's in the open source version:

  • As noted above, the SolarisIA extension is integrated to boost the kernel scheduling priority of the process that has focus.
  • The higher quality TrueType font engine from Xsun is used instead of FreeType for TrueType fonts in the core protocol.
  • Wheel mouse support is on by default without requiring configuration.
  • Display Power Management is enabled by default
  • The XST extension (part of the Standard Type Services Framework) is included.

Of course, there's also all the changes we made but gave back already - just look at the many entries from Sun people (okay, mostly myself and Stuart checking in the work of Sun engineers) in the X.Org CVS ChangeLog - everything from better Solaris & Sun compiler support to the new XEvIE extension (originally designed for accessibility, being adapted to serve projects such as Project Looking Glass). And we're just getting started at this...

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.