First of all, I apologize for not writing a blog post last week. The thing is, I had many exams this week and spent the week before studying, so I didn't manage to tackle anything that was worth reporting.
While I didn't manage to complete my goal that I set before myself two weeks ago, I still did some work (largest amount yet) that's worth reporting. To be clear, I didn't manage to look at how to make weston behave when you unplug an output. The rest of what I set to do last week was done this week.
Now, on to business. This past week I spent a number of hours trying to tackle an issue in subsurface implementation that happens when a program that uses subsurfaces is started when no outputs were there. The issue was that a subsurface wasn't rendered properly and instead of subsurface, a main surface was rendered in its place. After hours of unsuccessful debugging, my mentor, Pekka, hinted that it might actually be an issue in gl-renderer. He was right.
Two weeks ago, I hinted at a problem when weston was started with zero outputs on how it would crash when an EGL extension is being used. The thing is that EGLSurface which was used for displaying rendered content was tied to an output, and only when an output gets plugged in, an EGLSurface would get created and there would be something you could an EGLContext to with eglMakeCurrent
Pekka gave me two ideas on how to solve this problem.
First idea was to use EGL_KHR_surfaceless_context if it was available. When EGL_KHR_surfaceless_context is available, eglMakeCurrent can attach EGLContext to EGL_NO_SURFACE.
The second idea was to use a PbufferSurface, a dummy surface which will always be created at gl-renderer initialization and can be used instead of EGL_NO_SURFACE when calling eglMakeCurrent.
In the end, we settled for both; Use EGL_KHR_surfaceless_context if available, otherwise fall back to using PbufferSurface. By doing that, the issues in subsurface implementation and crashes when creating an EGL or DMABUF were gone.
But, that wasn't an end to subsurface issues. Another problem was that weston used outputs to indicate that a surface or a view is mapped. A mapped view or a surface is a view/surface which is ready to be displayed. The current logic is that if a view or a surface had an output assigned, it was ready to be displayed. That of course wouldn't work when there is no output present. So, I had lots of checks that were checking if a surface or view were mapped failing, which lead to another issues, especially in subsurface implementation.
In the end, I had to introduce a new, output independent check for checking if a surface or a view is mapped and change all the places that did the actual mapping to operate on new variables. That required me touching the compositor and various shells' code, but I managed to do it, and with that, solve all my problems with all demo applications.
But journey doesn't end there just yet. An issue that I didn't mention, but that was there ever since I got weston to work with zero output is weston-keyboard failing to start. When setting up a virtual keyboard, it tries to set an input method as toplevel, and that setting depends on a valid output. Since there is no valid output at startup, it can't be set as toplevel and instead it would just crash. I solved the problem by moving the toplevel setting into a separate function and called it only if there was an output present at runtime or if there was no output present at runtime, but an output was created later. This seems to work just fine and I have yet to find any issues with this implementation.
That covers the three major things I was doing this past week. I am proud to say that I have submitted my work so far for a review. With the midterms closing in, both Pekka and I thought that I should present what I did up to now.
As for future work, I won't rush myself this time and say "I'm going to do this ... I'm going to do that". So far, everything I've set out to work on had a "side quest" for me. So, I'll just say that the plan is to finish the remaining work for zero outputs case before end of the month. That includes getting weston to behave on all outputs being unplugged at runtime, and of course, an automated test suite to test all this.
My last exam this month is on Tuesday (2 days from now), and after that I'll have all the time I need to work on weston.