Experiments with crosvm

Last week I played a bit with crosvm, a KVM monitor used within Chromium OS for application isolation. My goal is to learn more about the current limits of virtualization for isolating applications in mainline. Two of crosvm's defining characteristics is that it's written in Rust for increased security, and that uses namespaces extensively to reduce the attack surface of the monitor itself.

It was quite easy to get it running outside Chromium OS (have been testing with Fedora 26), with the only complication being that minijail isn't widely packaged in distros. In the instructions below we hack around the issue with linker environment variables so we don't have to install it properly. Instructions are in form of shell commands for illustrative purposes only.

Build kernel:

$ cd ~/src
$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
$ cd linux
$ git checkout v4.12
$ make x86_64_defconfig
$ make bzImage
$ cd ..

Build minijail:

$ git clone https://android.googlesource.com/platform/external/minijail
$ cd minijail
$ make
$ cd ..

Build crosvm:

$ git clone https://chromium.googlesource.com/a/chromiumos/platform/crosvm
$ cd crosvm
$ LIBRARY_PATH=~/src/minijail cargo build

Generate rootfs:

$ cd ~/src/crosvm
$ dd if=/dev/zero of=rootfs.ext4 bs=1K count=1M
$ mkfs.ext4 rootfs.ext4
$ mkdir rootfs/
$ sudo mount rootfs.ext4 rootfs/
$ debootstrap testing rootfs/
$ sudo umount rootfs/

Run crosvm:

$ LD_LIBRARY_PATH=~/src/minijail ./target/debug/crosvm run -r rootfs.ext4 --seccomp-policy-dir=./seccomp/x86_64/ ~/src/linux/arch/x86/boot/compressed/vmlinux.bin

The work ahead includes figuring out the best way for Wayland clients in the guest interact with the compositor in the host, and also for guests to make efficient use of the GPU.

Validating changes to KMS drivers with IGT

New DRM drivers are being added to almost each new kernel release, and because the mode setting API is so rich and complex, bugs do slip in that translate to differences in behaviour between drivers.

There have been previous attempts at writing test suites for validating changes and preventing regressions, but they have typically happened downstream and focused on the specific needs of specific products and limited to one or at most a few of different hardware platforms.

Writing these tests from scratch would have been an enormous amount of work, and gathering previous efforts and joining them wouldn't be much worth it because they were written using different test frameworks and in different programming languages. Also, there would be great overlap on the basic tests, and little would remain of the trickier stuff.

Of the existing test suites, the one with most coverage is intel-gpu-tools, used by the Intel graphics team. Though a big part is specific to the i915 driver, what uses the generic APIs is pretty much driver-independent and can be made to work with the other drivers without much effort. Also, Broadcom's Eric Anholt has already started adding tests for IOCTLs specific to the VideoCore-IV driver.

Collabora's Micah Fedke and Daniel Stone had added a facility for selecting DRM device files other than i915's and I improved the abstraction for creating buffers so it works for drivers without GEM buffers. Next I removed a bunch of superfluous dependencies on i915-only stuff and got a useful subset of tests to run on a Radxa Rock2 board (with the Rockchip 3288 SoC). Around half of these patches have been merged already and the other half are awaiting review. Meanwhile, Collabora's Robert Foss is running the ported tests on a Raspberry Pi 2 and has started sending patches to account for its peculiarities.

