fosdem.org

Kristian Høgsberg will give a talk about "Wayland" at FOSDEM 2012.

Could you briefly introduce yourself?

I'm Kristian Høgsberg, I work at Intel in the graphics team in the Open Source Technology Center. I'm the founder and maintainer of the Wayland project and it's what I work on at Intel. I've been at Intel for two and a half years. In the past I've worked at Red Hat, mainly in the X/Desktop team where I did AIGLX and DRI2. Overall, I've been working on Linux graphics and window systems for almost 8 years now.

I've always been excited about driving improvement and simplification in the Linux graphics stack across the various open source silos and tribes.

What will your talk be about, exactly?

Wayland is a new window system architecture aiming to be a good fit for everything from embedded and mobile devices to full-blown desktop environments. Wayland builds on most of the graphics driver, desktop and UI infrastructure we have today, but distills out just the display server functionality we actually use today. The toolkits, device drivers, compositors and desktop environments we use today all play their parts, but the X server is essentially reduced to an awkward, 500kloc IPC mechanism. In the talk we will look at where Wayland comes from, how our graphics stack has evolved to make Wayland feasible and the basics of how Wayland works. We are working towards a 1.0 release of the protocol libraries and the reference compositor, Weston, and we'll take a look at what will be in the release.

What do you hope to accomplish by giving this talk? What do you expect?

We're getting ready to do a 1.0 release, which marks a point where the core Wayland protocol and library APIs are going to be stable. It used to be that you would have to compile a special KMS pageflip kernel, a custom mesa branch and my standalone, halfbaked EGL library. Today, everything is upstream and we're working on closing the gaps in toolkit support.

So aside from the technical Wayland content, I'd also like to tell about our path to 1.0, get the message out that we're peeling off the "EXPERIMENTAL" sticker and invite people to get involved.

You started Wayland in 2008 in your spare time while working for Red Hat. Was it a 'scratch your own itch' project or was it out of technical curiosity?

It was more or less the natural progression from what I had previously worked on at Red Hat. In the X team I worked on making a composited desktop possible. The enabling mechanism was introduced by Keith Packard with the COMPOSITE X extension, but many things were still broken: OpenGL didn't work under COMPOSITE, input delivery didn't respect the window transformation, and we didn't have the infrastructure to write OpenGL compositors. I worked on that for a while and we did AIGLX, DRI2, KMS and GEM and got the graphics stack to where it is today where things work "well enough".

What most people don't realize is once we got there, we were essentially using a completely different window system than the original X. Most of the work is done by the compositor and applications and X is just a middle man. One of the last things that X still does is input handling, but even that belongs in the compositor, we were just never able to fix that. So with Wayland I wanted to make a display server that directly supported that model, instead of building it out of duct-tape and window properties on top of a different type of display server.

Most graphical applications use application frameworks and toolkits such as Qt or GTK+ and could gain support for Wayland through them. But which toolkits are still not supporting Wayland and which other porting issues are still not solved?

Indeed, this is one of the things that make a switch to Wayland feasible at all. Most applications don't go to the window system directly they use a toolkit such as Qt or GTK+. These toolkits provide the common UI elements such as scrollbars, buttons, text fields, etcetera, and typically run on a few other window systems already. So most of the work in porting an application to Wayland is in porting the toolkit it uses. We currently have good support, though still work in progress, in the two big toolkits, Qt and GTK+. The Qt team at Nokia has been very helpful with getting the Qt effort started and at this point they maintain and drive the Qt port themselves. GTK+ is pretty far along too, we're currently working on closing the last few gaps. There is also a Clutter port and an EFL port. We try to keep an up to date list on our website.

Of course, the question was, which toolkits aren't supporting Wayland and I guess the anwer is "all the rest". Of those, I think the most interesting cases are applications that have their own toolkit, for example, Blender and LibreOffice. And then there are the legacy X toolkits such as Motif and Xaw, which are deeply rooted in X and not worth the porting effort.

The two most interesting challenges in porting toolkits to Wayland are probably popup windows and client side decorations. Popup windows are interesting since the popup behavior relies on grabbing the keyboard and pointer, and being able to position the popup window at a given position on screen. Wayland doesn't allow either, but we solve it by having the server know a little more about how the popup should work and implement part of the behavior. The other challenge is client side window decorations, which means that the clients draw their own window title bars and frames. This typically means that the toolkit has to draw a few more widgets as part of the top level window, but it makes the whole stack simpler. It's also a very popular bike-shedding topic.

Obviously, Intel's open source graphics drivers are well supported by Wayland. How's the situation with AMD and Nvidia drivers? For instance, is it already possible to run the X server as a Wayland client with non-Intel hardware? And will their proprietary drivers support Wayland?

All the drivers in Mesa that support DRI2 under X and have KMS support can run Wayland today. The reference Wayland compositor (Weston) has no chipset specific code, it's all done through generic Wayland EGL extensions and KMS. The support for Wayland is in the shared Mesa infrastructure, so when driver writers enable a new chipset in Mesa, it will automatically support Wayland.

I can't speak for AMD or nVidia or their plans for their proprietary drivers.

The Wayland code was first licensed as GPLv2, but you later announced moving to LGPLv2, which didn't happen because instead you switched to the MIT license. What was the rationale behind the choice for MIT and why did you choose GPL and LGPL first?

Initially I picked GPLv2 for the reference compositor (server) implementation and LGPLv2 for the libraries without thinking too much about it. The compositor was intended as a prototype implementation of the protocol, and code would either migrate from the server to the libraries or to a real compositor. As long as I was the only contributor that worked fine, but as other people started to contribute GPLv2 code to the compositor, it would be harder to move reusable code from the GPLv2 compositor to the LGPLv2 libraries. That was the reason I announced the plans to move it all to LGPLv2. I had some time to think about that before actually making the change, and in the end I decided to go for MIT instead. Part of the reason is that a lot of people have concerns about LGPLv2, that it's an unclear and ambiguous license. But also that I'm just not too concerned with proprietary forks. A lot of "secret sauce" that a vendor might want to keep proprietary is either in the higher level UI or in the hardware drivers. None of that is part of Wayland. So I'd rather us a more liberal license that makes adoption easier.

Wayland requires Linux-specific features such as KMS and udev. Would it be much work to port Wayland to other free operating systems such as the BSDs? Do you know of any efforts or interest in this domain?

It's certainly possible to port Wayland to other operating systems, but they'll have to provide the same level of infrastructure as Linux does. One of the things that went wrong with X was that we tried to pull too much of the OS into X so that we could run on every old platform out there. Or to put it more bluntly, bending over backwards for fringe platforms. There's a real cost to that; the code gets encrusted in #ifdefs, codepaths that never get tested and bad architecture decisions such as userspace PCI bus enumeration and writing your own dynamic linker.

I also find that the Linux kernel has a lot of cool features that can make applications faster, safer and simpler, and we often don't use those in the name of portability. There is an accept4 syscall that lets you accept a connection on a socket and sets O_CLOEXEC atomically. The epoll mechanism with timerfd and signalfd does most of what many complex userspace event loops do in many thousands of lines of code. We need to embrace all the new features the kernel offers and not insist on some outdated lowest common denominator.

Have you enjoyed previous FOSDEM editions?

Very much, although I've only been to FOSDEM once before, when I presented my work on AIGLX in 2007. I'm impressed by the scale of the conference and the energy there, and Brussels is a very nice backdrop.

This interview is licensed under a Creative Commons Attribution 2.0 Belgium License.