Setting up a Pandaboard for KWin development

The Pandaboard is a nice little ARM powered device which is meant for development and suited for example to test KWin on real OpenGL ES hardware. This weekend I decided to set it up again, I had done it before, I had installed KWin on the PI, so I’m not a complete NOOB for ARM hardware. I wanted to test a few things and see how the latest changes to master do on a non x86 architecture.

I got the memo about Linux is for normal users and not for LEET, but I do not understand why it has to be so difficult to setup a device which is meant for development. In the past it was as simple as dd an image to an SD-card, plug it in and done. Well those times are over.

My requirement for a base distributions are rather small:

Up to date kdelibs, because compiling is slow on the device
Working drivers for GL hardware

With this combination we can rule out most distributions like for example Debian (issues with both) or openSUSE (no drivers). I decided to try Linaro 13.02 which offers an image for Pandaboard and is Ubuntu 12.10 based, which means we can easily install KDE packages.

Linaro is still rather simple: dd to SD card, plug in and go. Just that you don’t get any output on the screen. I already thought my Pandaboard was broken. What’s a little bit tricky is that the Pandaboard has two HDMI connectors (one as HDMI, one as DVI) and at least openSUSE reports that only the real HDMI works. But with Linaro I did not get anything on either screen or TV.

So I had to connect to the Serial port to get some output. And look there: it boots. Once I was logged in I was able to figure out that the system is pretty basic, e.g. no X installed. But even after installing X I did not get anything on the screen: it complained about missing /dev/fb0. That was then the point where I considered trying a different distribution. (Search did not help).

Next choice was Kubuntu. This also used to be rather simple: dd to SD card. Downloaded daily build of 13.04, dd to SD card, plugged in and screen turns on. But instead of starting the system, the installer is started. Well since 12.10 you need to install. Obviously the system is not able to install to the SD card which is plugged in. So I got an USB stick, dd to stick, plugged in and nothing. The pandaboard doesn’t boot from USB stick. Now it got difficult: search for a second SD card. Found one, dd image to the second card, moved the first SD card to a card reader, plugged everything in and installed to the SD card at the card reader.

After installation, I swapped the SD cards, plugged in and nothing. System doesn’t boot. Well maybe the system expects at a different device, so I plugged the card reader in again, tried to boot and nothing.

OK, I installed a daily built of an unreleased version, so maybe I should try 12.10. Not so up to date kdelibs, but probably good enough for KWin. Did the same procedure again, installed and doesn’t boot.

Now what? I could try a base Ubuntu instead of Kubuntu. But as the installer is to my knowledge shared I do not expect that it will work. And also I’m too scared that Ubuntu will come without drivers and with Compiz. I don’t want llvmpipe on the desktop, I definitely don’t want llvmpipe on ARM. And I had seen Compiz with drivers on the pandaboard – so no that’s too scary.

While searching for a solution to the problems I was facing, I also stumbled over Ubuntu Core. It didn’t look like anything I want to try, but at this stage I was at the point to decide whether I use a distro like openSUSE without drivers or try something which might give me drivers.

Now with the linked wiki page I would not have been able to install it, because it’s an interesting system. Luckily the omappedia contains an instruction. Basically the system comes with nothing. No editor, no network, no console, no way to log in, just nothing. But even with the introduction it gets interesting. For example it links a PPA which is not available for quantal or raring. Do I not need it anymore? Will my system be broken afterwards? (it turned out that the packages are nowadays included).

The most interesting aspects were that it doesn’t start with networking enabled. The wiki page lists a command to start networking, but I did not manually adjust resolv.conf because I thought DHCP would set it. Well it didn’t and in the running system you cannot change it because there’s no editor.