The next two big chunks of work are abstracting CRC checksums of frames (on drivers other than i915 this could be done with Google's Chamelium or with a board similar to Numato Opsis), and the buffer management API from libdrm that is currently i915-only (bufmgr). Something that will have to be dealt with in the future is abstracting the submittal of specific loads on the GPU as that's currently very much driver-specific.

Additionally, I will be scheduling jobs in our LAVA instance to run these tests on the boards we have in there.

Thanks to Google for sponsoring my time, to the Intel OTC folks for their support and reviews, and to Collabora for sponsoring Robert's, Micah's and Daniel's time.

Lucid sleep in the free desktop

For the past year I have been working on the kernel side to bring some ChromeOS features to upstream.

One of the areas I'm currently working on is what Google calls Lucid Sleep, which is basically the ability of performing work while the machine is in a low power state such as suspend. I'm writing this blog post because there has been interest on this in different communities and the discussion is currently a bit dispersed.

Small mobile devices have been able to do that since basically always and this feature brings it to bigger devices that traditionally have been either on or off. It's similar to what Microsoft calls InstantGo (previously Connected Standby).

Childhood Dream by theSong / CC BY-NC-ND 3.0

A few examples of tasks that the system could perform while apparently sleeping are:

• Checking if the battery level is so low that it would be better to completely power down the machine
• Starting a network backup if the present connectivity allows it (a known access point may have become accessible)
• Downloading email
• Checking for new instant messages

With regards to functionality and leaving performance considerations aside, userspace could implement this without requiring any new support in the kernel as illustrated in this scenario:

• We assume that a video is currently playing in YouTube
• User closes the lid
• PM daemon notifies userspace of an impending sleep
• Browser pauses playback
• Compositor switches off the screen
• Kernel freezes userspace, suspends devices and puts the CPUs to idle
• Time passes...
• RTC alarm fires off
• Kernel resumes devices and unfreezes userspace
• Userspace realizes there hasn't been any user activity since it went to sleep last, so stays in "dark resume" mode
• Userspace does any lucid tasks it wants, then goes back to sleep again
• Kernel freezes userspace, suspends devices and puts the CPUs to idle
• Time passes...
• User opens lid
• Kernel resumes devices and unfreezes userspace
• PM daemon notices the SW_LID event, so notifies userspace that this is a full-on resume
• Compositor switches screen on
• Browser resumes playback

No changes needed in the kernel is always good news, but there's two issues.

Lost input events

Sometimes the event from the input device that woke the system up gets lost before it reaches userspace, so we don't know if we can stay dark and do our lucid stuff, or if the user expects the machine to power completely on.

This is in any case a bug, but if it needs to be fixed in the firmware, we may not be able to do much about it. At most we could get the kernel to synthesize an input event, but sometimes it may not have enough information to do so.

Performance

When the system wakes up, there tends to be a lot to do in the kernel and userspace, so it could take several seconds for the screen to come up from the moment the user opened the lid in the scenario presented above.

For ChromeOS this isn't acceptable so they are carrying some patches in their kernel that make some shortcuts possible (the screen is left on at suspend time, and the kernel knows at resume time whether it has to power it on based on which was the wakeup source, thus not having to wait for userspace).

Fortunately, there have been some changes recently in the kernel PM subsystem that can speed up resumes quite a bit and we can make use of them to offset the penalty of dropping those shortcuts.

The first is idling the CPUs instead of suspending to firmware, which on modern SoCs should be quite efficient and much faster, by a few tenths of seconds.

The other is to leave idle devices that are already in a low power state alone when suspending, which means that we don't have to wait for them to resume when the system wakes up. In every system I have seen there's always a few devices that take a long time to resume, so this can shave several tenths of seconds from the total resume time.

Both need some amount of support in either the platform or in device drivers, and that's what I'm currently working on for the Tegra-based Chromebooks.

GNOME API reference at the DevX hackfest

Last week I spent a few days at the Developer Experience hackfest and got to have some fun again with the API reference generator in gobject-introspection.

Jon intended to hack on the XSLT stylesheets in yelp-tools/xsl, but after some trying he got discouraged by the amount of work that would take to get them to generate the HTML that we are interested in. We also discussed the benefits of using Mallard for generating the reference docs, and given that we want to generate a single output, we couldn't see much value in the level of indirection that Mallard adds.

Thus, we considered generating HTML directly from the GIR files, but shortly after Alberto Ruiz came by and offered to explore a client-side-only solution involving processing JSON files with JavaScript.

He very quickly got something relatively complete, which is very encouraging, but even more so is seeing how other projects are generating their API references that way, for example: http://docs.sencha.com/extjs/4.2.2/#!/api/Ext.Class

Aspects such as as-you-type search would bring the online documentation on par with the Devhelp experience. Plus they have some niceties such as a symbol browser and links to annotated source code.

I have hacked a (yet another) --write-json-files switch to g-ir-doc-tool that will output the content of the GIR file to JSON, but indexed and formatted as needed by the JS side of things. See this branch for the code.

That branch also adds support for Markdown rendering using python-markdown, but some more code needs to be written to implement the extensions to Markdown that the Gtk+ docs are using.

It was great to talk about all this and more with old and new friends in Berlin, so I'm very grateful to the GNOME Foundation for organizing it and sponsoring travel, and to Endocode for providing a venue. And special thanks to Chris Kühl for the great organization!

Multi-touch gestures in Mutter-based compositors

A customer has asked for documentation on handling multi-touch gestures in their Mutter-based compositor (see my previous post) and I thought that it could be a good idea to have it in the GNOME wiki, in case it helps when they are added to GNOME Shell:

Multi-touch gestures in Mutter-based compositors

I'm not sure of what would be the best use for multi-touch gestures in the Shell, probably for resizing windows (with a 4-finger pinch gesture) or for switching desktops (with a 3 or 4 finger swipe). Probably some ideas can be taken from the multi-tasking gestures in recent versions of iOS, such as using pinch gestures to activate hidden panels or to switch to another views.

Something I feel strongly is about restricting system-wide gestures to more than 3 fingers, because the user experience and the implementation gets quite complicated if the compositor and the applications need to compete for touch sequences in similar gestures.

It's currently a bit convoluted due to zero support in Mutter for touch events, but once the Shell starts using touch events, I think it will make sense to move some of the setup and boilerplate into Mutter.

Once more, thanks to my employer Collabora for sponsoring this work:

Multi-touch gestures in Gnome Shell

I'm keeping this small branch in which touch event support is added to Mutter. Plug-ins can register to get touch events before any other client and then accept or reject touch sequences depending on whether the shell is interested on the gesture or not.

As can be seen in this example of a mutter plug-in, any subclass of ClutterGestureAction can be used, which includes gesture recognizers for pan, zoom and rotate actions, but creating new recognizers is pretty easy.

The mutter branch is up for reviewing in bugzilla and any comments on the approach will be very welcome. And if anybody wants to play with multi-touch gestures in Gnome Shell, please link to your work from the wiki so we can track it.

If anybody from the design team has already started thinking about this, I would be very glad to hear their thoughts on this.

As always, I'm grateful to my employer Collabora for sponsoring this work, and I hope GNOME benefits from it.

Touch events within Xephyr

As part of my ongoing work on multi-touch, I have been looking at handling touch gestures within Mutter plugins. Developing a X window manager/shell can be quite a hassle because you are likely to want to do that in a separate X display so your testing doesn't disturb the session where you do the actual coding.

In the past I have used Xephyr to run a nested X display so I can run the window manager as I would run any normal application, but this time I found that Xephyr doesn't forward any XInput2 events right now, which is needed for MT. Having a separate machine where to test is an alternative but it has been quite uncomfortable.

My colleague at Collabora Daniel Stone encouraged me to give it a try and it indeed didn't take much work to get something running, though I still haven't tested it much.

So for the code, here is the Xephyr repo: http://cgit.collabora.com/git/user/tomeu/xserver/log/?h=xephyr-touch

And here the Mutter repo: http://cgit.collabora.com/git/user/tomeu/mutter/log/?h=touch-clutter

Remember that these are early proof-of-concepts, but if you give it a try and want to give feedback, it will be welcome.

As usual, thanks to my employee Collabora for sponsoring this work and letting me share it.

Multi-touch in WebKit-Clutter

Following my past work on multi-touch support in Clutter, have been playing lately in implementing the W3C Touch Events API in the Clutter port of WebKit.

A lot of code can be reused from WebCore without problems, but we'll need to do some mildly complex event translation because the W3C API and the one in Clutter (and in XInput and in Gtk+) are very different.

But for now, a quick demo of a web page drawing the touch events that it receives, limited to 2 touch points because that's the maximum supported by the hardware I have here:


This is still early work, but once event translation is done, this should be very close to be feature-complete. And a nice side-effect is that given that the touch API in Clutter is so similar to Gtk+'s, it should be pretty straightforward to port it to WebKitGtk+. You can find the code here, but please keep in mind that this is very preliminary work.

As usual, thanks to my employer Collabora for sponsoring this work.

WebGL support in WebKit-Clutter: Part 2

Following up on my work from last december, I have a branch of webkit-clutter that runs most of the WebGL demos that float around the web. The main differences are that the required new API has been accepted into Cogl and that there's a lot more code shared with the other WebKit ports.

Right now bigger applications are not working because of this bug which also affects the Gtk+ port, but hopefully it will be fixed soon.

The code lives in this branch and you will need this Cogl branch with a recent Clutter 1.10 release.

As before, thanks to my employer Collabora for allowing to work on this.

Multi-touch support in Clutter

Have been doing some tests regarding multi-touch support on Clutter and everything seems to be working fine:



You will need either a very recent master or clutter-1.10 branch because there was a bit of fixing needed, but hopefully that will get into a release soon.

That example can be find in ./tests/interactive/test-touch-events.c and can be run as:

$ cd clutter
$ ./tests/interactive/test-touch-events

Needless to say, you will need a recent Xorg (1.12) and support in the kernel for your multi-touch hardware.

Hope that soon I will be able to work on gestures support and automated tests for this.

Thanks for my employer Collabora for sponsoring this work.

Progress on generating Python API docs from introspection

The Docs hackfest in Brno is nearing to an end and I think enough progress has happened on generating API reference from introspection to warrant a report.

To see the current state, check the Telepathy-GLib reference generated here for Python.

Tomorrow morning will work on fixing some issues in the GIR files such as enum docs not making to it and then I will head home.

I'm not likely to work further on this, so if you think it can be of use to you, please consider lending a hand and contribute bugfixes and features. And if you don't like the design or the layout, just change it :)

