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.

ponedjeljak, 4. srpnja 2016.

Week 6: DRM Backend, Fullscreen Shell and a Test Suite

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.

ponedjeljak, 27. lipnja 2016.

Week 5: Output unplug journey

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.

nedjelja, 19. lipnja 2016.

Week 3 and 4: Starting with zero outputs: Done

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.

nedjelja, 5. lipnja 2016.

Week 2: Getting weston to work with zero outputs

While this week was also busy, I still have managed to get some work done.

This week, my goal was to get weston to run when there are no outputs present. Fixing this mostly required adding a couple of null pointer checks to prevent weston from crashing.

However, this also introduced some problems. When an output is NULL, weston subsurfaces don't get mapped correctly. Currently, the code for configuring a subsurface will assert when the output list is null and that leads weston to a crash.

Pekka pointed out in order to solve this, I need to fix mapping functions not to rely on an output member, which I will be working on in the following days.

Also, attaching an EGL or DMABUF will result in a crash when no outputs are present. I have tracked this down to a call to image_target_texture_2d. This might be a bug in Mesa's EGL implementation. So far, I've made the function abort attaching in case there are no outputs, but I need to find a way to reattach it when an output appears. Otherwise, nothing gets displayed.

With the fixes from above, minus the problems mentioned, weston seems to handle zero outputs nicely. I have tested all of the weston demo apps and they start with no outputs present and get displayed correctly when an output gets attached.

My goal for the next week is to fix all of the issues mentioned above and make weston behave correctly when an output gets removed at runtime.

nedjelja, 29. svibnja 2016.

Week 1: A simple testing framework idea

So, here goes the first week of the Google Summer of Code coding period.

It was another busy week, and a lot of school and other activities have taken most of my time. So far, I've only managed to write a small amount of code to demonstrate my idea.

The goal for this week was to get a testing framework up and running. Truth be told, it was a bad idea to put this on a list as a first item. I have managed to get weston ready for the testing framework, but I'm unable to wire it up (or rather, verify that I've correctly wired it) due to weston not yet working without any outputs.

Still, I'd like to discuss what I've done so far.

Weston already has its testing framework, and most of the tests are run on the headless backend, a backend that has a fake input and output device. I have added a new command line switch to weston that allows me to tell the headless backend to not create any virtual outputs. This comes in handy for emulating a zero outputs scenario in the test suite.

But, it's not just starting with zero outputs present that needs to be tested. I also need to test a scenario where no outputs are present at start, but an output is plugged in later. I also need to be able to remove outputs and plug them back in at any time in order to emulate a real-life hotplugging scenario (ie, bad connector).

Weston test suite has a helper module,, which is loaded into weston to help test certain internals that couldn't be accessed otherwise. This means that I can use this module to control weston outputs. While using the mentioned module, it was easy to remove all outputs at runtime, but the problem was: How to get it back?

Since the headless-backend supports only one (or none) output(s) at the moment, I've decided to reuse that one output as many times as it's needed. This required me to expose some of the internals of the backend, meaning that any module that's plugged into weston might be able to control such internals. But since headless backend is mostly used as a testing backend, I don't think this will pose much of a threat to anyone. Still, I need to discuss this approach with Pekka and other people involved in the project.

To summarize: I have modified headless backend so it's able to start with no virtual outputs and exposed some internals so I can manually plug a virtual output into the headless-backend from the testing module. I have verified that the code works, but I haven't yet wired it up due to not knowing where it should be, as weston doesn't yet work when starting with zero outputs.

Lets hope next post will be more exciting.

ponedjeljak, 23. svibnja 2016.

First Post

This will be my blog to report on progress for my Google Summer of Code project, Output Improvements for Weston, the Wayland compositor.