Planning the X/Wayland Marriage, X Server 1.13
In terms of the X.Org Server 1.12 release that's expected to happen by early March, Keith went over the changes and its past six months of development. Of course, the most exciting part of the 1.12 release is X Input 2.2 extension, which presents Multi-Touch support for systems running X11.
Aside from the major input advancements, there isn't too much else exciting with this next release. There is some changes to libpciaccess, documentation updates, string function changes, etc.
What unfortunately is not found in xorg-server 1.12 is the server-side changes for GLX_ARB_create_context support with GL3. This work by Ian Romanick ended up being too late for X.Org Server 1.12, but the GLX updates should be here for X.Org Server 1.13.
A more unfortunate feature lacking from the 1.12 series is RandR 1.4, which has been talked about for years and was merged before but then reverted. RandR 1.4 comes down to per-CRTC pixmaps and improved mode-setting support. The atomic screen-wide mode-setting changes is what would make it easier for NVIDIA's binary driver to support RandR 1.2+ and it would also benefit other modern GPUs/drivers too.
It was the per-CRTC pixmap support that caused RandR 1.4 to be yanked previously. With X.Org Server 1.12 there were no attempts to prepare and merge RandR 1.4. What Keith talked about doing now is just merging the parts of this Resize and Rotate extension update that are baked and ready while leaving the other bits out until they mature.
After discussing 1.12, Packard brought up the xorg-server 1.13 release. Keith is planning for this next X.Org update to come by early September. The date he has in mind is the 7th of September (2012). In coming up with the date he ensured it wouldn't collide with the Bavarian X.Org Summit that will be later in September or that it wouldn't interfere with Oktoberfest (acknowledging that the only "X.Org press" [myself/Phoronix] will be preoccupied).
Keith then took off his release management hat and began talking about X.Org and Wayland integration. The plans, which aren't new, is to allow for full integration between X and Wayland applications. There will be support for seamless multi-window mode, and full performance of X exposed through Wayland. X.Org-dependent applications will be able to run within a Wayland Display Server just as XQuartz does similarly for X applications on Mac OS X.
Keith expects that there will be no performance penalty of running X applications on Wayland versus running them as you have already for decades on bare metal. In fact, he says it's one of his goals to see there aren't any performance drops, but the performance of X applications on Wayland may actually yield a performance boost. The performance boost would come as a result of handling swap requests with Wayland being much simpler.
Among the X/Wayland items still to be solved is how to synchronize keyboard mapping changes, the acceleration architecture for X on Wayland, and how to handle RandR-like display configuration changes. In terms of the acceleration architecture discussion it came down to how to best accelerate X apps on Wayland and whether some DDX driver code from the various hardware drivers should be pulled out or what would be the best approach.
As far as what works now for X on Wayland is that basic X apps should be working, a primitive window manager, cut/paste, and drag-and-drop works. Keith acknowledges lots of people are excited about switching to Wayland.
5 Comments