Hope you have as much fun with this as I have had!

Once more, thanks to the GNOME Foundation, Red Hat and Collabora for sponsoring this work.

Below you can get a glance of what has been progressed on during these days, here is the changelog:

• Add some more stuff to Enum pages
• Display the hierarchy tree for classes
• Install the Mako template files
• Add AM_CHECK_PYMOD macro and use it to check for Mako
• Remove stale DocBook files
• Properly link to property pages
• Fix names of xref links
• Move constructor example to follow the class doc body
• Properly link to signal pages
• Fix the id of signal pages for Python
• Qualify the class name in the constructor with the module name
• Add links to properties in the constructor
• Fix link
• Show how to construct instances in the Class page
• Add details for properties in Python
• Add param information to signal pages in Python
• Implement intra-namespace cross references
• Use instances of MallardFormatter* instead of class methods
• Remove some occurrences of empty Returns: lines
• use True and False instead of %TRUE and %FALSE
• Remove module and class from the function signature
• Use template caching
• Use None instead of %NULL
• Use the ctype for the return type in signatures
• Display Returns: even if there's no args
• Update expected, some whitespace was removed
• Add Since: tag to classes
• Add Since: tag to mallard docs
• Add function argument docs to the C template
• Add argument docs to the Python template
• Don't instantiate MallardFormatter for unknown languages
• Update expected mallard for the doc tests

