One sure way to stir up Linux users and developers is to propose
replacing a tried-and-true technology with an up-and-coming
technology. Especially replacing something as crucial as X, which is what
Mark Shuttleworth suggested might
happen on Ubuntu, with Wayland taking its place. The response to Shuttleworth's post, along comments and questions on development mailing lists since, show that Wayland is not well-understood in the larger Linux community. Moving to Wayland isn't as far-fetched as one might initially think.
So what is it? Wayland is not, as it was initially reported, a "new X
Server" for Linux. Wayland is the name for the protocol and the
MIT-licensed implementation of a compositor that can run as a standalone
display server, or under X as a client. Most importantly, Wayland (when
running on its own) removes a few layers of complexity.
As explained in the Wayland
architecture document, X runs on top of the Linux kernel and, in
conjunction with a compositor, it is in effect adding an extra layer
between the kernel, hardware, and compositor. With X, windows and contents
are sent to a separate buffer and then "composited" together into the frame
buffer by Compiz, Kwin, or another compositing window manager. With Wayland, all of this will happen in one display manager.
Wayland works directly on top of the kernel, and lets the clients handle
rendering directly without the intermediate layer. Wayland uses direct
rendering through OpenGL, or OpenGL ES. X imposes additional
layers, and that causes a performance hit. As Shuttleworth wrote when tapping Wayland as the future for Ubuntu and Unity, "we don't believe X is setup to deliver the user experience we want, with super-smooth graphics and effects."
The initial reactions and discussion about Wayland had more than a tinge of concern. Much of which based on fairly breezy reports about Wayland as a replacement for X for Ubuntu. As Andrew Haley points out on the Fedora devel list, there's no immediate cause for alarm:
It looked like a bunch of kiddies who had never used remote X applications had decided we didn't need to do that anymore, and it was more important to get kewl features like smooth scrolling and rotating 3D whatnots. It seems that isn't true, and we don't need to worry. The lunatics have not, in fact, taken over the asylum.
Yes, the asylum remains in competent hands. Wayland is not a new
idea. Wayland started as a "secret" project by Kristian Høgsberg in
2008. Høgsberg's creation was outed
by Phoronix, caused a brief wave of excitement in Linux circles, and
then went back to largely being ignored by most of the Linux world.
But X folks have been thinking about Wayland, at least occasionally, for
some time. Last year at the Linux Foundation Collaboration Summit, Keith
Packard talked about turning
"the graphics stack upside down" by moving device configuration out of X
and into the kernel, which would pave the way for other systems like
Wayland. Packard also hinted that a post-X era may be in the
offing while at this year's Linux Plumbers Conference, and mentioned Wayland as a possible replacement — with X running as a client.
Why not simply extend X, yet again? It's been extended to add all sorts
of features never envisioned when it was first developed. Wayland is an
option "of pushing X out of the hotpath between clients and the
hardware and making it a compatibility option," as described in
the FAQ. X
running as a client is a particularly important feature. As Adam Jackson points out on the Fedora devel mailing list, X applications only need be ported to behave as native Wayland clients. Otherwise they can run within Wayland within a nested X server "and you wouldn't ever know the difference." Note that Wayland can also run as an X client, which allows for development and testing during the transition.
It may be beneficial to look at Wayland as an opportunity rather than a
potential problem. For example, while many games now run well on X, it is not particularly friendly for fullscreen 3D games. Høgsberg indicates that thought has already gone into the specific problems of fullscreen games and how to address problems like modesetting and handling the pointer.
Wayland is also poised to support
GPU hotswapping, something that X does not currently support. As more
hardware ships with more than one GPU, which is intended to help with power savings, users will want Linux to support switching between the GPUs.
But we're not there yet. The big problem, of course, is that Wayland is not ready for prime time — or even early morning between infomercials. Wayland may see an influx of interest thanks to the attention it's getting, but there's a long way between vision and reality at the moment.
As Packard mentioned during his LPC talk, input is another problem for an alternative display system. Key mapping, accessibility work (using the keyboard for mouse movement, for instance) and handling more complex input devices like touchpads, all need to be addressed.
Aside from a general lack of readiness for Wayland itself, Wayland also lacks drivers. Nvidia has already explicitly said it has no interest in Wayland, though Nouveau may be able to take up the slack there. Wayland can use the open source KMS drivers for ATI, Intel, and Nvidia — but what about the new crop of video hardware coming with ARM-based devices? Here we have a new set of video hardware without open source drivers or existing efforts to create them.
There's also the question of who's going to do the work to ready
Wayland. The work on Wayland up until now — and in the foreseeable
future — has been on Red Hat and Intel's payroll. Høgsberg was a
Red Hat employee when he first started Wayland, and is now working for
Intel. Canonical doesn't have any resources currently assigned to work on
Wayland. Canonical's Ted Gould has set up an import of Wayland's git tree
into Launchpad to make it easier to build packages. But Gould says he's
unaware of anyone directly working on Wayland who is on Canonical's payroll:
Most of our effort there is ensuring that the new stuff we are building (Unity, uTouch, etc.) is compatible with a post-X11 future. It seems like momentum is definitely switching in that direction with even Keith implying it at Plumber's.
Personally, my biggest worry with Wayland is graphics drivers, and I think that was partially what Mark's blog post was trying to help with. Establish a direction at a high level to let other companies know where we're going. I hope it's successful, otherwise the switch (which seems inevitable at this point) will be very painful.
Users who are itching to get hands on bleeding-edge Wayland builds can look at the compile instructions, or add the "xorg crack pushers" PPAs for Ubuntu to install Wayland on Maverick (10.10) or Natty (11.04). Breakage is quite likely. Developers interested in pitching in are welcome to do so. Wayland is part of freedesktop.org, and the git repository is open.
But it will be some time before anyone needs to make the switch. With
the renewed attention caused by Shuttleworth's post, Høgsberg has
started working more actively on Wayland again. But while Høgsberg
isn't quite going it solo, there's not a lot of commits from other
developers yet. Shuttleworth indicated that it would be a year before
Ubuntu could seriously consider switching to Wayland. Fedora will probably
package Wayland for F15, but when it will be default is up in the air. Jackson says the "cabal" of Fedora graphics folks "don't even have a complete list of transition criteria yet, let alone a timeframe for switching the default." It would seem that replacing X has momentum, but we're a long way away from making a switch.
Comments (47 posted)
I'm not at all convinced that people and, more particularly,
corporations, have really analysed the implications of web apps and
cloud computing. When they do I don't think web apps will prove all
-- Harold Fuchs
-- Shu Wang
, Adobe, on when the Flash
bug might be fixed.
Comments (none posted)
Initial MPlayer developer "A'rpi" has noted that November 11 is the
tenth anniversary of the 0.01 release. One decade later, the project
continues its asymptotic approach to version 1.0 and it clearly has a wide
user base. Congratulations are in order.
Full Story (comments: 41)
After a long slow period, development on the notmuch mail indexing system
has picked up again; the 0.5 release is now available. "The major feature in notmuch 0.5 is the ability to automatically
synchronize maildir flags, (so that if a mail file gets marked
externally with the flag 'S' for 'seen' then the 'unread' tag in the
notmuch database will be automatically removed). And of course, there
are various fixes and improvements throughout.
Full Story (comments: none)
Version 2.10.0 of the Parrot virtual machine has been released. The code
has been moved to github, so work has been done to make various subsystems
more Git-aware. There's also some new documentation on using Git to work
Full Story (comments: none)
ActiveState has announced
an index for Python modules
. It offers some useful features like searching by keywords or tags, finding all packages by a specific author, and more. "Although PyPM Index was originally intended to be a frontend to browse/search for packages available in the ActivePython PyPM repository, it evolved as a general purpose site to find information about almost any Python package.
Full Story (comments: 4)
The twelfth systemd release is out. New features include support for more
services (to the point that a "normal distribution" can boot with no shell
invocations), Ubuntu support, system-level passphrase support, a new
"condition logic" mechanism, and more.
Full Story (comments: 11)
Newsletters and articles
Comments (none posted)
The Libre Graphics Magazine
launched. "This is one purpose of a Libre Graphics Magazine: to
serve as a catalyst for discussion, to build a home for the users of Libre
Graphics software, standards and methods.
" The first issue is now
available; it's 64 pages of CC-licensed content available either in PDF
format or as a for-purchase printed version. This issue includes articles
on free fonts, free software in the classroom, a "unicorn tutorial," and
Comments (5 posted)
Page editor: Jonathan Corbet
Next page: Announcements>>