1. Computers
  2. Display Drivers
  3. Graphics Cards
  4. Memory
  5. Motherboards
  6. Processors
  7. Software
  8. Storage
  9. Operating Systems

Facebook RSS Twitter Twitter Google Plus

Phoronix Test Suite


Why Wayland & Weston Were Forked

Scott Moreau

Published on 29 March 2013
Written by Scott Moreau
Page 2 of 4 - 131 Comments

For those who do not know about wayland/weston internals, I will attempt to explain a bit. The shell plugin is largely the window manager part of weston. It is built as a shared object (desktop-shell.so) from weston/src/shell.c. In addition to the shell plugin, there is also the xwayland plugin (xwayland.so), built from files found in the source directory weston/src/xwayland/. This is the special Xwayland window manager that allows X clients to be used as wayland clients.

These plugins are loaded by weston at runtime. xwm is a short name for the internal X window manager for xwayland. Weston can run without xwm but it cannot run without a shell plugin. The shell plugin interface has a finite set of control through a loosely defined API. The shell plugin handles many of the requests and sends many events related to window management, to do things such as maximize and resize.

The shell plugin can manipulate surfaces in certain ways such as, translations, transforms, alpha, or any other already-supported compositing feature found in the main weston binary. Weston core compositing functionality is primarily found in src/compositor.c. The compositor handles the actual damage/attach/commit calls and works with the backend to yield a final composited result, typically to present on an output device.

The backends are also shared objects loaded by the compositor. It gives the compositor an output set or, rendering target. The backends are basically utility function sets that allow weston to render in a context the backend provides.

In order to do different things with weston surfaces, you have to touch the relevant code and make it do what you want. My goals include producing a wayland compositor that is simple, usable and fun to use at the same time. Specifically, my goals include things like additional animations or effects, not at all unlike the functionality certain popular compiz plugins have brought to X.

This includes but are not limited to:

1) Live Minimized Window Previews - This is useful but not easily doable with X protocol without some hacks.
2) Minimize Animation - Instead of a surface simply disappearing when minimized, you could create a more aesthetically pleasing transition.
3) Additional protocol - It might be useful to separate maximize calls into 'maximize vertically' and 'maximize_horizontally' for instance. There is also a new close event, to allow closing a single surface of a client as opposed to killing the entire client which subsequently destroys all related surfaces.
4) Candy - You can create all kinds of effects with gles2 shading language.

These are only a few examples of my ideas but they are probably the most relevant to the reason for the split. The first two are seemingly fine. This can be done in a new shell plugin, right? Unfortunately the fact of the matter is, that the core wl_shell_surface interface found in the core protocol has no minimize events or request, at all.

The wl_shell_surface interface is the protocol that defines the events and requests needed for basic window-management-like communication. All wayland clients use it except X clients. X clients do not use entirely different functionality but instead call into the shell plugin in order to relay surface communication, from a special interface in the compositor.

Two things are to be noted here:

1) Some preliminary maximize protocol exists but without a way for the compositor to tell the client to maximize, only the other way around. The missing case is one that must be satisfied if you want to have a special client such as a dock or panel, communicate via local compositor protocol and allow a way to control the surface in response to menu clicks, for example. Conversely, if the missing core protocol is implemented in a localized way, each client using this standard would have to support this protocol. This would cause more division than if the protocol is standardized in core wayland.xml because the clients would have to support a specific compositor's interface instead of using the core shell surface protocol designed for all wayland clients to use.
2) In the likely event such protocol is pushed upstream to suit the purposes that the northfield repository provides as a wayland protocol, this particular repository would become obsolete and there would no longer be a need to maintain toolkits and other clients separately in addition to the core library. Regardless of the eventuality, The Northfield Project, an umbrella under which a community, a compositor and other related components are housed, will continue to grow and thrive.

Naturally, my initial intent was that I wanted to see the code accepted upstream after proper review. This is how it's worked for the past year and it hasn't been too much of a problem. However in this case, there was a known technical problem that was exposed by my minimize implementation. Minimized surfaces were not receiving frame events in my implementation. This causes a program that is rendering, say a video player, to stall when minimized and rush-to-catch-up upon unminimize. This is nothing new because I've ran into this problem before several months ago when doing the weston-control experiments. I discussed this with Pekka and others at the time but we didn't really come up with any solution. The cause for the problem itself was clearly in my choice of implementation but my question regarding frame events specifically and how minimize should be implemented in a better way wasn't answered until recently by Pekka Paalanen (see here; the very last paragraph is most relevant). It's no secret that eglSwapInterval() is not implemented in Mesa and needs to be. Not only for this reason here, but also because other EGL applications need it too. One such example is SDL2. Since my recent attempt to get SDL2 wayland backend ready for SDL upstream at Kristian's suggestion, I have noticed some SDL2 applications flickering constantly and I am fairly confident that this is directly related to the problem (see here and here). I hope that we can get eglSwapInterval() working before SDL2 wayland backend is upstreamed. Otherwise, there will be many broken applications. The SDL developers are finally ready to release SDL2 after all this time but this problem needs the proper attention to ensure every-frame-is-prefect quality, as one of wayland's primary advertised features. In addition, it will require testing after implementation and may require other changes to support eglSwapInterval() and vet it properly. The current glxSwapInterval() implementation works correctly. This problem only exists when rendering using SDL video backends that utilize EGL. The GLX paths are unaffected so the problem is not yet prevalent.

Latest Linux Hardware Reviews
  1. A Walkthrough Of The New 32 System Open-Source Linux Benchmarking Test Farm
  2. Habey MITX-6771: Mini-ITX Board With Quad-Core J1900 Bay Trail
  3. OCZ Vector 150 SSD On Linux
  4. Noctua i4 CPU Cooler: Great For Cooling High-End LGA-2011v3 CPUs
Latest Linux Articles
  1. AMD Kaveri: Open-Source Radeon Gallium3D vs. Catalyst 14.12 Omega Driver
  2. 12-Way AMD Catalyst 14.12 vs. NVIDIA 346 Series Linux GPU Comparison
  3. AMD Catalyst 14.12 Omega Driver Brings Mixed Results For Linux Users
  4. 6-Way Winter 2014 Linux Distribution Comparison
Latest Linux News
  1. LLVM 3.6 Will Be Branched Next Month
  2. Opera Browser Puts Out Linux Updates For The Holidays
  3. GNOME Shell 3.15.3 Adds Support For High-Contrast Themes
  4. Linux 3.19: ThinkPad Muting Redone, New Dell Backlight Support, Acer Is Banging
  5. KVM Drops Support For IA64 While Adding Various x86 Improvements
  6. GCC 4.8.4 Officially Released
  7. FSF's High Priority Project List Now Has A Committee
  8. Details On Using OpenACC & GPUs With GCC
  9. Ubuntu 15.04 Alpha 1 For Its Various Flavors
  10. Git 2.2.1 Released To Fix Critical Security Issue
Latest Forum Discussions
  1. XLennart: A Game For Systemd Haters With Nothing Better To Do
  2. The New SuperTuxKart Looks Better, But Can Cause GPU/Driver Problems
  3. Debian init discussion in Phoenix Wright format
  4. FPS capped on Linux (AMD fglrx drivers)
  5. Are there an app using HSA ?
  6. Bench specific mount point
  7. Tool for measuring FPS in games
  8. Need some hand holding with upgrading xserver