Docs hackfest: starting point

Have spent my trip to Brno undusting and rebasing the branch in gobject-introspection that uses to Mako templates to generate Mallard code from GIR files.

Here you can see how looks like the generated documentation for the Account class in the TelepathyGLib typelib for Python, and here is the one generated with gtk-doc.

As can be seen, there's still a long way to get even close to the gtk-doc level, but it's a very promising start.

Documentation hackfest in Brno 2012

Tomorrow I'm taking the train to Brno to participate in the documentation hackfest, with plans to continue the work on generating API documentation from the GIR files that are generated by GObject Introspection.

I will be continuing the work that a bunch of us started in Berlin during the GObject Introspection hackfest last year.

Will be giving as well a workshop on GNOME application development with Python and GObject Introspection as part of the Developer Conference 2012 that Red Hat is organizing there.

Thanks to the GNOME Foundation for sponsoring my accommodation, to my employer Collabora for sponsoring my time there and Red Hat for sponsoring the venue and the food.

PyGObject gets a splash of new blood

Things as they are, few hackers get to work on the same project their whole life. No matter how deep one has been involved in a project, and how much effort was put in, there are many reasons why at some point one may decide to distance from it.

For different reasons, the people who have been maintaining PyGObject for the last couple of years (since the move to introspection) aren't currently using it much any more, which isn't ideal because it means they can allocate less time to maintenance and also lack the guidance of their own motivation.

