nedjelja, 21. kolovoza 2016.


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!


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.


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.


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!).


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.


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.

nedjelja, 31. srpnja 2016.

Week 10: Journey to the new output configuration API

As mentioned in the last week's post, I've been trying to write an API for libweston that can be used to configure an output outside of libweston. This week I made a lot of progress. By combining code from previously failed attempts and feedback from both of my mentors, I believe I have finally written an acceptable API (at least by my standards).

So, how does it work? Current model works like this (I'll make an example with DRM and X11 backends, as those are ones I've worked with most):

The DRM backend initializes outputs present at runtime and implements output hotplug using udev. To use a DRM output, backend does a lot of magic (which I don't understand fully, to be perfectly honest). Then it calls a function that needs to be written when writing a compositor (not part of libweston), which will then obtain preferred output configuration and does some more magic to make the picture appear on your screen driven by the DRM backend.

For X11 backend, compositor (libweston user) tells how many outputs should be configured and then the backend creates a number of outputs, whose configuration is either read from the configuration file, weston command line or hardcoded defaults.

This seems to work just fine. So, why bother writing a new API for configuring those outputs? It enables compositors to enable/disable/reconfigure outputs at will, implement configuration dialogs for more fancy output configuration, etc. Another reason that's important to me is to move output layout configuration from libweston, so compositors can choose to implement whatever layout placement they want.

The new model consists of these steps:

- When an output gets plugged in (or is  "created" in case of backends such as headless, X11 or wayland), a backend creates an object representing that output, but doesn't fully initialize it like it was done before. It only initializes parts that are needed so an output can be cleanly configured or destroyed.

- A compositor is then notified that an output is created, and basic output is passed as the data which can be used to aid in configuration. At the moment, only data that's needed from the output object is its name, as the configuration is mostly done on per-output-name basis.

- Using plugin-registry, compositor calls corresponding function that's tied to the backend and tells it to configure an output using the desired configuration. Output can also be dropped, if it seems unnecessary.

This isn't much different from what DRM backend does presently: Detect an output -> Do a little magic to get the necessary data to ask for configuration -> Get its configuration from the compositor -> Configure the output. Only now, the user (libweston user) has the power to configure the output the way he sees fit. Of course, it's limited at the moment, but it can be extended, and it doesn't need to be generic or backend agonistic since it's exposed through plugin registry.

I hope I made some sense. I'm really tired and it's past midnight here. But it sure was fun working on this. So far, I've done the initial API and ported 4 backends to it: X11, fbdev, headless and DRM. Two backends remain: RDP and Wayland. I was looking at the wayland backend, but I need some more time to figure out how it really works. As for RDP, I might have a hard time there, as I don't know how to test it, given that I don't have the needed tools for it. All the code is in my git repository, which can be found at so it's not just talk this week. I hope I can get this done in the next week and move to the final task in the remaining week of GSoC - configuring output positions.

ponedjeljak, 25. srpnja 2016.

Week 8 and 9: Nothing special

While I expected to work full time on the project as soon as summer holidays started, I didn't take into account some things. Last week, I didn't write a blog post beacuse I wasn't at home from Saturday evening to early Thursday, and also had an exam this Thursday.

Over the past two weeks, I've been trying to write an API for libweston that can be used to configure an output outside of libweston. Currently, when a backend receives an output connected signal (ie, DRM backend), it will first call the compositor defined function to receive a desired configuration for the output (if any), and then configure the output in the backend itself. Backends such as X11/Wayland/Headless have different approach. Since they don't depend on real hardware (I like to call them virtual outputs), outputs are created when the backend is started and there can't be more outputs plugged in at runtime (at the moment), but can disconnect an output in case there's more than one (closing X11 window representing an output will destroy that output).

What I was trying to do over last two weeks is (roughly written) to make the backends notify the compositor when an output gets connected, and let the compositor configure the output by calling backend specific functionality used to configure an output. And that's where it all began.

The first idea, written week before last, was to introduce a weston_pending_output structure, and initialize it with output name, default options and function pointer that can be used to configure it, and notify the compositor process that the output has been created. The compositor then would call the output configure function with choosen parameters or let the backend use defaults passed at runtime. The idea wasn't that good because the defaults were in the backend, and they shouldn't be there. I was then suggested to try using the new plugin-registry API to expose the configuration.

The second idea, similar to first, was to expose all backend functionality in the plugin registry and
let the compositor and libweston use that for manipulating the backends and options. Now, that wasn't really necessary, as that wasn't the original intended use for plugin-registry. The plugin-registry was intended to be used outside libweston for functionality that libweston can't directly provide for different reasons (different backends having different configuration options is just one example).

Even after I was explained what was plugin-registry about, I took a third approach, and still didn't get it right. The idea was still the same as the first one (backend creates the output, notifies the compositor, compositor configures it by calling backend specific function). Only this time, I reused weston_output instead of using weston_pending_output, but still exposed too much unnecessary things through the registry. I once again misunderstood the use of plugin-registry and tried to write generic configure functions for all backends that are exported through the registry. This contradicts what I've written above about plugin-registry (and I just realized that this morning when Pekka once again explained the purpose of registry to me).

This morning, we have come to a conclusion that the original idea is right, but the API still needs to be properly designed. So far, I have no code in the repository to show (I had several patches on pastebin sites shared with both of my mentors; Pekka and Quentin "SardemFF7"), but I belive all three of us finally agreed on how it should be done - so I have a task for this week. But hey, libinput api was modified several times before they got it right, so that gives me hope that I'll do the same for the task I was appointed. Stay tuned.

nedjelja, 10. srpnja 2016.

Week 7: Review feedback

I haven't spent this week working on anything new, but rather on polishing the existing patches I've written over the past two weeks.

First task that I was working on is reworking how views behave when all outputs were gone. In a post from two weeks ago, I pointed out how I got that to work back then. Now, thanks to Pekka's review, I took a different approach. Instead of forcing all views to assign an output when a first output gets plugged in after all outputs were gone, I simply mark all the views' geometry as dirty, so weston will take care of updating the transformations and assigning an output.

Second task was about reworking my patches for fullscreen shell and zero outputs scenario. Again, thanks to Pekka's feedback, I changed my patches from last week to have more code sharing, preserve the surface only when no output resource was given and implemented destroy callbacks for the preserved surface so it can be removed from preserved surfaces list once the client destroys it.

The final task for this week was working on the testing environment. While I did good amount of work last week, I lost some hours trying to integrate my work from the past week. That didn't go well and Pekka didn't like me using timers, so I threw that code aside.

With hints from Pekka and Quentin "SardemFF7", I completely reworked the testing environment and extended the testing protocol, so a client can itself control whether an output should be hotplugged or unplugged, and receive information on whether that's done. Doing this proved to be a bit harder than I expected, but I did learn how wayland protocols are written and implemented in compositor, so in the end it was totally worth it. However, the testing environment isn't yet ready. I need to fully integrate the tests in the weston-tests-env and disable/rework some tests under zero outputs scenario, so I can get acceptable results.

This went on a bit longer than I expected, but I think I can finally concentrate on second part of my GSoC proposal, which includes output position configuration using weston.ini. Pekka's tasked me with reworking big chunk of weston code, so all backends can share more code and so I can implement my task easier, instead of doing so in all the backends separately. Since Pekka's still on vacation, I'll be working with my other mentor, Quentin "SardemFF7". I really hope I can get the early prototype with at least one backend during the next week. Stay tuned.