After quite some fiddling with the system I finally was at a state where startx succeeded and loaded into the KDE Plasma desktop. Looked good even compositing working OOTB (of course only XRender). So I enabled my keyboard/mouse combo and nothing. Searching for this problem recommended to check whether the usb module is loaded. Yeah, come on, I’m not stupid. Well better be sure:
lsmod | grep usb
nothing. Hmm get’s interesting. Modprobe fails, depmod fails – /lib/modules/ does not exist. The linux image was not installed. That was the point where I decided to install full kubuntu-desktop instead of just kde-workspace. The device is slow, it took a few hours.

By now I have the system running and KWin master built from source (took another few hours). It looks like it has drivers for the system. At least a shipped demo application for OpenGL ES 1.1 is working – the demo application for OpenGL ES 2.0 is failing because it has a hard coded path to the shader file. Installing the driver was also fun, it comes as a DKMS package and the first installation try failed with a crashing g++. That’s something I already knew from my last try with the pandaboard. Gcc might crash, restarting solves it.

Unfortunately I don’t have KWin running on OpenGL ES yet on this hardware. It fails somewhere in the init buffer configs code. But it was already worth the effort. The code is already extended with much more error checks as I needed to find where exactly it is failing. Also compiling on ARM found a few more C++11 narrowing conversion warnings (floats). Given that we want to enable C++11 for KWin in 4.11 it’s good to know that there is still some work to do on non x86 hardware. Would be nice to get that CI covered.

25. March 2013

This week in KWin (2013, week 10-12)

This week I want to start with a big thank you for our sysadmins who did a great job this weekend. And then I want to say sorry that I didn’t put up a summary the last two weeks, but I did a general blog post instead.

Last week we had to investigate one issue which quite surprised me. On Sunday a cleanup to our GLX initialization code was pushed to master. This had a small regression preventing compositing to work on NVIDIA. What surprised me is that nobody noticed till Thursday, when I setup an old system with NVIDIA to test something completely different. Is nobody running master any more or are our KDE developers no longer using the NVIDIA driver? Overall it’s not good that we have regressions in master for four days without anybody noticing. And no: CI cannot catch such issues.

Summary

Crash Fixes

315528: KWin crashes when switching windows
This change will be available in version 4.11
Git Commit

Critical Bug Fixes

Bug Fixes

259640: Deleted windows not unrefed when restarting compositing
This change will be available in version 4.10.2
Git Commit
317068: keepInArea does not work if window dimensions match the area dimensions
This change will be available in version 4.10.2
Git Commit
305781: Option “Suspend desktop effects for fullscreen windows” makes the image freeze when going fullscreen in applications
This change will be available in version 4.10.2
Git Commit
316040: Dual screen issue caused by d6b3f6983efebc42abd6028ece9c3ec7facea2d0
This change will be available in version 4.11
Git Commit
283309: Attaching windows to activities is too clumsy
This change will be available in version 4.10.2
Git Commit
316033: Switching from one aurorae theme to another results in no decoration
This change will be available in version 4.10.2
Git Commit
314532: Plastik (QML) decoration: poor performance with desktop effects
This change will be available in version 4.10.2
Git Commit
296076: Fix fullscreen state handling: NETWM says it’s bound to focus and not stacking order, also see bug #224600
This change will be available in version 4.11
Git Commit
313061: “Login” effect does not fade in on secondary monitor(s) with a multi screen setup
This change will be available in version 4.11
Git Commit
307965: Upper part of windows tears when moving it left/right ONLY in upper part of display
This change will be available in version 4.11
Git Commit
299245: Get rid of “Display borders on maximized windows” setting
This change will be available in version 4.11
Git Commit
237260: shortcuts for switching windows don’t work with multihead
317025: Java Swing Apps do not receive Deiconify event if window is shaded
This change will be available in version 4.11
Git Commit
91703: vertical maximization doesn’t work as expected
This change will be available in version 4.11
Git Commit

New Features

Tasks

14. March 2013

An update on KWin on 5

