Linux Graphics News
The graphics stack in Linux comprises a number of distinct projects, and in this article we'll take a look at the current development of X.org, Wayland, and Cairo.
Linux graphics have undergone a major evolution over the past decade in two respects. First has been a shift from 2D system rendering, to today's hardware-accelerated 3D system compositing. Second has been a large-scale migration of graphics support from X down to the kernel level, where it can take maximum advantage of hardware capabilities. In recent years the former has exposed limitations in X.org's design, while the latter made it much easier to reimplement a graphics stack separately from X.
Thus there is now both the motivation and means to replace X, and this has led to a couple efforts to do just that. Wayland is slowly but surely becoming a useful affair, and Canonical's Mir efforts are offering a credible new challenge. Yet recently X.org has embarked on development of DRI3, demonstrating that this venerable project is not yet ready to fade into the sunset.
- xorg-server: 1.14.2 was released June 25, 2013.
- wayland 1.2.0 and weston 1.2.0 were released on July 12, 2013.
- cairo: 1.12.14 was released Feb 10, 2013, and is currently preparing for a possibly upcoming 1.12.16 release.
By and large, X.org is in maintenance right now, although some interesting development work is going on around the edges.
Of particular note this month, Keith Packard has been developing Present, an X server extension that handles redirected video in composited scenarios more cleanly. It provides a more direct path for applications to display visuals on the screen. This complements recent development work for the new DRI3 extension. See below for a more detailed examination of this new technology.
A new library, libevdev, was introduced by Peter Hutterer, which wraps the kernel evdev interface and provides abstractions for ioctls, SYN_DROPPED events, and device bit checking. The goal of this work is to establish a shared codebase for use by X.org, weston, and evtest. libevdev has received two releases so far, and is currently at version 0.2.
Multi-screen reverse optimus support was added to the Nouveau and Radeon drivers. This feature allows rendering to be done by the integrated GPU (typically Intel), and displayed through monitors connected to discrete GPUs (e.g. Radeon or NVIDIA graphics cards).
In addition to these major efforts are the usual array of bug fixes and codebase cleanup changes. Of particular note, Peter Hutterer proposed a large set of input patches to backport fixes for touch to xserver 1.13, to fix grab handling, cursor refcounting, race conditions, and other issues. Driver and keyboard fixes were also integrated from OpenSUSE by Egbert Eich, and from NetBSD by Thomas Klausner.
As X.org has been around quite some time, there is ongoing efforts to excise obsolete code to help cleanse the codebase. This month's dead code removal included dropping CRAY support, and obsoleting libxkbui.
The DRI3 and Present Extensions
One of the main selling points of Wayland and other recent display technologies being developed is that they provide a better solution to X.org's limitations when it comes to compositing of multi-buffer windows. X.org predates today's ubiquitous 3D-capable graphics hardware and its original design did not take compositing into account. It's a testament to X11's modular flexibility that compositing could be added in via the DRI2 and composite extensions, however this scheme has always felt a bit bolted-on to developers, and doesn't work well with direct rendering clients such as games and movie players.
However, a recent X.org development promises to change this, via the DRI3 and Present extensions.
The DRI3 extension allows applications to render directly through kernel buffers into Pixmaps, effectively moving this graphics buffer management out of X and into applications.
The Present extension handles moving the pixels from the DRI pixmap created by the DRI3 extension to an X drawable that can be displayed. An application calls PresentRegion once it has a back buffer ready. The server captures this request and constructs an event for the compositor to place the image correctly on the screen. The compositing manager receives this event and clips the pixmap to the shape and transformation of the window. Then it combines the transformed pixmap with other application pixmaps as needed (thus handling multi-window translucency, blur, etc.), and generates another PresentRegion request to have the result mapped onto the root window. Additionally, the compositing manager is made aware of which monitor the window is being drawn on, so it can synchronize the updates to that monitor CRTC's refresh rate. The application is then notified that its PresentRegion operation has completed, so it can handle cleanup and proceed with the next cycle.
This new approach serves to minimize the number of copy operations needed by applications to display their content within a composited environment. The goal is to achieve this without incurring tearing or other display artifacts.
By providing a complete direct rendering solution for OpenGL, the DRI3 and Present extension provide applications with the key benefits promised by Wayland, without the need of replacing X. Initial implementation of these extensions has been done, but they've not yet landed in the Xserver repository. If it lands soon, we may see this functionality in Xserver 1.15, scheduled for release in September or October; otherwise it'll need to wait for 1.16 this spring. For now, the functionality is available through Keith Packard's freedesktop.org git branches.
A common misconception about the Wayland project is that it is intent on literally replacing X. A more accurate view is that it is a technology incubator for proving out design concepts. The project produces two components: The Wayland Protocol and the Weston Display Server. The Wayland Protocol is considered the principle product of the project, with Weston being a reference implementation that it expects other projects to study or reuse from in developing their own Wayland-compatible technologies. The Weston package also includes an example shell and several example client applications.
This month saw the 1.2.0 releases of both Wayland and Weston. With much of the core API and implementation stabilized in 1.0.0, development in versions 1.1.0 and 1.2.0 has mainly focused on adding backends, polishing up the codebase, improving input handling, and fleshing out subordinate features that take advantage of the Wayland architecture.
One of the new features added in 1.2.0 is a new subsurface protocol extension. This allows clients to create their windows using multiple Wayland surfaces, for example a video player that might consist of window decorations, the video player, a sub-title layer, and picture-in-picture. Each graphical buffer can be of a differing type, with its own color space.
Color management was made more flexible in this release, as it now permits a choice between a simple CMS plugin with a profile read from weston.ini, and integration with colord. The latter permits run-time adjustment of the color profile using tools like gnome-color-manager or colord-kde.
Multi-seat functionality was added to permit defining keyboard and mouse pairs using udev rules. Each of these 'seats' can (optionally) be confined to a specific output monitor.
There is a new example client included which demonstrates how to share buffers among clients. The classic use-case is a web browser with an embedded client plugin for video playback. For security purposes, Wayland imposes stricter boundaries between clients than usual for X, so this demonstrates how to make one client act as a compositor for another in a nested fashion.
Several efforts this month focused on improvements to the shell. A xdg_shell protocol was proposed, that would establish a standard API with functionality like resizing or moving windows, setting windows state (transient, maximized, et al.), and setting window names. Shell functionality from the Raspberry Pi technical demo were proposed for inclusion; some fixes were pulled in, other items were deemed more cosmetic and out of scope for Weston.
Jason Ekstrand proposed language bindings for libwayland, for e.g. writing clients in e.g. Java. This could be a significant new feature, if it opens up Wayland client development to a wider range of programmers.
Beyond Wayland core development there are starting to appear efforts to add Wayland compatibility in other projects. Sam Spilsbury announced a proof-of-concept port of the XBMC Media Center to run inside Weston, using SDL 2.0. Both the KDE and GNOME desktop environment projects have declared intention to add Wayland support; the Enlightenment project already runs on Wayland, and plans to implement a stand-alone Wayland compositor.
Cairo development has been fairly quiet this month. The tree is being stabilized for a 1.12.16 release, although no dates or release schedules have been announced.
About a dozen patches this month focused on test suite fixes and cleanup. In particular, support was added for identifying redundant reference images; this was used to drop a bunch of unneeded files from the codebase.
In addition, Henry Song landed three patches to fix stencil buffer issues. Behdad Estfahbod landed some preparatory work for loading color glyphs from FreeType.
It will be interesting to see if the DRI3 / Present extensions for X.org will satiate Linux distribution graphics needs, or if Wayland adoption will accelerate as its technologies mature. Or, perhaps, the migration of core graphics technologies from X.org into the Linux kernel will inevitably lead to a Cambrian Explosion of compositors and new graphics projects. Will Wayland and Mir be the only contenders for replacing X, or have they merely paved a path for future projects to follow? Will the Wayland protocol be compelling enough to prevent fragmentation, or are we destined to see a host of specialty display technologies built atop the Linux kernel?
- Linux Plumber's Conference: Sept 18-20, New Orleans, Louisiana. A Graphics and Display micro-conference is being scheduled.
- X.org Developer's Conference: XDC2013 - Sept 23-25, Portland, Oregon
- LibreGraphics Meeting: LGM2014 - April 2-5, 2014: Leipzig, Germany
Bryce is a Senior Open Source Developer at Samsung Research America.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Paranoid Penguin - Building a Secure Squid Web Proxy, Part IV
- SUSE LLC's SUSE Manager
- Google's SwiftShader Released
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- Doing for User Space What We Did for Kernel Space
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide