Why Wayland & Weston Were Forked

Written by Scott Moreau in Software on 29 March 2013 at 02:05 PM EDT. 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.


Related Articles