Fortunately for PyGObject, a bunch of heroic hackers have stepped forward to take the responsibility of maintaining it:

• Martin Pitt
• Paolo Borelli
• Ignacio Casal Quintero
• Sebastian Pölsterl

For now I remain listed in the .doap file, but as I'm not using PyGObject myself any more (even though Collabora sponsors some of my time working on PyGObject), my involvement will be limited to occasional patches and code reviews as I find time.

My thanks and admiration to those who have maintained PyGObject in the past:

• Johan Dahlin
• James Henstridge
• John (J5) Palmieri
• Simon van der Linden
• Zach Goldberg
• Gustavo J Carneiro
• Paul Pogonyshev
• Gian Mario Tagliaretti

To end, just note that Martin is using his canonical.com address, so I assume that Canonical is sponsoring his work as maintainer upstream, so kudos to them as well.

WebGL support in WebKit-Clutter

In a previous post I wrote about how we can use accelerated compositing in the Clutter port of WebKit in order to take advantage of the graphics hardware when merging media elements into the finalized web page, which can be very dynamic (read: several updates per second) due to JavaScript usage and also because of CSS3 animations.

Another advantage of having the composition happening in the GPU is that whatever elements we render there (hw-accelerated video decoding or WebGL) doesn't need to be brought back to the CPU for composition, which would be very expensive.

For the last few weeks I have been working on a proof of concept of how we could implement the WebGL specification in our port, using Clutter. We cannot take the WebGL implementation that is already in use by the Gtk+, Qt and OSX ports because direct GL access isn't possible with Clutter, so it has taken quite a bit more of work than that. Here you can see the code in action, it's a WebGL canvas being rotated with CSS3:



