Linux Graphics News
Last October, our last look at graphics focused on the plans laid at September's X Developer's Conference. In the three months since then, these plans have come to fruition, reasserting the continuing relevance of X.org compared with Wayland and other compositing display servers.
Indeed, while Wayland continues to show solid progress in development, adoption by users and distros remains light, with efforts focused around niche areas (e.g. automotive). That said, this quarter saw interesting progress at increasing Wayland's flexibility, which may enable it to enter a wider array of niches and use cases.X.org Stable Release News
The X.org project saw a prolific quarter, with several packages receiving some major new releases:
- The Intel video driver (xf86-video-intel) has had several release candidates in their run up to their 3.0 release. Version 3.0 will feature switching to using the Sandybridge New Acceleration (SNA) by default. SNA is the latest 2D acceleration method from Intel, and promises faster rendering performance and better power usage than the current UXA acceleration method. SNA has undergone extensive testing over the past few years, and has been shipping as the default in distros like Ubuntu. Another new feature is tear-free rendering on transformed/rotated outputs. The 3.0 series also brings in bunches of hardware enablement fixes, build fixes, performance tunings, fixes for graphical glitches, and other stabilization work.
- mesa achieved version 10.0. The major new feature is the implementation of the OpenGL 3.3 API. The API is implemented for the Intel driver; OpenGL 3.3 support for the Open Source Radeon and Nouveau video drivers will be filled in by those projects over time. Along with this comes fixes for a number of rendering problems encountered by games, demos, and h264 video playback. This was followed by a 10.0.1 release which corrected a regression preventing Mesa 10.0 from working with released versions of the X server.
- xorg-server released 1.15.0 just before the end of the year, on December 27th. This release brings the Direct Rendering Infrastructure 3 (DRI3) and the Present Extension, which provides an efficient rendering path for direct rendering applications like games and video players when operating in a composited environment. This brings Wayland-like rendering performance to X.org and solves some major longstanding glitch/tearing type bugs. Beyond DRI3, this release also introduces a major GLX code re-write. A notably missing feature is any support for XWayland or XMir, so both of those projects will need to continue carrying their own X11 compatibility patches.
- xorg-server also saw several stable releases of the previous 1.14.x branch, most notably being fixes for passive/active grabs, touch listeners, and pointer syncing in 1.14.3 and 1.14.4, and a series of randr fixes for 1.14.5.
- The release of presentproto 1.0 and dri3proto 1.0 marks a major release of Keith Packard's Present extension work. This adds a new protocol and API to give clients a better way of redirecting rendering data to hardware while in a composited environment.
While X.org development is as usual all over the map, there have been several areas of particular focus lately:
- The DRI3 and Present extensions mentioned above have landed in the mainline xserver, and are included in the 1.15 release. Code review and testing found several issues.
- Compiler warnings have received intense focus, with scores of patches going in just this month. This work is targeted to the 1.16.x branch.
- Multi-monitor support has improved in several distinct areas, spurred on by NVIDIA's addition of randr 1.2 support and by recent advances in multi-GPU and hybrid graphics. randr improvements include support for master/slave GPUs and allowing hotplugging of the slave, with changes reported up the graphics stack.
- Code cleanup and general updating of the Xephyr codebase, including migrating it to use XCB instead of direct glx/libXv/Xlib.
- The usual scattered fixes for glx and Xi/dix, etc. Touch device support and active/passive grab handling represented the bulk of input changes.
The just-announced 1.8 release series for the Enlightenment Foundation Libraries (EFL) is a landmark release due to the feature set and extremely long period since 1.7 (~14 months).
One of the other major features of the 1.8 release is the introduction of asynchronous rendering, which will greatly improve application responsiveness when performing heavy rendering operations. This is especially relevant on embedded devices which are gaining more and more cores, allowing for parallelized operations to compensate for lower clock speeds to ensure better UX during the times when multiple cores are enabled.
The final major feature in this release is that all the various libraries, excluding Elementary, have been merged into a single repository and build tree, which makes it much easier to package and distribute the toolkit.EFL Development News
Looking forward, the 1.9 series of EFL releases is slated for February under the new release manager Stefan Schmidt. He has proposed and outlined a process by which he plans to do 3 month release cycles. E18 release is also pending, with work on E19 having begun back in July.Cairo Stable Releases News
Despite earlier predictions, there were no stable Cairo releases this quarter, but pixman received several updates. The pixman 0.32 release series brings performance improvements for image scaling, and numerous bug fixes. 0.31.2 was a development release on this branch, and 0.32.2 and 0.32.4 were followup releases providing a few build fixes.Cairo Development News
Aside from a handful of bug fixes, development activity for Cairo has been light the last few months. There has been little activity on the mailing list and few commits to the mailing list. On-list discussions have mainly been usage questions. There have only been ten commits during the past three months.
In 2013 the Inkscape project introduced a sweeping change in replacing their rendering engine, libnr, with Cairo. Cairo had been used here and there in the codebase, but various issues prevented a wholesale switch. Working with Google Summer of Coding and the Cairo development community, they were able to see these issues solved (or work around them within the Inkscape codebase), and now have moved over to Cairo as the default. Due to the care taken in the conversion, they have incurred no major regressions, and indeed have solved a number of longstanding feature and performance issues.
Inkscape is preparing their 0.91 release, projected to arrive in spring 2014. In addition to the Cairo conversion, other major new features being highlighted include:
- Cairo rendering for display and PNG export
- OpenMP multithreading for all filters for substantial editing speedups
- Major improvements in the text tool, with typography extensions
- A new measure tool
- Type design features
- Symbol library and support for Visio stencils
- Cross platform WMF and EMF import and export
- Improved support for Corel DRAW documents, and a Visio importer
- Support for real world document and page size units, e.g. millimeters
- Numerous usability improvements
Wayland Stable Releases News
The Wayland project is comprised of two code trees: 'Wayland', which is just the protocol definition, and 'Weston', the demo compositor that implements the backend server for the protocol. This past quarter saw a 1.3.0 release for Wayland, and 1.3.0 and 1.3.1 releases for Weston.
With the Wayland protocol largely considered stable now, the Wayland 1.3 release was relatively light. One notable enhancement was the addition of language binding support, which allows writing clients in higher level languages.
Weston 1.3 brings quite a few changes:
- Realtime h.264 screen capture using libva. Potentially will be replaced by gstreamer later. This might serve as the base for a network streaming functionality.
- libhybris support, so weston can be used with Android EGL/GLES2 drivers.
- Better multi-resource input device support, allowing different subsystems can receive events from any number of pointers, keyboards, or touch resources.
- Drag-and-drop from X to wayland.
- RGB565 pixel format for clients using gl or pixman buffers.
- Various fixes and improvements for touch device support.
The Weston 1.3.1 release was an important bugfix release since 1.3.0 was released with a list of known issues. This fixes several severe crashes and hangs, and addresses several functional gaps.
Wayland Development News
The XDG Shell Protocol has received a large amount of attention the past few months, and some preliminary prototyping is underway as 'westoy' - an intra-project fork of weston with the new protocol inserted between weston core and the shell. This protocol is intended to standardize compositor calls that shells need to make, such that weston could be swapped out for a different but protocol-compliant compositor, with no modifications required of the shell.
The Wayland/Weston 1.4 release is scheduled for mid-January, with the first alpha release (1.3.91) posted on Dec 17th. A few of the features being included in this release are:
- Moving subsurface and input methods into wayland, and scaling of subsurfaces. Subsurfaces provide a more efficient design for applications that use sub-windows for displaying video content, such as a web browser with a video player or game embedded in it.
- logind backend.
- Surface/view split, with scaling and cropping support.
- Output cloning and per-output multi-texture borders.
- Fix for wl_shm buffer truncate exploit.
- Nested wl_buffer pass-through.
- Touch grabs to enable touch-to-focus.
- Use gstreamer or libva helper library instead of direct libva use for weston encoding.
- Run-time switchable renderer backends (e.g. Pixman vs. OpenGL)
- An ExposÈ feature.
- linux.conf.au, Perth, Australia, Jan 6-10, 2014
- FOSDEM 2014, Brussels, Belgium, Feb 1-2, 2014
- LibreGraphics Meeting: LGM2014 - April 2-5, 2014: Leipzig, Germany
2013 has been a dramatic and controversial year for graphics in Linux, yet actual changes to the overall graphics stack have so far been more incremental than revolutionary. But with us closing in on several Linux distributions' Long-Term Support releases this is to be expected, as stability weighs stronger than novelty among consumers of these products. This next summer may be a safer window for distros to undertake major transitions; we should expect to see major graphics system transitions in desktop distros at that point. The landing of XWayland support in the X server can be seen as an early indicator of a Wayland desktop future, since it's a crucial prerequisite.
We'll check in again next quarter, when hopefully the distros will have established their post-LTS plans, and we'll be able to forecast the future for X.org and Wayland. Meanwhile, follow us on Twitter @SamsungOSG.