I was doing some housework over the weekend and lost track of time. It might sound silly, but I thought yesterday was Saturday. That happens here when I go on Summer Vacation. But well, 24 hours isn't that behind, no? :)
Now, on to business. As mentioned in my previous blog post, I submitted my first batch of patches for review. The review was done quickly by my two mentors, Pekka and Quentin, so the second batch was already on the list on Wednesday.
Once that was done, I was exploring what was necessary to get weston to work when all outputs get unplugged at runtime after at least one was plugged in during the session.
The first thing I did was get the testing environment ready. I wrote a small module which weston loads at runtime and unplugs all outputs in the X11 (theoretically, in any backend, as there is no backend specific code) backend. The module initiates a timer, and only triggers the unplug after the timer counts down to zero. I set the timer to allow me to start a couple of test programs before all outputs disappear. So far, it has served me well.
By doing that, I uncovered one minor problem in the X11 backend. When I manually unload the outputs, X11 window(s) representing (each) output remain there, but frozen. The problem was that an xcb_flush was missing in the output destroy handler, but was called from the "x" button handler (close button).
Once that was fixed, I went on with testing. With help of another testing backend that I wrote in the past (this one is strictly X11 backend specific) which allows me to hotplug an X11 output after certain amount of time, I had a perfect "output unplug, output plug back in" scenario with the X11 backend.
After that was in place, and I started running tests, the crashes happened instantly after an output was unplugged and then plugged back in. The problem was that the views (objects which represent visible part(s) of a surface) were still using old (destroyed) outputs, and nothing was updating them. My idea was, when plugging in an output and there were no outputs present before, to simply force-move all views to a new output. This was simple enough and it just worked. At least I didn't notice any problems.
However, Pekka suggested that views shouldn't be force-moved to a new output only after new primary output gets attached. Instead, it should be done when any output gets attached just in case a surface happens to be in a region that's not part of the new primary output. By doing that, we would ensure that all surfaces remain displayed after a number of outputs gets unplugged and plugged back in. I still haven't considered this, but I'll sure take a look at it. I just need to verify if my testing environment can test this scenario.
That was my small journey last week. I didn't do anything else because, as mentioned above, I was doing work around the house and had family over. I still didn't finish the mentioned work, due to unpredictable complications that happened, but should be done by tomorrow, or in the worst case, at Wednesday.
I don't want to repeat myself regarding my goal for the following week. I already outlined in my previous post that the goal was to get the first part of GSoC done by end of the month. That's this week (well, it does stretch to the fist 3 days of July too), and I hope I can keep up on my promise (I'm looking at you, unexpected problems!).
And finally, last week was Midterms Week for GSoC. I hope I passed and will be able to continue to work on weston for the rest of GSoC.