What I ended up doing was adding a mechanism to Cogl (Clutter's graphics backend that abstracts OpenGL) so that applications could use raw GL to draw into an offscreen framebuffer without disturbing the rest of the application's graphics state, that is managed by Cogl. The branch that implements this is here.

Note that this is a proof of concept, in order to upstream this work we would need to find a way to share more code with the existing WebGL implementation in WebKit and also fix all the hackiness on the Cogl branch.

Other further work includes reducing the frequency with which GL contexts are switched, which should help enormously in GPUs such as Imagination's PVR and ARM's Mali.

To finish, I would like to thank my employer Collabora for allowing me to work on this and share the results, and to the Clutter guys that patiently answered my questions and showed me the right way, specially Robert Bragg and Neil Roberts.

If your company is interested in this, we'll be pleased in working with you, just drop an email to sales@collabora.com.

PyGObject 3.0.3 Released

The Sugar guys are doing great progress porting their code from PyGTK+ to GObject Introspection and they have requested a new stable release, which comes with these goodies:

- Convert all modifier constants to Gdk.ModifierType (Manuel Quiñones)

- Convert all strings to utf-8 encoding when retrieving from TreeModel (Sebastian Pölsterl)

- add test for bytearray variants (John (J5) Palmieri)

- handle NULL arrays correctly for each array type (John (J5) Palmieri)

- Revert "Revert "Fix array termination and size calculation"" (John (J5) Palmieri)

- pygmainloop: avoid lockups if multiple glib.MainLoop exist (Owen W. Taylor)

- Properly chain up to the class that implements a given vfunc. (Tomeu Vizoso)

- Revert "Fix array termination and size calculation" (Tomeu Vizoso)

- Fix array termination and size calculation (Holger Berndt)

- pygi-convert: fix for Pango.Alignment (Daniel Drake)

- pygi-convert: fix for Gtk.Orientation (Daniel Drake)

- Add tests for calling closures (Martin Pitt)

- fix marshaling of arrays of GVariants (Mikkel Kamstrup Erlandsen)

Thanks all for your hard work!

More acceleration support for video in webkit-clutter

The last few days I have been working on reworking how video gets rendered inside a web page in the Clutter port of WebKit, using Clutter-GStreamer. This work is contributed by Collabora and sponsored by Bosch.

Previously, we were doing the same as the Gtk+ port, that is, rendering each frame to a Cairo texture (with whatever format conversion that was needed) which would be then composited along the rest of the page (with Cairo as well). On the Clutter port that big surface would be uploaded to a texture in the GPU side of things and composed along the rest of the stage.

Joone and Gustavo have been working lately on adding accelerated compositing support to the Clutter port (and both will be blogging in the next few days about this work), which means that the page gets split in layers that get sent individually to the GPU where they get composited. Layers can be cached so only the ones that changed need to be re-rendered and re-uploaded.

This reduces dramatically the amount of work that happens on the CPU, so that animations with complex pages are feasible, even those involving video elements during playback, such as this:



Because page composition happens now in the GPU instead of in Cairo, we don't need to copy each frame to a Cairo surface (saving a copy) and don't need either to change the pixel format from whatever GStreamer gave us to whatever Cairo wants.

Another benefit of using Clutter-GStreamer is that alpha pre-multiplication can happen in the GPU (implemented as a shader), saving more CPU.

Furthermore (and more importantly), we can use standard GStreamer elements that use the hardware for decoding. Given the proper hardware and driver support, frames could be placed directly where the GPU can find them when compositing the page.

Hopefully this will make the Clutter port of WebKit more appealing for mobile platforms, where low-power GPUs are commonly available but the CPU is often taxed by other tasks.

All the code is here: https://gitorious.org/webkit-clutter/webkit-clutter/commits/ac2

Thanks to Bosch and Collabora for allowing me working on this. To know more about Collabora's involvement in WebKit: http://www.collabora.com/projects/webkit/

WebKit, Clutter and companies giving back

Time passes by and another project nears its end. For the past several months I have worked on a project for Bosch involving Clutter, Mx and WebKit and have had the pleasure of interacting daily with the upstream communities.

I feel I have been lucky because many of the companies that are starting to base their products on FOSS fail to understand the dynamics that will allow them to make the most from the components they are reusing. In this particular case, Bosch has understood that a big part of the value of FOSS resides in the possibility of adapting the software to their specific needs, and also in sharing the burden of maintaining the software with other organizations.

For that to be practical, you have to resist the urge to settle at the beginning of the project on specific stable releases, because if you do, you not only will miss new features and many bug fixes that will land only in the unstable branch, but you will have a much harder time integrating upstream whatever modifications you make. This situation often leads to companies having to maintain forks of the components they had to modify, and that's when the costs start spiraling up. David Neary wrote recently about in The Cost of Going it Alone.

Additionally, by working within the upstream community you will be doing so side-by-side with the people that are most knowledgeable about that specific component, either because they have been working on it for a long time, or quite often, because they are its creators. This is going to massively increase the chances that whatever modifications you end up doing are done in the best way and also that they will be integrated upstream and become maintained by other parties.

Besides technological soundness and reduced maintenance costs, there was an additional factor that made even more important the collaboration with upstream: Bosch had devised a new user experience that pushed the limits of the UI toolkit because of being innovative and because of scalability reasons. And understandably, they didn't want to compromise there because that innovative UI brought a lot of value to their product.

Getting into a FOSS community can be tough sometimes (specially if it's your first time), but in this case I have had the luck of finding a very open community in Clutter, well resourced and with a clear idea of how to deal with those contributions that can bring the most to the project. I take this opportunity to congratulate and thank the colleagues at the Clutter team at Intel OTC: Emmanuele Bassi, Robert Bragg, Neil Roberts, Thomas Wood, Brian Peel and Chris Lord (now at Mozilla).

Here comes a summary of the contributions sponsored by Collabora on behalf of Bosch:

- 16 commits to Clutter, most notably adding the base for gesture-based actions and several improvements to ClutterEffect subclasses.

- 16 commits to Mx, mainly on MxKineticScrollView

- 5 commits to WebKit's Clutter port, the most notable change was allowing the user to explicitly load images

- Filed 30 bugs in total

Besides thanking the individuals mentioned above, I would like to send big kudos to Bosch, Collabora and Intel for the courage and insight shown when investing in this new way of working together that we call Open Source.

You can read more about the Clutter port of WebKit here and about Collabora's involvement in WebKit here.

GObject Introspection hackfest in Berlin

A quick (and late!) recollection of what happened in Berlin during the GObject Introspection hackfest:

• Red Hat's John (J5) Palmieri worked on new releases of PyGObject and on the documentation generators.
• Prezi's Laszlo Pandy worked mainly in resurrecting Zach Goldberg's DocBook generator, merging it into master and adding important stuff to it such as description parsing and class hierarchy rendering.
• Red Hat's Colin Walters reviewed code, gave input on people's direction and answered thousands of questions.
• Syllogist's Shaun McCance added features to Mallard to match gtk-doc and worked on the DocBook and mallard generators.
• Volunteer Torsten Schönfeld worked on improvements in gobject-introspection that are needed by his Perl bindings but that will benefit other bindings as well.
• Canonical's Martin Pitt worked on server-side GDBus support in PyGObject and some improvements trickled to gobject-introspection.
• Igalia's Guillaume Emont worked on adding default values to typelibs, #558620.
• Codethink's Richard Dale worked on GObject-Consume, making it much easier to consume GObject-based APIs from Qt.
• KDE volunteer Arno Rehn worked along with Richard on GObject-Consume.
• Volunteer Johan Dahlin, as one of the maintainers, also supported all others, added missing information to the .gir files and hacked on the DocBook generator.
• OLPC's Simon Schampijer worked on porting Sugar to use introspection instead of the static bindings.
• Volunteer Pavel Holejsovsky couldn't be with us in Berlin but hacked along in #introspection adding stuff to gobject-introspection that his advanced Lua bindings were already needing.
• Collabora's Tomeu Vizoso worked on the documentation generators and on the train back home rebased them to use Mako templates.

Nemein's Piotr Pokora and Nokia's Ivan Frade couldn't join us at the end because of unexpected obligations but we look forward to their contributions in the future.

Travel and lodging has been sponsored by the GNOME Foundation:

Openismus hosted us at their office when the Summit was over:

Nemein invited us to a delicious fondue dinner:

And Collabora treated us to tasty Ethiopian food and flooded us in beer afterwards:

Big thanks to those companies that sent their hackers, to the volunteers that devoted their time and talent, and to the sponsors for their support.

To close, I think this was a hackfest filled with fun and that we made good progress on the stated goals, most importantly having expanded the set of people that hack on gobject-introspection.

There were constant signs of appreciation towards Berlin, its food, beer, people and bike infrastructure. Looking forward for the next one!

Clutter WebKit port at the Desktop Summit

Collabora is sponsoring work on the Clutter port for WebKit and we are going to take the chance to discuss this with the Clutter community during the Desktop Summit in Berlin this month.

Add a comment if you are interested and if there's enough people we'll register for a BoF.

See you in Berlin!