Multiple backends for GTK+

I have to blog about this before the other Kristian finds out and beats me to it. Kris wrote about the new GDK backend work that Alex Larsson started and Benjamin Otte and Matthias Clasen finished. The backend work lets us compile several GDK backends into GTK+ at the same time. Over the holidays I was able to dust off my Wayland backend work for GTK+ and bring it up to date with all the cleanup that's been going on and make it work with the multi-backend stuff. With a little patch to the build system, it is now possible to actually build multiple backends, and adding a Wayland backend on top of that lets us try out the new multi-backend functionality:

The screen shot shows the testgtk application running under X (that's the window with decorations) and under Wayland (using the X based compositor, sort of like Xnest but Wayland nested under X instead). The two testgtk windows come from the same application linking to the same GTK+ library. The only difference is that the Wayland instance was started with the GDK_BACKEND environment variable set to "wayland".

I moved my wayland backend branch to the upstream gtk+ git repository, but it's still very much a work in progress. In fact, I'm using testgtk in the screenshot above, because gtk-demo currently doesn't work in the Wayland backend. But like Kris mentions in his post, the cleanups that has landed in gtk+ recently makes it a lot easier to work with and port to other window systems. And Wayland itself is a lot easier to run these days, all the custom branches of mesa, libdrm etc and kernel patches that were necessary a year ago are now upstream. Fedora rawhide has all the packages required to build and run Wayland and Bryce Harrington maintains a Wayland PPA for Ubuntu (only maverick for now). Or you can build it yourself

And by the way, Wayland moved to freedesktop.org hosting recently: wayland.freedesktop.org. We now have web pages, a real mailing list, #wayland on irc.freenode.org and an official looking git repo.

Thanks!

Emil got a pair of pirate pants from the GNOME Foundation! This was a "thank you" present for the GNOME git transition work, but the pleasure was all mine. I'm happy to see that the transition has been mostly a non-issue and that GNOME development continues with the same (or maybe even better) pace after this little infrastructure hiccup.

Also in the gift bag was a hand imprint kit, but I had to make a left foot imprint, of course! Unfortunately the kit was a little hard to use, or maybe my craft skillz just aren't up to standard for this stuff.

There's definitely a foot there though. The white imprint material was very fascinating - light weight and plasticy and it smelled very delicious - I had to resist the urge to bite into it.

Fuck the Foundries

I'm guessing a lot of people have seen this already, but I just love this rant and can read it over and over again: Fuck the Foundries. Indeed.

The Eagle EGL loader

I happen to have a small side project over here that's a non-conformant, itty-bitty EGL loader for the DRI drivers. Eagle started as a test case for the dri driver interface changes I was doing for DRI2. Before the interface changes, the driver interface was GLX specific and I wanted to remove all X/GLX dependencies from the driver and make it easy to load the dri driver in an EGL framework. So eagle started as a simple loader for the driver to verify the interface changes. At some point I realized that it was pretty close to working and finished up the remaining pieces. It's still lacking a proper EGLConfig picker, but it's fairly capable and sufficient for Wayland.

Now, there's also a mesa EGL loader. The mesa code is very generic and supports EGL on GLX, EGL on gallium, EGL on swrast, whereas Eagle is strictly written to just support the new DRI driver interface. That means Eagle is very minimal, while mesa egl has some overhead (more indirection, more .so's to dlopen). The mesa EGL code doesn't have support for the new (DRI2) dri driver interface, so it only works for gallium capable drivers, specifically, it won't work for the Intel DRI driver.

Merging the Eagle code into the mesa EGL code, has a good number of benefits: the mesa code will learn how to load DRI2 drivers, I won't have to write an fbconfig chooser, and there'll be only one EGL for mesa. So there's a lot of appeal there. The downside, and the main reason I'm still keeping Eagle a separate project is that I want to experiment with the glue code API between EGL and GEM/DRM. The way you create an EGLDisplay or an EGLSurface you have to first somehow create an instance of an EGLNativeDisplayType or EGLNativeWindowType, EGLNativePixmapType and then pass that to an EGL constructor such as eglCreateWindowSurface(). I'm not a diplomat, so let me just say it as it is: that's fricking braindead! See, if you have to go outside the generic EGL API to create an EGLNativePixmapType, why can't we just skip the middle man and create the EGLSurface straight from the implementation specific code. That way we wouldn't have to pollute the EGL API with strange, useless "native" types and we wouldn't need and window and a pixmap constructor for EGL surfaces.

Anyway, the native type fiasco is just a wart in the API that I like obsessing over. There's nothing that prevents an EGL implementation, such as Eagle, from implementing it's own non-standard entry points to create an EGLSurface straight from a GEM buffer handle, for example. Or non-standard API to get at the GEM handle for the back buffer so that we can use the KMS page flipping API. Which is what Eagle does and it's the main reason that it still exists. Eagle is currently a playground where I can try out different types of constructors and extensions for integrating EGL with GEM and KMS. Once we get the KMS page flipping ioctl worked out, I'm planning to write a Eagle+KMS backend for clutter, so clutter apps can run straight on the KMS framebuffer. Next step from there would be a clutter based Wayland compositor... oh wait, isn't that what Moblin should be?

Out of the Office

I have a son! Emil Au Kristensen, born June 25th, 8lbs 12oz, 22 inches.

Git day plus a week

Woo, the GNOME git migration is complete. We got the bulk of the repos converted Thu-Fri last week, but it took a little longer than estimated because of an update to the the commit message rewriting step. The remaining days have been spent trying to fix and reimport the repos that were broken during the import. I sent out this status a couple of days ago, and just now I copied the last fixed repo in place on git.gnome.org.

I'm looking forward to closing the door on this and to contribute to GNOME through git. And now that I have the scars to prove it, let me just end by saying: friends don't let friends use svn.

Git day minus 1

Tomorrow, Thursday April 16th, is the big flag day for the GNOME repositories. We've moved over quite a few repositories from SVN, GitHub, freedesktop.org and other places that people have put GNOME git repositories, but tomorrow we finish the migration and move over everything else. We've timed it so that the 2.26.1 release could be finished first, and since that just happened, now is the time to push the big button. Thanks to a lot of sysadmin legwork from Owen, the GNOME git infrastructure is looking great: we have cgit set up on git.gnome.org and the various commit hooks and mailing lists scripts have been setup and tuned.

What will happen tomorrow is that all SVN repositories will be marked readonly in the morning, around 10am EST, and then we'll start the migration. The git repositories will show up as they're converted and will be ready to clone and push to. We've done a few test runs on all the GNOME repos and I expect the conversion process to take most of the day.

Part of the migration project has been to update the documentation and there's a introduction document in place for developers and a guide for translators as well. There's room for improvement still, but in the meantime a lot of GNOME contributers are already familiar with git and can help out on irc etc.

See you on the other side!