nedjelja, 21. kolovoza 2016.

Summary

And so, GSoC has come to an end. In this post, I'm going to describe what I have done in the past 13 weeks.

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 [1] and [2] about two different approaches I was working on. The final code (unfinished) can be found at [3].

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 [4] and [5].

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 [1], [2] and [6].

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 [1].

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 [7], [8] and [9].

Everything described so far can be found in my github repository, gsoc-final branch found at [10].

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 [11]. Code available at [12].

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!

[1] http://armin-gsoc.blogspot.ba/2016/07/week-6-drm-backend-fullscreen-shell-and.html
[2] http://armin-gsoc.blogspot.ba/2016/07/week-7-review-feedback.html
[3] https://github.com/krezovic/weston/commits/gsoc-v5-testing-backend?author=krezovic
[4] http://armin-gsoc.blogspot.ba/2016/06/week-2-getting-weston-to-work-with-zero.html
[5] http://armin-gsoc.blogspot.ba/2016/06/week-3-and-4-starting-with-zero-outputs.html
[6] http://armin-gsoc.blogspot.ba/2016/06/week-5-output-unplug-journey.html
[7] http://armin-gsoc.blogspot.ba/2016/07/week-10-journey-to-new-output.html
[8] http://armin-gsoc.blogspot.ba/2016/08/week-11-outputs-outputs-and-more-outputs_5.html
[9] http://armin-gsoc.blogspot.ba/2016/08/week-12-even-more-outputs.html
[10] https://github.com/krezovic/weston/commits/gsoc-final?author=krezovic
[11] http://armin-gsoc.blogspot.ba/2016/08/week-13-end.html
[12] https://github.com/krezovic/weston/commits/gsoc-v11-output-layout?author=krezovic

Week 13: The End

And so GSoC comes to an end. This last week was still dedicated to new output API design. We had to go through at least one more iteration of the patches. Unfortunately, we missed weston 1.12 feature deadline, and the code won't land anytime soon, at least until weston 1.12 has been released. The latest code can be found in gsoc-v11 branch of my git repository.

Link: https://github.com/krezovic/weston/commits/gsoc-v11

But, that isn't all. I spent last night trying to get output layout configuration to work. It appears that even though I refactored the original API a number of times now, it appears that it requires at least one more iteration to make some modifications required for the output positioning to be moved out of libweston.

I was kinda in a hurry, so I squashed everything into one single commit. I'm not going to submit that part for GSoC evaluations, so it lies in a side branch, gsoc-v11-output-layout.

Link: https://github.com/krezovic/weston/commits/gsoc-v11-output-layout

The functionality is not that advanced. One can specify a output in weston.ini that the current output should be placed to relatively, either right of that output, or left of that output. This can be done for as many outputs as there can be. However, if a certain output appears twice in the configuration as a relative output, only the first output will be positioned next to the relative output, while every other output will be placed top right. Same goes for all outputs that have no configuration specified, which is also the current behavior.

The code was tested with X11 backend and 6 different outputs and different placements, as well as with DRM backend and Internal Laptop Panel/HDMI TV.

The GSoC is comming to an end, so I won't finish this just yet. I have two exams pending next week, so I'll take a break. But as soon as that's done, I'll get back to getting the previous series ready for merging as soon as I get the time, provided Pekka reviews series that are currently on the list. I expect at least one more revision, even without the fixes required to properly support configuring layout outside of libweston.

So that's all for now. Following up is a recap of what I've done this summer.

nedjelja, 14. kolovoza 2016.

Week 12: Even more outputs

Nothing special this week either. The new output configuration API is still under review. So far, I jumped 2-3 new revisions since last week.

However, the week wasn't so boring after all. Even though I had to rewrite parts of the series several times throughout the week, that wasn't all!

Some patches that were implemented before Pekka went for vacation were left floating around and he has finally reviewed them all. Some patches required a rewrite or two, but they're all merged now!

Those patches included fixes for the fullscreen shell to work properly with zero outputs and no output resource, fix for a crash in weston animation code when no output is assigned to a view, making EGL_NO_SURFACE/PBufferSurface current in gl-renderer when all outputs are gone and handling weston_view output reassignment when all outputs are gone and new one appears after.

On Thursday, I've finally sent my series to mailing list so wider audience can participate if they want. Today, I've improved everything that was asked during the review of the API and resent v2!

Hopefully, this will mean that I won't need to change the API anymore, which needed to be done once again this time. The backends however didn't receive in-depth review, but I hope they will do so during the next week!

Next week is final GSoC week, and I still have to implement output layout configuration. As promised, basic output layout configuration will be implemented (left of certain output, right of certain output) as a part of GSoC, and we can implement the rest later. As soon as I get the green light that API doesn't need to be changed, I can comence on my work. Hopefully that will be done tomorrow!

As usual, all changes can be found on github, now in gsoc-v10 branch (yay v10!).

Link: https://github.com/krezovic/weston/commits/gsoc-v10

Stay tuned for seazon finale next Sunday!

petak, 5. kolovoza 2016.

Week 11: Outputs, outputs and more outputs

Usually I tend to be late when it comes to blog posts, but this week even I'm surprised how early I got to write a new post. Main reason behind this is that I've worked during these past 5 days more than any whole week previously. So, I decided I call it a weekend now and wait for next week when Pekka is available, so we can continue working on this.

So, what did I do this week? I continued working on new output configuration API, as mentioned in last week's post. I'm not going to go over details on how it works or what does it do, as that was explained in my previous post.

Both of my mentors were quick to respond to my previous work, and provided valuable feedback on the patches I wrote during the past week. So far, I believe I had to do at least 3 bigger rewrites to get somewhere (and a couple smaller ones). Today, I've finished porting all of the backends that weston supports to the new code. But since Pekka isn't available during the weekends, I won't have much to do until he gives me the green light about the current series (rewriting stuff isn't fun, really). So, until my mentors properly review my current code, I'll take a short vacation.

I hope we can get it ready before end of next week, so I can focus on writing layout configuration API, which is the final task on my GSoC TODO list (well, there's the testing suite too, but so far I have no idea how that would work or how to implement it, so I'll postpone it post GSoC). The current code can be found in gsoc-v8 branch of my git repository.

Link: https://github.com/krezovic/weston/commits/gsoc-v8

That'd be all for this week. This blog post is quite short, but nothing new was done that needed special explanations. If it was done past week, it would've been far longer. So long, until next week.