Plasma Active on OpenGL ES

The past weeks, I’ve been working on getting Kwin, the window manager and compositor in Plasma Active (and Plasma Desktop ;) to work on top of OpenGL ES instead of OpenGL. After some updating of packages lower in the stack, especially Mesa and parts of Xorg, we now have working OpenGL ES support on our hardware. Today, I’ve finished packaging it as an option on top of our Plasma Active packages. These packages in the :Devel subsection of the KDE:Active repository in the OBS run on top of Balsam Professional and openSUSE 11.4. We will give this some more testing and improve a few things, in order to move to GLES by default. OpenGL ES is very interesting as this is an API often used on mobile devices, so I’m glad that I can state that we’re ready for this. This of course needs proper support in the drivers, something we can not always solve by ourselves. I have been running this successfully on two Intel Atom-based tablets.

Contour showing the Froscon activity

All the props of course to to our Akademy-award winning window management and compositing hero, the one and only Martin Grässlin. He’s been working on OpenGL ES support (and a lot of other features to make kwin “ready for the future”) for quite some time already. OpenGL ES support in kwin has been introduced in the recent Plasma Desktop 4.7 release, a few weeks ago.

So, is it much different? Nope, it’s very much a thing of underlying technology. There’s no noticable performance improvement, but it runs stable and well. Given that OpenGL ES support has only very recently been introduced in kwin, it’s already surprisingly good. There is probably still a lot of room for improvement, which is something we can investigate now and easily test much better.


In the screenshot of the Contour shell of Plasma Active, you can see that I’m all set up to go to FrOSCon tomorrow, where I’ll be presenting the ideas and demoing the prototypes, hoping to get some feedback on concepts, and give some understanding of the challenges and opportunities we face in this exciting endeavour. And of course show some serious bling. :) If you’re in the area around Bonn, drop by.

KDE:Active:Devel introduced

The past week, when working on the Mesa packages for Plasma Active, I might have caused some headache since I broke the compositor in Plasma Active with a few packages I uploaded for easier deployment on test devices. It was not more than an annoyance, because kwin gracefully falls back to non-composited mode in case of graphics problems. In order to get a bit more stability into our deployment process, I’ve now set up a subproject called KDE:Active:Devel under the KDE:Active project on the Open Build Service (OBS) which we use to build the Balsam packages. As we’re moving, development-wise into the stabilization phase for Plasma Active One, this makes testing new things a lot easier, just by switching to the same package from the :Devel branch. Conversely, this means that if you install packages from the :Devel subproject, you should really know what you’re doing. On the bright side, it’ll be easier to keep regressions out of the packages that are deployed on most users’ machines. Contour showing the Froscon activity

Along with these changes, I’ve updated all the packages to the latest state of the art, and worked a bit on our documentation, as we keep getting very good feedback about this. Among the most wanted fixes we’ve introduced is a patch by Aaron that makes konsole usable with the virtual keyboard, making another very powerful tool usable on Plasma Active. I’ve also fixed up some default configuration options, polished up the contour packages and made that used by default. (Those who have plasma-tablet-config on their machine will have to replace it with “plasma-contour-config”, though.) This is another pretty big move, as we now basically regard the contour shell stable enough to make it into Plasma Active One. It’s also very, very shiny I must say, the usual disclaimer about alpha software notwithstanding.

OBS makes it rather convenient merging changes back and forth between these branches. In general, my impression is that OBS works very nicely as a collaboration tool, and solves a very complex problem for us, the “how do we get our code onto the device”. As an aside, it also makes it very easy to build packages locally, so for even shorter development-deployment cycles, one can build locally and rsync packages onto the device. With the right kind of script setup, that takes a lot of the pain away, that development for mobile devices often brings with it. The KDE:Active:Devel repo can be used directly by developers to upload their latest sources in order to deploy them to their testing machines, and we can pull working versions in from there. Rocking.

Installing Plasma Active on the ExoPC (“WeTab”)

If you own an ExoPC, and you’re eager to know how to get Plasma Active, our new workspace and set of applications for consumer devices to run on it, this blog article will help you get going.

Note: Plasma Active is in alpha state right now, it is basically usable, but you will find many rough edges. You should not try this unless you consider yourself an early adopter, or if you mind fiddling with bits and pieces. We are working towards an end-user ready product, but we’re not yet there.

Plasma Active

What to pick?

