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
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.