I realized I haven’t written a blog post to highlight the latest changes in KWin for quite some time. The reason for this is that we currently are mostly focused on getting KWin to work on Qt 5/KDE Frameworks 5. As I have mentioned already in the past KWin is a little bit special in the transition to Qt 5 as we used the low level native, non-portable functions provided by Qt (last week I found one usage of a native function which is not even documented). For us it mostly means that we transit from XLib to XCB and remove code which uses methods which got removed or replaced.

Although that means that we hardly have any new features there are quite some improvements all over KWin. Having to touch the code anyway allows us to also rethink how we tackle a problem.

For example we use Plasma functionality at a few places. The code got added before QtQuick existed so it uses QGraphicsView. With libplasma2 the QGraphicsView support is going to be removed which means we need to adjust our code. Over the last years some areas in KWin already made the transition from Plasma styled QGraphicsView to QtQuick, such as our Window Switcher or the Desktop Change OSD. But some areas remained: the close button in Present Windows and the add/remove desktop button in Desktop Grid. Here we have now a nice improvement ready for 4.11: these elements got rewritten in QML and they look way better now.

Aus KWin

For comparison just do Ctrl+F8 or Click here.

This was AFAIK the last bits of UI in KWin which hasn’t done the transition to QML yet. By using QML for all of our UIs the code becomes much easier to maintain, easier for users to improve it, easier to style it. The last point is really important for KWin adjustments for non-Plasma environments like Razor-Qt. Though they use a fair bit of Plasma styling already and with KF5 libplasma2 will be so small that it hardly matters 😉

The screenshot also shows another new improvement thanks to the transition to XCB. In the left upper corner a glow is shown when approaching the corner with the mouse cursor. If you use auto-hiding Plasma panels you already know this glow. This change became possible because the screen edge related code was one of our strongest user of XLib and a refactoring was needed anyway to support the world after X. The new design follows an approach which will make it easy to add support for a new windowing system – even if I do not know how exactly that will look like in a Wayland world (currently Qt5 is the highest priority). Also we plan to make KWin take care of the screen edges needed for the Plasma Panel. This removes quite some duplicated functionality from Plasma and solves the general “problem” that Plasma cannot listen to just all mouse events in a Wayland world.

One of the areas which has seen most adjustment so far is our XRender based compositor. It was a heavy user of the QPixmap/X pixmap relationship and needed to change. I still consider XRender as an important part of our compositing offering and therefore decided to do the porting. Interestingly the porting did also bring improvements to our OpenGL compositors. Again the reason is that we had to rethink. Our decoration rendering code used the QPixmap/X Pixmap relationship from the time when KWin only supported the native Qt graphicssystem. When we did the transition to raster the code did not get adjusted to the new world and that’s why we for example recommended the native graphicssystem for XRender. With the native system going away we just had to make it better and the improvements made for XRender benefit the OpenGL compositor in the same way. With Qt 5 I hope that we can get some further improvements for the QtQuick based window decorations. I was running KWin on XRender with raster and Plastik-QML as window decoration and was positively surprised: I couldn’t notice a difference in the speed compared to the OpenGL backend.

So how far are we with the transition to Qt 5? Last week I did a test compile against Qt 5 and KF 5. I hit a few issues but got it compiled. Apart from the known low-level issues (we still need some of the functions for Qt 4’s native graphicssystem) I only hit one compile issue with Qt 5 – given the source base that’s really a great job by the Trolls! In KF 5 I hit a few more issues – also because it’s not yet meant to be used. Well it doesn’t bother me much, I fixed the issues and started to integrate them either in KWin or in KF5.

But when it’s not yet supposed to be used, why am I investing time into it? The reason is the event filter. We need to transit our event filter from XLib to XCB and that’s something we can only test once we are running against Qt 5. I have some code prepared which at least compiles, though I know that it doesn’t cover everything and needs to be changed. I plan to give it a try over the next day, just to see how much breaks. But that’s the reason why we are doing it right now to have enough time till we do the final transition.

8. March 2013

Reply to “All the faces of Ubuntu”

Dear Mark Shuttleworth,