There are a few different options to choose from, I’ll quickly explain which to choose under which circumstances.

  • MeeGo: Works well overall, but is lacking in key areas, for example we do not have a UI to connect to wireless networks yet, and as the device doesn’t have Ethernet (and cables are lame on mobile devices anyway). You can work around this with a trick Marco explains.
    Choose this option if you want to run and develop for MeeGo
  • Balsam Professional: Download the Balsam Professional live images from open-slx. This live image provides a fully functional live system without too much hassle.
    Choose this option if you want to try Plasma Active
  • openSUSE: Install Plasma Active on top of openSUSE 11.4, it uses the Active packages created by open-slx (me, my employer), but is a bit more laborious to install.
    Choose this option if you want to run the full experience on your ExoPC, or track progress and hack on Plasma Active

I will explain here how you can get to a state-of-the-art Plasma Active, using what will eventually become the Tablet Edition of Balsam Professional. Balsam Professional is, unlike openSUSE, focused on end-users and the user experience on consumer-level devices. Balsam Professional is based on openSUSE, so you might well be familiar with many of the tools already.

What you need

  • An ExoPC, or a WeTab
  • An empty USB stick of at least 700MB
  • A USB keyboard and possibly a mouse

Note that the installation is possible to do by keyboard only, but a bit more comfortable if you have a mouse available. As the ExoPC does only have two USB ports, one of which will be occupied by the installation medium for the first part of the setup, you either need a USB hub, or a combined receiver for mouse and keyboard. If you don’t have a mouse or the means to plug one in, don’t worry, it’s not really hard to do. In this case, I’d recommend to install the updated kernel package from the KDE:Active repo as soon as the base installation is done, as that makes the touchscreen work, from that point on, you won’t need a mouse anymore.
The process should take you about two hours, you might get it done quicker, but should be able to get it running within, say, one evening.

Getting started

The following points provide a detailed guide to installing Plasma Active and the Contour shell onto your ExoPC, using openSUSE. This process is also explained on the wiki, check there for the latest updates.

  1. Install openSUSE 11.4: Download this image, Use “dd” to write it to a USB stick, or use the excellent imagewriter tool to handle this for you. after this step, you should have a bootable installation medium in your hands.
  2. Insert the USB stick into your ExoPC, boot it and install openSUSE 11.4 onto the machine. It’s wise to enable auto-login, and possibly the SSH server during the installation, since this makes your life a bit easier later on. You need a keyboard for this.
  3. Set up the repositories for Plasma Active:
    zypper addrepo --refresh \ kr47
    zypper addrepo --refresh \ plasma-active
    zypper modifyrepo --priority 90 plasma-active

    The last line increases the priority (lower value means higher priority) for the Plasma Active packages.

  4. Update your KDE installation to the 4.7 release, this pulls in the dependencies needed for Plasma Active. At this point, you still have a traditional desktop, you now update the KDE stack to the 4.7, and get a few updated packages as well (among them Mesa and a new kernel which is needed to make the touchscreen work and brings much better performance):
    zypper dup

    Accept all vendor changes.

  5. Make sure the 3.0 kernel is installed (“zypper if kernel-desktop”), if not install it with
    zypper in plasma-active:kernel-desktop  plasma-active:kernel-desktop-base
  6. Install Plasma Active packages on top. This will install the contour shell, some apps and configure your system to run Plasma Active, including tweaks to the defaut configuration that make the whole system more touch-friendly and suitable for mobile use cases.
    zypper in plasma-contour-config

    After this step, you have Plasma Active on your system.

  7. Reboot to boot the new kernel, the Active shell will start automatically. If you get a black screen past login, use a keyboard and ALT+F2, “konsole” to get a shell and try starting “plasma-contour” by hand. If the command is not found, as root, do “ln -s /usr/bin/plasma-mobile /usr/bin/plasma-contour”.
  8. Install additional packages, such as Calligra Active (package “calligra-active”) Kontact Touch (package: “kdepim4”) or the kdegames4 suite. Bringing you a nice collection of useful software.
  9. Hop into the #active IRC channel on, tell us about your experiences and help others gettting started as well. =)

On Tuesday at 14:00 UTC and on Friday at 12:00 UTC, we will organize online install fests on #active ( where we can help you with installation issues, and where you can share your experience with others. Of course you’re free to drop by and hang around at any time.

Release Team Changes

During the Desktop Summit in Berlin, we had a session in which we had a good look at how KDE’s release team performs, which points we can improve on, how, and who will implement these changes. For example:

  • Make our output more predictable and thus downstreams’ lives easier
  • Reduce the risk of something going wrong, the bus number problem
  • Make our work more efficient

Let’s take a step back first, though.

A bit of history: from Coolo & Dirk to TWG to Release Team

