First of all, I want to thank the Wayland Project and my mentors, Pekka and Quentin "SardemFF7", for letting me pass the Google Midterms evaluation. That means that I'm still participating in GSoC and can continue my work.
Also, I'm proud to say that most of my work that was submitted was merged to weston master. So, if you are using weston git master, you should get working "zero outputs setup at startup" feature when using X11 backend and desktop-shell.
The past week was dedicated to ironing out remaining output hotplug and unplug at runtime issues with the things I never had the chance to touch before. That includes the DRM backend and fullscreen-shell. I've also started to prototype a test suite.
The DRM backend was easy to fix. It was already working, but had some codepaths that would make weston fail/exit when it hits zero outputs case, whether at startup or runtime. Removing those code paths fixed all the issues I've previously encountered during testing.
Fullscreen Shell was different story. A fullscreen surface was always tied to an output object and can only be created and configured when a fullscreen output object is present. And when all outputs are gone, the surface gets unmapped (because it doesn't have any more views associated to an output), and there was no way to display it again when an output gets back.
To overcome all this, I had to resort to preserving the surface manually in the shell process and remap/reconfigure it after an output gets attached, so it gets properly displayed. I'm not sure if this was the right solution, but it's the one that currently works, for both zero outputs and startup, and all outputs gone at runtime then one gets reconnected situations.
Another minor task which I've done, but haven't yet mentioned is a little more work on the gl-renderer. When using an output to draw stuff, gl-renderer makes the EGLSurface associated with an output current so all GL calls are being done on that surface. But what happens when all outputs are gone? What surface is current then? I wasn't really sure. So, to avoid any potential issues, I reused the dummy surface that was used to create a EGLContext at startup and make that surface current, so all future GL calls are using it, until an output gets attached. I want to note that I didn't notice any problems without the mentioned feature, but I still think this was the right thing to do.
And finally, the last feature I was working on last week was the testsuite. So far, I've only got the code parts finished and have yet to wire it up. But, the code changes include modifications to the headless backend to expose additional functionality, so a module can create an output and emulate output hotplug scenarion. This functionality was hidden behind a CPP define, so it doesn't always get built into the headless-backend. To avoid messing with the headless-backend which gets installed, I introduced a new, headless-testing-backend (which is headless-backend plus the mentioned functionality) which will be used for the testsuite instead of headless-backend, which is currently being used.
When that was done, two new testing modules were written; A module which emulates output hotplug in the headless backend by using the functionality previously mentioned and a module which emulates output unplug, by removing all the outputs that were present. Both modules use timers to do their job, so I had a hard time thinking how to get them wired up. I have to discuss this with someone who better understands the weston test suite.
That's all what was done this past week. This week I expect to finish the test suite integration and submit this part of my work to review and then start working on part 2 of my GSoC project. Stay tuned.