so you “have absolutely no doubt that Kwin will work just fine on top of Mir”. This is great and I totally appreciate that you think Mir is a great system. But I’m wondering why you don’t use KWin then, after all it will work fine on top of Mir and is Qt based?

But I have doubt that KWin will work just fine on top of Mir and I have already stated so. You might have wanted to check the facts before stating such claims (somehow I get a feeling for a pattern here).

What makes me think that you cannot make such bold claims:

You don’t even know how to write KWin
Currently the number of commits to KWin by an Canonical employee is 0 (git log — kwin | grep @canonical)
No Canonical employee has so far contacted the KWin team on how we could integrate Mir and whether we are interested at all
I have to question the abilities of Canonical to judge what other software can do and cannot after Canonical argued with non existing issues in Wayland for Mir
We are still waiting for the Wayland adjustments for KDE done by Canonical. May I remind you:

We’ll help GNOME and KDE with the transition, there’s no reason for them not to be there on day one either.

I have to ask you to keep KWin out of the pro-Mir campaign. I didn’t ask for Mir, I don’t want Mir and reading blog posts like the one which triggered this reply does lower my motivation to ever have anything to do with Mir. Mir is an answer to a question nobody asked. It’s a solution to problem which does not exist.

Your community manager recently posted on Google+ he had a frustrating day. Guess what my week has been and guess who I can blame. Guess what I great day I will have after reading your blog post this morning.

5. March 2013

War is Peace

Today I got many questions about KWin and Mir, how it affects us, what it means for our Wayland plans and so on. I did not want to write anything about it because I think there is nothing to write about, but before answering the same question again and again I think it’s better to put down a few lines here. Wiki will be updated once Wayland wiki is updated so that we have something to link to.

First question: Does Mir affect us? Yes, obviously. Because of Mir I have to write this blog post, Wayland developers have to get the FUD out of the Mir documentation, it’s creating tension and it harms the development. We will have to face again and again the question whether Wayland is better or not. So yes it affects us and I’m not happy about it.

Second question: Does it affect our plans for Wayland? I think it would be very unprofessional if we would change our plans just because Canonical did an announcement that they want to do an own display server for Unity (we didn’t throw away Plasma because of Unity either). Whether Mir provides technical advantages or not cannot be judged right now, we will have to wait and see, then we can make a decision whether it’s worth to change our plans. So far I have not seen anything in the documentation that would look like an advantage over Wayland. Given the incorrect statements about Wayland I’m very skeptical whether there can be any advantages. I don’t want to go into detail, just look on the Internet there’s already enough information about that. Also one should consider that Canonical changes plans for their distribution every other day. Just consider the number of toolkits which have been used for Unity – given that I would not bet on Mir will be used next year and that means of course that we should not consider it for our planning.

Third question: Will KWin support Mir? No! Mir is currently a one distribution only solution and any adjustments would be distro specific. We do not accept patches to support one downstream. If there are downstream specific patches they should be applied downstream. This means at the current time there is no way to add support and even if someone would implement support for KWin on Ubuntu I would veto the patches as we don’t accept distro-specific code. If Mir becomes available on more distributions one can consider the second question. Given the extreme success of Unity on non-Ubuntu distributions I’m positively optimistic that we will never have to do the evaluation of the second question.

4. March 2013

This week in KWin (2013, week 9)

This week I can only present a very small summary. Somehow not much has happened, but the review list is getting longer. For users of Intel IvyBridge I would recommend to wait with upgrading to Mesa 9.1 till the release of KDE SC 4.10.1. One of our (optional) shaders seems to hit a performance regression on that driver. It’s not a really bad thing and we were quite lucky that we had a hot-fix for KWin on the day 4.10.1 got tagged. Thanks a lot to our users doing a git bisect on the mesa sources which allowed us to provide both commit and an example shader to the developers. This are the nice things about free software that make me really happy. Especially if you get in turn suggestions on how to improve the shader.