In KDE 3, Coolo and Dirk managed KDE’s releases. When KDE4 was started, we also wanted to promote this in a more suitable fashion, we started doing more proactive PR work, and generally improved our communication to our users (potential or not). In 2005, the Technical Working Group was conceived, which was meant to handle the releases of KDE4. The Technical Working Group didn’t quite work out since it didn’t bring the structural changes we needed in order to release KDE4. In late 2006 we we decided that it didn’t work, disbanded the TWG and conceived the release team, a self-organized team of volunteers. Conceptually, the release team started as a place for people to go who wanted to make releases happen. We found module maintainers for our released modules who would coordinate towards the app teams and, and a few core people who know how all that stuff works to put things together. We got our release process on the rails again. Interestingly, the release team is very informal, we never ended up appointing anyone release manager, or end-responsible — it has also never been necessary, it seems. Lesson here: shared responsibility works well for us.
A quick unscientific count of the whole KDE 4 series (including pre-releases) brought me to 88 releases done by the release team in its current form.

Git migration and tarball layout

During the migration of our source code repositories to Git, we had a bit of trouble keeping up with splitting of our released modules. This has caused a bit of grief among some packagers, but we’ve sat down together a few times and worked out good solutions for these problems. The Git migration meant that we’d split out repositories such as kdegraphics, but shipping a different set of tarballs also means that packagers have to adjust their scripts, spec files and so on. The Git migration was spread out over a period, meaning that we basically ended up with shifting tarball layouts across patch-level releases, which unintentionally added a bit of work across those releases. Thanks to the feedback from packagers (especially Slackware has helped us a lot there), we were able to address these things, before and during the desktop summit and have become much more aware that the tarball layout is for us essentially a public interface which should be kept stable, and not change without good reasons and communication to those who are affected by it. This will be done as changes to the release scripts, which combine git repos into tarballs.

Release Team BoF

As I mentioned, during Desktop Summit, we used the opportunity to talk about these problems and find solutions to them in a BoF (Birds-of-a-feather) session. About 12 people got together to work on this, including downstream participants such as Slackware, openSUSE, Gentoo, MeeGo, Balsam and people from the release team, build system knowledgables and GNOME’s release team. A group with different angles but a shared goal. I think collaboration has come a long way, seeing that we share processes and experiences across many groups.
The BoF session was kicked off by a discussion wether we want to change our release rythm. People were pretty happy with our time-based, 6-monthly releases, so we quickly decided to keep these. We thought about reducing the number of patch-level releases, which might make sense since we’re in much calmer water than when we started with this rythm at 4.0. There are — unsurprisingly a lot less critical bugfixes now than back in 2008. Our users seem to be really happy with our cadence, so we decided to reduce the work with these releases a bit more, but to keep our monthly updates — no changes there.

Release Team Tweaks

So what did we come up with? The following list of items should give you a good idea of that, but please keep in mind that we haven’t nailed everything down completely, and that it’s a bit of work on progress. The things left to do aren’t that horrible, so I suppose I won’t take long until we have adopted these tweaks to our processes, and that the results become visible. I’ll put this onto the Wiki once I’ve dealt with the post Desktop Summit lack of sleep. :)

  • Human backup strategy:: We’ve checked with each other who jumps in. Once in a while we’ll have the backup person take over a release, so we actually make sure that we not only think we’re safe, but that we actually are. We’ve started approaching people who we think have the responsibility, trust and skills to backup the release team.
  • More parts to be automated: Script more parts of the release notes,our patch-level releases still involve “monkey work” to a certain degree. This involves some easy changes to the PHP scripts will help us we attempt to maintain consistency across release notes.
  • More predictable tarball layout: The tarball layout will be kept in place for 4.x, Frameworks 5.0 will obviously bring changes to the tarball layouts, which will happen as a one-time change.
  • More rythm to the community by communicating more often where we are in our cycle. This will most likely happen in the form of reminders to email lists such as kde-core-devel, release-team, kde-devel.
  • Promo Team does release notes: The promo team is the right place to create release material, Carl offered to coordinate this on the kde-promo side.

I think that these points bring a nice set of improvements to our current release process and prepare the way to the eventual release of the KDE Frameworks 5 — we came up with a strategy to facilitate the modularization in the structure of especially our development frameworks. One that works for us and our downstreams.

Board Business

Tonight, the new board of directors of KDE e.V. went out for dinner, generously (!) treated by our constituency.

It was a nice and relaxed dinner, gave us some good opportunity to brief Lydia (our newest board member) on how we work, boring stuff like where we store our documents, what to expect from our bi-weekly conference calls, what granularity of emailing we found to be productive, and so on. One official thing we always have to do (according to German foundation regulations, so-called “Vereinsrecht”) is appointing roles. Cornelius was volunteered as president, Frank as treasurer, both accepted their new and old responsibilities. I promoted from regular board member to vice president (which really only has a a theoretical meaning). The vote was, as usual a formal thing and we got it done between dumpling 2 and 3 on my plate, it took all of 3 minutes. Serious, effective, yet duely diligent. :P

