In my project proposal I proposed (roughly) the following tasks to be ironed out during the GSoC:
- Make weston start without any outputs.
- Make weston survive all outputs being unplugged at runtime.
- Write a test suite that ensures the behaviour above doesn't break during the future development.
- Make weston able to configure output layout using a config file.
Well, what did I do?
The first two tasks were accomplished entirely, and weston 1.12 will be able to start with no output present and survive if all outputs get disconnected at runtime. Yes, it has already been reviewed and merged upstream!
The third task was unfortunately not done. It was because I lacked an idea of how to implement it and what to test at that time. Ever since those two failed attempts, I have moved on to the fourth task, with the idea to get back to this one, but the fourth task took longer than expected, and I have unfortunately ran out of time. You can read  and  about two different approaches I was working on. The final code (unfinished) can be found at .
Fourth task took an unexpected turn. In order to get output layout configuration outside of libweston, Pekka advised me to rework lots of weston code and move output configuration from libweston to compositor itself. This required adding and refactoring large amount of code, and took many iterations to get that right (and I believe it still isn't ready for merging).
So, how did I make weston work with zero outputs at startup and at runtime?
There were several issues that needed to be taken care of. Before my work started, lots of places in weston assumed an output is always present. Removing all outputs, or starting without any outputs would lead to instant crashes. Biggest problem of all was that weston assumed a surface (view) was mapped (read: ready to be displayed) if it had an output assigned. At that time, it made sense, as you can't display something if it has no output assigned. But, that was rather problematic, because certain programs wouldn't continue working properly when no output was present at startup because some parts of protocol implementation were checking if a surface (view) is mapped to preform certain tasks. To fix this, I introduced a "mapped" indicator for both surfaces and views, and set them manually for surfaces (views) that weston and its shells create. Weston also left gl-renderer in half-broken state when no outputs were given at startup, which prevented the renderer from fully utilizing EGL. An issue in weston-keyboard was also fixed that prevented it from starting when no outputs are present. For details, consult  and .
After weston was able to properly start without any outputs present, I focused on fixing weston so it can remain running after all outputs have been unplugged at runtime, and plugged in again. Biggest problem that needed to be sorted out is when all views (part(s) of a surface that (is/are) to be displayed on a certain output) were in a output present; all outputs gone; new output connected scenario. This lead to views relying on non-existend output (using dangling pointers), mainly because nothing was there to assign a new output after it has been assigned once, which would lead weston to crash. This was fixed by marking all views as "dirty", so compositor will take care of assigning a new output, if necessary. Another issue was that weston animation code would lead to crash after an output assigned to a view was gone, and the animation code tried to use it. This was fixed by simply letting the animation code complete instantly rather than being assigned to an output and displayed.
A couple of smaller fixes were also needed, such as preventing the drm backend from shutting down the compositor when all outputs get disconnected or when no outputs are connected at startup, as well as having the gl-renderer always have a (EGL_NO_SURFACE/PBufferSurface) EGLSurface assigned to the current thread. More details can be found at ,  and .
Then there was the fullscreen-shell. Fullscreen-shell is a minimal shell which can only run one fullscreen client at a time. It was relying on an output to be present at startup if output resource wasn't given to the surface create command. Detailed explanation on how this was fixed can be found at .
The final task took an unexpected turn. In order to make it easier to configure output layout, I was advised to move all output configuration from libweston and the backends to the compositor itself. I made use of recently added plugin registry to expose configuration for different backends, which can be used from a compositor to configure outputs in a way suited for them. I also added some backend independent functionality for configuring options such as output scale and transform and ported all the backends currently available in weston to use the newly added functionality. For detailed explanations on what was done on that front, consult ,  and .
Everything described so far can be found in my github repository, gsoc-final branch found at .
But that's not all. Remember how the final task was to enable weston to configure output layout using config file? Well, I did some work there too. It's rather a rough draft, but it seemed to work, at least during my testing on X11 and DRM backends. Detailed information at . Code available at .
That's all folks. I also wish to thank the Wayland Project and my mentors, Pekka Paalanen and Quentin Glidic, for allowing me to participate in GSoC under their umbrella, as well for aid they've given me and knowledge they have passed onto me during these past 13 weeks.
So, what else to say? I still plan to finish what I started, meaning that I'll work on layout configuration and new output API until it's merged. So long, and thanks for all the fish!