Two quarters ago we saw that Glamor and XWayland were poised for making strong progress. Half a year later, we see these technologies have permitted vast progress by the X and Wayland communities.

X.org

X.org's Xserver saw a 1.16.0 release in July, which brings Glamor, XWayland, and non-PCI device support; a 1.16.1 release followed in September with bugfixes. Glamor builds on top of the OpenGL standard to provide hardware-accelerated X functionality that used to be provided via hardware-specific video drivers - which sometimes default to slower software fallbacks. Thus, glamor is allowing video driver developers to simplify their hardware-specific code, and in so doing lessening the need to fallback to software as well. Xephyr also gained Glamor support this release; Xephyr is used for "headless" testing, and with Glamor it's able to perform more closely to a native X session. Glamor also made the XWayland support more feasible to implement, allowing its integration into the Xserver this release. Non-PCI device support permits displaying graphics on video devices connected via means other than the PCI bus, including USB video.

mesa's 10.3 release in mid-September saw the introduction of GLX_MESA_query_renderer for game developers, a new software rasterizer driver called kms_swrast_dri, and GLX DRI3 GPU offloading support. In addition there was progress made by a number of video drivers. A 10.4 release should arrive in December. Full OpenGL 4.0 support will be introduced in mesa 11.0.

The Intel video driver is introducing using Glamor for 2D acceleration. Historically, the Intel driver has experimented with a lineage of 2D acceleration technologies: XAA, EXA, UXA, and most recently SNA. Each generation seemed to get more Intel-specific and required more and more be done in software. Thus the shift to the hardware-agnostic Glamor marks a big strategy shift: As desktops have shifted to 3D composited environments, the need for maximum 2D acceleration has eased. So, from a maintenance standpoint it's better to have a good 2D acceleration technology that is widely adopted and worked on, than to have a tightly optimized, hardware-specific 2D acceleration that only a few people understand.

Cairo

Cairo finally saw a new stable release 1.14.0 in early October. The release is largely a wide array of bug fixes collected over the past year, along with build and test system improvements made more recently. The main new feature is the addition of a highly demanded image downscaling functionality; these new scaling algorithms are implemented for the image backend and used by other backends for fallback needs. Other features include improvements to device transformation and scaling, which provides HiDPI support, and support for JBIG2 mime data in PDF. One performance optimization by Samsung optimizes the VBO size to 1M for GL, and 16k for EGL.

Samsung's Caskbench benchmark was announced on the list in late September. This benchmark provides a set of tests for doing comparison of Skia performance against Cairo. Test runs of Caskbench demonstrate that cairo-gl performance has significantly improved since the last time it was reviewed; for some tests the improvement is several orders of magnitude.

Wayland

The Wayland project involves four codebases: A standard protocol package, called Wayland; a reference implementation called Weston; and two libraries libinput and libxcbcommon that Weston depends on. These latter two libraries are available for use by other Wayland implementations and with X.org's Xserver.

Wayland received primarily bug fixes in the 1.6 time-frame, but also gained a number of new test cases in the test suite, keyboard repeat rate control, and a way for the server to automatically find a free socket name. Improved error handling now allows Wayland clients to better diagnose error conditions.

Weston 1.6 saw more development activity. Much of this focused on improvements and fixes needed by desktops as they work on porting to Wayland. The Xdg-shell protocol, which defines standard functionality that desktop environments should provide, saw some churn due to important changes needed by the desktops; it is hoped the protocol will be re-stabilized by 1.7.0. Keyboard repeat rates and the numlock start-up state are now configurable. Handling of desktop shell crashes was smoothed out, to prevent some black screen freezes.

Libinput saw two releases (0.5.0 and 0.6.0) this quarter with many clean-ups and bug fixes.
Under 0.5.0:

• Pointer acceleration (especially for touchpads) has been improved.
• Basic palm detection has been added.
• Much more device information is exposed via the libinput API now, and the beginnings of a configuration API is emerging - as a side effect of the new configuration API, touch pad tap-to-click now defaults to "off".

0.6.0 is mostly a bug fix release, though some feature work took place:

• libinput no longer allows querying the current state of all keys - applications now must watch for events, any keys held down at library initialization now propagate events right away.
• touchpad calibration has had a major overhaul, and been added to the new configuration API

Weston/Wayland 1.7 is intended to be complete in mid-February. One of the new features being added is the Presentation extension, which improves performance of sub-surface embedded video playback.

For libinput, a lot of the development effort focuses on improving user experience on touch devices, by tweaking and optimizing finger hit/release timing and so on.

Final Thoughts

X.org rolls along. With technologies like Gallium3D and Glamor allowing broader code sharing, the workload of maintaining and optimizing this code will similarly broaden. X is getting leaner and meaner, as it drops crufty hardware-specific code and enables itself to tackle newer and more esoteric corners of the graphics hardware market.

Meanwhile, as X races to slim down while modernizing, Wayland is bulking up to reach a feature-complete state.

Last quarter we mentioned Fedora's Wayland plans. In late September it was announced that a usable GNOME/Wayland port had been achieved. Much work remains, including several window management functions that aren't available in xdg-shell yet, and a couple DND-related functions.

With Qt and EFL also porting to Wayland, we're at a point where we should start to see the more technically-inclined users start to experiment with Wayland-based desktops for day-to-day use. Eventually, a critical mass of applications will be ported which will enable mainstream users to make the switch. If we start seeing evidence of this desktop migration in the next six months, we may well see Wayland and Wayland-a-likes become the norm in the 16.04 LTS cycle.

Of course, this presumes that Wayland continues to present compelling benefits over sticking with X.org. X.org is not a static project! As we've seen via introduction of technologies like Glamor and Present, X.org is able to reinvent itself continually and in doing so pare down the list of benefits that a switch to Wayland would bring. The Wayland architecture still has several advantages over X.org, though; a key thing to watch for is per-application security in X.org. X can already be run rootless in some configurations; if it can also run applications in some form of sandbox mode, then Wayland's security advantages may become a lot less compelling.

Bryce Harrington is a Senior Open Source Developer at Samsung Research America focusing on Open Source Graphics. Prior to Samsung, he led Canonical, Ltd.'s Ubuntu X.org team, and focused on stabilization of the graphics and input infrastructures for the Ubuntu distribution. Bryce began his career in the aerospace industry as a spacecraft propulsion engineer at The Aerospace Corporation, Hughes Space and Communications and TRW. Later, he joined the Open Source Development Labs as a Senior Performance Engineer working on NFSv4 testing and development of automated test systems. He is a founder and developer of the Inkscape project and serves as Chairman of the Inkscape Board. Bryce has a BS-AE from USC and an MS-AE from Caltech.