We also used the opportunity to talk about non-board stuff, about our other projects in KDE (we’re also pretty active in the community outside of the board chores), private going ons, random fun things. I came back happy about our team, and looking forward to our work in the coming year. Just right.

Earlier this afternoon, we met with the GNOME board. There were also some personal changes in the new GNOME board, I especially enjoyed Ryan Lortie (desrt) having joined the board of directors of the GNOME foundation. I’ve met Ryan at several occasions in the past, and always found that we got a good click, enough differences to keep conversations interesting, but very much one the same line of communication. One of the topics was communications across the boards, and we thought that having some kind of ‘open communication channel’ for situtations which might turn unproductive would be good. Ryan and me volunteered, and we took immediate opportunity and went out for an afternoon drink, which I very much enjoyed.

While going to our dinner appointment, I had really two things in mind, love and hate. Not sure why those two words sprang to my mind, but I really hate saying goodbye to the people I love. Even if it’s very much a temporary thing (our meetings in the Plasma team have become pretty frequent, especially with Plasma Active One being on the horizon), having people leave after an intensive week of excellent collaboration always makes me kind of sad. That’s of course just an indication of how much I enjoy working in this excellent team, or maybe just a sign of exhaustion after a week of pushing the Free desktop to the next level with peers who are as passionate about this as I am. Tomorrow in the afternoon, I’ll take a train back home to the Netherlands, and will commence putting our plans (and continuation, tweaks thereof) to action. Exhausted after week of frantic Free software conferencing, but just as energized as if it were my first Akademy.

The coming weekend will be used for catching up on sleep, then next weekend, I’ll be at Froscon, where I’ll be presenting Plasma Active. Be there if you want to touch it yourself. :)

Desktop Summit Thoughts

I’ve been to the Desktop Summit in Berlin for the past few days, we’re now around the middle of the event, after the conference, before the workshop and BoF sessions, so I thought I might share some thoughts I’ve gathered in idle moments in the past few days.

Boredom and Diversity

Last night, the build system BoF was planned, a team session where we look at the way how we develop our software. I have to admit that to me, this is quite a boring (but nevertheless very important topic). As it also affects the way we release software, I’ve put my release team hat on and joined the session. I was a bit afraid that since it’s not the most sexy topic in the world, that little people would show and we end up with incomplete or broken ways to release the KDE SC, and KDE Frameworks in the future. My worries were ungrounded as quite some people showed up and we made good progress on all the topic we talked about. (If you’re interested what we talked about, keep an eye on the kde-core-devel and kde-buildsystem mailinglists.) What struck me is that in KDE, there’s enough people who feel responsible, even for boring topics. When I shared my (ungrounded) concerns with Stephen Kelly, he looked at me with this empty expression on his face and told me “but that’s exciting, it’s the way we build our software!”, and given his enthusiasm, I believe him (even if I don’t exactly personally share his excitement). Diversity makes us strong.

Collaboration and Sustainability

While during the last desktop summit, in Gran Canaria, there were really two co-located conferences, and for my taste we missed some opportunities to sit together with our GNOME peers, this aspect is much better this time around. I’m not sure wether it’s because we all figured out that we have to work more closely together, or if the setup of the conference enables us to work together more closely, I just see it happening. In fact, we sat together with a bunch of GNOME guys until late last night, discussing challenges the Free software ecosystem faces, and possible solutions to these. We focused on these shared challenges instead of the diffferences in our approach, and the differences in our community. We did think much more as one community, than as two.

Active Central

My current focus in KDE is of course Plasma Active, and our team of designers and hackers is fully using opportunities this event gives us to get the word out about Active, and establish it as our answer to the Freedom needs on consumer devices. Just like Matthias set out 15 years ago to conquer the desktop, to provide a Free, coherent, integrated and complete set of applications for users of desktop computers, we are setting sails to also reach this goal for a wider spectrum of consumer devices. We held a bunch of presentations during the conference track already. Martin Grässlin kicked that “Plasma Active track” off, talking about Kwin and Wayland, me doing a more general overview, then Marco and Fania explaining concepts behind Active’s Contour shell, and finally Ivan having us peak into how Nepomuk smartens up our devices by closely listen to what we do. The feedback so far has been fantastic, and I think we’re a step closer to reaching our goal of unifying our efforts regarding consumer devices, such as tablets, smartphones, media centers, and whatever will be invented.

So, on to the next ten billion disruptions! ;-)