XWayland Updated Against X.Org Server 1.12
XWayland has been around since last June when before that it was known as X.Org "Hosted" as an abstracted means of running a xorg-server within another system. XWayland support hasn't been merged into the mainline "xserver" tree, but Kristian has updated against the current X.Org Server 1.12 series code-base.
This new work was all pushed this morning and can be found in his new xwayland-1.12 branch of his personal X.Org Server Git repository. The XWayland/hosted work amounts to a few thousand lines of code changes.
Kristian's also pushed an xwayland-1.12 branch of the xf86-video-intel driver for the XWayland support. The Intel DDX changes required for handling XWayland amount to just over 100 lines of code. For graphics hardware without an updated DDX driver to support XWayland, there's still available the xf86-video-wlshm DDX driver to serve as a "fake" X.Org graphics driver.
As far as Wayland support with X goes, back at FOSDEM 2012 it was discussed. Below are my comments from that event last month concerning X/Wayland.
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.
6 Comments
