Posted on

Compositing and “lightweight” desktops

In the general discussion about “lightweight” desktop environments I have read a few times that one should disable Compositing in KWin. That’s done in Kubuntu’s low-fat settings package and also something Jos talked about in the context of Klyde.

I have never seen an explanation on why Compositing should matter at all. It mostly boils down to “OpenGL is evil” and “I don’t want 3D”. So let’s leave the “educated guesses” behind us and have a proper look to the question whether Compositing matters for “lightweight”. (Remember: lightweight is a buzz-word without any meaning.)

Let’s start from one of the “lightweight” aspects: Memory. For this it’s important to know that KWin is a Window Manager and Compositor. You cannot just have the Window Manager – even if compositing is disabled. It’s not like xcompmgr which runs in another process. For the binary that gets loaded into memory it doesn’t matter whether compositing is enabled or not. The pure binary containing both window manager and compositor has a size of 1.3 M (on Debian testing, that should be KDE SC 4.8). But when you enable compositing an additional library gets loaded containing the Effects. They are all in one library to not have to open 40 different files. (Again on Debian testing) This library has a size of 783 K. The effects do not link any library which is not already linked by KWin core, so that’s what we are talking about from additional memory costs when using any desktop effect from binary size: 783 K!

Obviously the binary mapped into memory is just one aspect. There are also additional data structures which need to be created on the heap. I have no idea how much is really needed and cannot properly look at my system because I have a KWin with debugging symbols loaded. What’s important to know is that only Effects one uses will get loaded and use memory for their data structures. Also the Effects do not load everything they need but wait till they get activated. E.g. the cube effect will only load a background texture if the cube gets activated. But of course effects do not have anything to do with just using compositing. If you don’t want an effect, just disable it.

The biggest cost from compositing in the memory perspective is probably using the XComposite extension which redirects the rendering into an X pixmap. That’s something which will go away once we are on Wayland as application and compositor share the buffer the application is rendering to.

But even so the usage of the additional memory is not just something which is thrown out. It’s just another case of the time-memory tradeoff. Unrelated windows do not need to repaint if a window get’s unmapped, moved or resized. Just look at this comment from the non-composited switching of virtual desktops:

During virt. desktop switching, desktop areas covered by windows that are going to be hidden are first obscured by new windows with no background ( i.e. transparent ) placed right below the windows. These invisible windows are removed after the switch is complete. Reduces desktop ( wallpaper ) repaints during desktop switching

Without compositing we move the time-memory tradeoff towards using more CPU (create those windows) to prevent even more CPU usage. With compositing we don’t have to do anything of it. So disabling compositing is obviously not the silver bullet for being “lightweight”. It just means moving the time-memory tradeoff slider towards CPU.

What remains is the OpenGL question. I know that many people think it’s about having a “3D desktop”. But the desktop I’m using is quite 2D-ish. There are people saying that 2D is just a special case of 3D. Looking at OpenGL that is certainly the case. As long as you don’t use any effect which needs the “3D aspect” of OpenGL, KWin just does 2D with OpenGL. Using OpenGL means to make use of hardware which is designed to do these operations instead of doing it on the CPU which is not designed for it. But what if one doesn’t have the hardware for it? A valid question, but just not in the context of KWin. If your system only provides software rendering KWin automatically falls back to XRender based compositing.

The last aspect to mention in the context of OpenGL is texture from pixmap. I don’t know how it’s implemented in the drivers so I don’t know whether that needs additional memory or not. But if you are concerned about it: XRender does not need a texture from pixmap.

So as you can see compositing comes with a little bit more memory usage but reduces CPU usage. It’s nothing I could say which one is generally better, but less CPU usage means a sleeping CPU. Granted some effects do animations – that also requires CPU usage. If you are concerned about that it’s better to disable the effects or set the global animation speed to instant than to just disable compositing completely.

And if you try to be “lightweight” and play with the compositing settings: one unrelated change can ruin all your benefit. Just imagine you would disable compositing because you want to be “lightweight” and then you enable a window decoration which uses QML (that is interpreted code) and does animations?

Posted on

Good bye Notifications

When I arrived at Tokamak 6 last week Alex was studying D-Bus communication between various applications. Before I had a chance to really sit down he complained about KWin talking to kded whenever for example a window got moved. This didn’t make much sense, so we had a look at it.

As it turned out that was KWin sending out notifications. Which immediately raised the question of why? Why would a user want a notification that he started/finished moving a window? After all it’s an action the user triggered. What should be done with the notification? Show a message? “You successfully moved a window!”, yes thank you I can see that on the screen. Play an annoying sound? Pling! Hopefully not.

Looking at what KNotify supports only logging to file or running a script make sense in response to the notifications emitted by KWin. But for logging to file it’s rather questionable why one would want that and why one would do that from inside a window manager. So what remains is running a script – fair enough that can be useful.

A closer look to the notifications emitted by KWin showed a few more things. None of them is configured to do something with the notification. By default KNotify just discards the notifications. This means we do a communication with kded via D-Bus for nothing. Two applications are getting woken up, context switches and so on for exactly nothing. Some notifications have a sound file connected to them, but are not configured to play that sound by default. We made a small quiz by me playing the sound file and letting the rest of the group guess what it’s for – I think nobody got one right. Nobody of the core workspace developers knew these sounds.

Looking at the code where the notifications are emitted highlighted another interesting fact. At all places we also emit a Qt signal which is mapped into the KWin scripting environment. And that’s actually quite awesome. Because unlike the notifications it has context. A KWin script does not only get informed about a window that gets moved, but about which window gets moved. Let’s say you are only interested in movements of Firefox windows – with KWin scripting that’s possible, with the notifications it isn’t. Given that we already identified that scripting (and maybe sound) is the only use case for the notifications emitted by KWin it’s getting more questionable why they are still around. Obviously they had been added long before we had KWin scripts. I was unable to really figure out when it got added, as git blame ends in one of the moving around code commits years ago (with more patience one can figure it out, but knowing that it’s old, was enough).

Of course we do not want to break our users’ workflow, so removing the feature is not easy. We have to properly judge whether the users’ workflow is valid enough to penalize all users by the additional overhead in code and in communication especially the context switches. Given that KWin scripting also allows to perform D-Bus calls, it should be possible to rework each of the previously existing notifications in KWin scripts.

That said: in case you were a user of one of those notifications and the removal breaks your workflow: please let me know. Please tell me how you used it and best provide your script. I will have a look at it and try to ensure that it’s still possible with KWin scripting (if it’s simple enough I will just port it).

Posted on

The History on Wayland Support inside KWin

Ever since a certain free software company decided to no longer be part of the larger ecosystem, I have seen lots of strange news postings whenever one of the KDE workspace developers mentioned the word “Wayland”. Very often it goes in the direction of “KDE is now also going on Wayland”. Every time I read something like that, I’m really surprised.

For me Wayland support has been the primary goal I have been working on over the last two years. This doesn’t mean that there is actual code for supporting Wayland (there is – the first commit for Wayland support in our git repositories is from June 11, 2011 (!)).

The Wayland research projects two years ago had been extremely important for the further development of KWin since then. First of all it showed that adding support for Wayland surfaces inside KWin’s compositor is rather trivial. Especially our effect system did not care at all about X11 or Wayland windows. So this is not going to be a difficult issue.

The more important result from this research project was that it’s impossible to work against an always changing target. At that time Wayland had not yet seen the 1.0 release, so the API was changing. Our code broke and needed adjustments for the changing API. It also meant that we could not merge the work into our master branch (distributions would kill us), we needed to be on a different branch for development. Tracking one heavily changing project is difficult enough, but also KWin itself is changing a lot. So the work needed to be on top of two moving targets – it didn’t work and the branch ended in the to be expected state. Now with Wayland 1.0 and 1.1 releases the situation changed completely.

The next lesson we learned from that research project was that the window manager part is not up to the task of becoming a Wayland compositor. It was designed as an X11 window manager and the possibility that there would not be X11 had never been considered. We started to split out functionality from the core window manager interface to have smaller units and to be able to add abstractions, where needed, to support in future more than just X11. That had been a huge task and is still ongoing and it comes with quite some nice side-effects like the rewrite of KWin scripting (helped to identify the interface of a managed Client inside KWin), the possibility to run KWin with OpenGL on EGL since 4.10, the new screen edge system in 4.11 and many many more. All these changes were implemented either directly or indirectly with Wayland in mind. That means we have been working on it for quite some time even if it is not visible in the code.

My initial plannings for adding Wayland support around October/November last year was to start hacking on it in January. I was so confident about it that I considered to submit a talk for FOSDEM which would demo KWin running on Wayland. In the end I decided against it as it would have meant working on some of our very important foundations under time pressure, which I don’t think is good for maintainability of the code base.

In December though I decided to adjust my plans and focus first on the Qt 5 port as that would allow us to use the Qt Wayland bindings which are a little bit more convenient for usage in a Qt based application than the native C library. This is not something I just come up with, I discussed this small adjustment with a few people (for example Aaron Seigo) at the Qt dev days last year.

On January, 22nd 2013 sebas outlined the time line for the transition to Qt 5 and Wayland of the KDE Plasma Workspaces. It clearly states that KWin will become a Wayland compositor and that this is a target we are working on with a clearly defined time line.

Given that I am really surprised to see media writing again and again that we started to work on Wayland because other projects deciding against or for Wayland. It’s not something we decided on recently and it is quite clear that our work does not depend on any decisions or announcements our competitors do. We are an independent project, which does it’s own decisions for long term planning. The fact that our work now shifts towards Wayland just at the time our competitors decide for or against Wayland is pure coincidence.

Last week we had a Plasma developer sprint in Nuremberg (thanks to SUSE) and of course Wayland was an important topic for discussion. We had many points on the agenda. After all it’s the first sprint for us since we work on Plasma Workspaces 2 and it is needed to define our direction for the next year. Given all that I wrote so far it’s rather obvious that we would have discussed Wayland even if a certain project would not have done a certain announcement. Some topics on the agenda were based on discussions we had on the mailing list before the certain announcement was made (I’m currently sitting in a train with not sufficient Internet connection so I cannot look up the reference). Which also shows that we had long term plans which were decided on long before the ecosystem shifted.

Summary: we had been working on Wayland for years and it is our long term strategy. Our strategy is of course not based on any announcements of our competitors. We of course need to evaluate new solutions available in the ecosystem when they come up. As I already pointed out in the past, this is not yet possible at the moment and all we can see so far is that Wayland is a better solution for our needs in the KDE Plasma Workspaces than other windowing systems which might be tailored towards the needs of our competitor’s desktop shell. One of the advantage of free software projects is that the development and discussions are open and that it’s quite easy to reach out to the developers and architects of the software.

Posted on

The relationship between Plasma and KWin in Workspaces 2

Yesterday during the Tokamak 6 sprint in Nuremberg we discussed the role of KWin in Plasma Workspaces 2. At the moment in Plasma Workspaces 1 KWin is of course the recommended window manager and compositor, but it’s also possible to use a different window manager. Back in the days there were quite a lot of users who run Plasma with Compiz. In theory that shouldn’t matter because everything is standardized with EWMH and ICCCM. Over the years we added more and more extensions to EWMH. It’s all open source so anyone can implement these extensions (Compiz used to do so), nevertheless right now there is probably no other window manager available to offer the full experience except KWin.

Plasma Workspaces 2 will be released at an interesting point of time. We don’t want to do the transition to Qt 5 and Wayland at the same time, so it will still be X based. But we all agree that our future will be on Wayland and even if we use X as the windowing system our primary focus is on Wayland. With Wayland quite a few things will change. KWin will play a more important role as it will be the Wayland compositor – we do not plan to use Weston.

Given that we know that the Wayland shell interface only covers part of what Plasma needs and some of our needs are extremely Plasma specific (for example Activities) it would be tempting to say that we tie KWin to Plasma. Let’s face it: which other compositor will be there to replace KWin? The reference compositor will probably never accept Plasma specific patches for things like Activities, Compiz won’t be ported to Wayland and GNOME Shell will probably never be a solution for Plasma. For the small window managers we do not know whether they will go to Wayland at all, but I expect rather not, though I expect that we will see Weston forks/extensions for substitutions of tiling window managers.

We decided to resist the temptation to go the easy road, but instead will develop all our integration bits in a way that one could replace KWin by a different Wayland compositor, even if that is just a theoretical option. Of course we will not do any fallback modes for the case that one is using e.g. Weston without Plasma integration bits. So the features which we need might then just be disabled. Adding fallback modes would most likely just result in bit rotting code as nobody would use it.

Of course to make it possible that others can provide compatibility features we need to properly document our extensions and additional interfaces. Luckily Wayland implicitly forces us to do so. The general plan is to publish our extensions and also try to standardize what makes sense to be standardized and we hope that this would also benefit other projects. What we especially had in mind is of course Razor-Qt which already supports using KWin. By properly documenting all our Plasma-KWin communication channel, they can also use what is useful to them and it ensures that we don’t break KWin in a way that it gets unusable for Razor-Qt.

Posted on

What makes a “lightweight” desktop environment lightweight?

Over the last few days I was wondering what is a “lightweight” desktop. And I must say I couldn’t come up with an answer to that question.

I was considering various things like “being memory efficient” which I discarded for obvious reasons. First of all it’s difficult to measure memory usage correctly (I haven’t seen anyone, who provides numbers, doing it correctly, this includes especially Phoronix). And then it’s comparing mostly apples to oranges. Loading a high-resolution wallpaper might make all the difference in the memory usage. Also if desktop environment Foo provides features which are not provided by Bar it’s obvious that Foo uses more memory. But still it’s apples vs oranges. It’s not a comparison on memory, it’s a comparison of features. And of course one might consider the Time-memory-tradeoff.

So is it all about features? Obviously not. If there is a feature a user needs and uses it cannot be bloat. The fact that a desktop environment has only few features cannot be the key to being lightweight. Being evil now: many people say GNOME is removing features, but nobody would say that GNOME is lightweight.

What about support for old systems? That’s not lightweight, that’s support for old hardware. And it’s something which doesn’t make any sense given Moore’s law. Which raises the first question: what is old hardware? One year, two years, ten years? Is it a moving target or is a Pentium III for all time the reference? Optimizing for old hardware means not making use of modern hardware capabilities. But does that make sense to not use modern hardware if it is available? Using the GPU for things the GPU can do better than the CPU is a good thing, isn’t it? Parallelize a computation on multi-core if possible is a good thing, isn’t it? But if you do so, you are optimizing for modern hardware and not for old hardware. So saying you are good for old hardware, implies you are bad on new hardware? Also I’m wondering how one can optimize for old hardware? Developers tend to have new hardware to not have problems like this. And how can one keep support for old hardware when the complete stack is moving towards new hardware? Who tests the kernel against old hardware? Who provides DRI drivers for obsoleted hardware which doesn’t fit into modern mainboards (who remembers AGP or PCI)? Who ensures that software is still working on 32 bit systems, who would notice such a breakage for example in the X-Server? So lightweight cannot be fit for old hardware. And remember: optimizing for old hardware is not the same as optimizing for modern low-end hardware. Even the Raspberry Pi has a stronger CPU (700 MHz) than the oldest Pentium III (450 MHz) – not to mention things like OpenGL…

What’s it then? Let’s ask Wikipedia. For Xfce it tells us, that “it aims to be fast and lightweight, while still being visually appealing and easy to use”. Unfortunately there’s no link on lightweight and also no reference. Let’s try again, LXDE: “The goal of the project is to provide a desktop environment that is fast and energy efficient”. Again no real definition and just stating a goal. But it goes on:

LXDE is designed to work well with computers on the low end of the performance spectrum such as older resource-constrained machines, new generation netbooks, and other small computers, especially those with low amounts of RAM.

I have no idea what a “new generation netbook” is, but it sounds like something modern half a decade ago. But we are down to the “being good on old hardware”, which we just discarded. Interestingly Wikipedia has references to prove that LXDE is good on RAM – unfortunately it’s references to Phoronix. Shame on you, Wikipedia, that’s a “benchmark” which has been considered seriously flawed by people understanding the topic.

Ok Phoronix aside, there is one more of the lightweight desktops to check. Razor-qt: “is a lightweight, Qt-based free software desktop environment for the X Window System. Unlike the KDE desktop environment which is also based on Qt, Razor-qt usually performs well even when used in computers with older hardware”. Damn, it again only claims and no reference for anything. Who says that KDE desktop environment (what’s that again?) is not performing well on older hardware? And what does the “usually” mean in that sentence?

So all Wikipedia gives us, is buzzword bingo and various claims without any proof (and not even a “reference missing”). Let’s try different and go to the projects directly.

Xfce tells us that it “is a lightweight desktop environment for UNIX-like operating systems. It aims to be fast and low on system resources, while still being visually appealing and user friendly.” Which sounds very similar to what Wikipedia wrote. Unfortunately nothing that tells us what lightweight means or what fast is or low on system resources. Fuzzy is fuzzy.

LXDE also has the same definition as shown in Wikipedia (maybe we should mark those wiki articles as advertisement?) but at least gives us a definition for what lightweight means to them: “It needs less CPU and performs extremely well with reasonable memory.” Fuzzy is fuzzy. What’s “reasonable memory” and “less CPU”? It goes on about various other things like “fast” and “energy saving” (which even are contradicting, e.g. fast is defined as working on hardware from 1999 and not require 3D – how that can be energy saving on new hardware one has to show me). The point energy saving is quite funny as it just says they are better than “other systems”. Oh well fuzzy is fuzzy.

Last but not least: Razor-qt. Razor doesn’t say it’s lightweight:

Razor-qt is an advanced, easy-to-use, and fast desktop environment based on Qt technologies. It has been tailored for users who value simplicity, speed, and an intuitive interface. Unlike most desktop environments, Razor-qt also works fine with weak machines.

Fuzzy is fuzzy. What’s a “weak machine”, what are the “most desktop environments”? Where’s the proof for other DEs not working well on those not-defined “weak machines”?

And here, poor fool! with all my lore I stand, no wiser than before. All what I could derive from studying what lightweight means is, that one just has to claim to be lightweight. Bonus points if you include it into your name. It seems like if you repeat it often enough people will repeat it and it will turn out into truth.

Posted on

Hitting walls – a story of Present Windows 2

One of my favorite User Experience elements in KWin is the Present Windows/Desktop Grid combination. For me those are the most important elements to switch between windows and virtual desktops. Although Present Windows and Desktop Grid are two different “effects”, I consider them us one because of their very similar functionality. The primary use case for both is to change the active window, the main difference is that Desktop Grid sorts the windows by virtual desktops.

The effects are so similar that they even share the code to lay out the windows. Nevertheless there are quite some differences in the functionality. The following features are only available in Present Windows:

  • Filtering of windows
  • Icon and caption on each window
  • Closing windows through a button shown on hover
  • Enlarging windows on hover
  • Mouse Actions
  • External activation (used by Netbook Shell)

On the other hand there are features in Desktop Grid not available in Present Windows:

  • Drag windows from one screen to another
  • Add/remove virtual desktops

The difference in functionality cannot be explained – there is just no reason for it. This is clearly a problem for our users – the effects look identical, but they behave differently. From all I learned about usability this is pretty bad because it teaches users to not trust systems.

The obvious answer would be to merge those two effects. But here we have a problem. Present Windows has been implemented to be Present Windows – no matter how we tweak it, it will be Present Windows. And Desktop Grid has been implemented as a Desktop Grid – no matter how we tweak it, it will be Desktop Grid.

I know that people will tell me that nothing is impossible. Of course one could hack around and make the effects be the same. But we have been there and tried to bring non-Present Windows functionality into Present Windows. I once implemented an Alt+Tab mode in Present Windows – a huge mistake. All it did was adding lots and lots of special case handling to make it work. And it castrated the effect. It only supported one screen (needed of course special hacks), it didn’t support filtering (keyboard grab hold by Alt+Tab framework) and so on and on. It never made any sense and I am very glad that I realized this error and removed the Alt+Tab mode again.

But also with Desktop Grid we made the experience by adding the layout mode of Present Windows. It wasn’t good for the code base. Nowadays, after I implemented that addition, I compare the code base of Desktop Grid effect to a Jenga tower which is already shaking and I fear that if I touch it to change something it will completely collapse.

A merge would only be possible by removing features and that is always difficult. People were really upset when I removed the Alt+Tab mode of Present Windows. Arguments do not work, giving replacements does not help and trying to improve the workflow is of course not welcome.

What remains would be a complete rewrite from scratch. But that’s a task so large that I consider it as a possibility for a Google Summer of Code project. Together the two effects have more than 4000 lines of code. It’s nothing we could do in parallel to our normal work and rewriting as a KWin Effect does not really make sense. Yes one can use Effects for that but it’s rather limited.

One of the most clear disadvantages is that Effects require Compositing. While having always composited systems becomes more and more the reality, there is still no reason why there should be the break in the user workflow when turning off Compositing and I have had many discussions with users who did not understand that.

But the real problem is that we do not have a toolkit inside the Effects. We are down to key press/release events and mouse motion/press/release events. That’s rather limited. For the close button inside Present Windows we do quite some hacks to get the mouse events injected into the QWidget. It’s a hack and nothing that scales. Key events are not composed correctly – for example on my English keyboard I’m not able to write letters like “ä, ß” in Present Windows. But the real problem is the handling of things like the drag and drop of windows in Desktop Grid. The code is extremely nested (seven indentation levels) and has to cover many, many corner cases. It just shows how difficult it is to get that handled correctly with different modes.

But since recently we have a technology which solves many of these problems: QML. With QML we get a toolkit which we can use to properly interact with the windows and which is supported in both composited and non-composited setups. In combination with our KWin scripting framework we have capabilities which are quite similar to what our effects can do. As a nice side-effect QML forces us to separate logic from visualization which means that the logic of Present Windows/Desktop Grid could be reused and combined with new ideas of how to represent the data.

This week the logic part entered KWin’s source repository in form of a QAbstractItemModel which is exported to QML. The model is quite flexible and allows to sort the windows in multiple levels – currently it supports screens, virtual desktops and activities. In addition one can specify whether a window should be excluded. That’s for example important to have the different modes of Present Windows – there is one mode for only current desktop and one mode for only windows of the currently active application.

Having a model makes it rather easy to support filtering – we just need to connect it to a QSortFilterProxyModel and such a model is already provided and exported to KWin’s QML binding.

Implementing the logic for Desktop Grid inside QML becomes now as simple as:

ClientFilterModel {
    id: filterModel
    clientModel: ClientModelByScreenAndDesktop {
        exclusions: ClientModel.NotAcceptingFocusExclusion | ...
    }
    filter: filterItem.text
}

The idea is now to use this as a base for what I call “Present Windows 2”. It’s nothing I target for 4.11, because of the complexity of Present Windows and Desktop Grid. I hope that many things become easier once we are on Qt 5 and QtQuick 2. So it’s something I want to have for Plasma Workspaces 2. I’m still wondering whether to optionally include the current proof of concept QML script which renders a screen like this:

Aus KWin

One can already see the improvements like an always visible filter area. That’s one of the real disadvantages of the existing Present Windows effect: one doesn’t get any hint that it is possible to filter the shown windows. Also a clear improvement in this variant is the always visible close button for each of the windows.

The new models included in KWin might also get new tasks I haven’t thought about when I started to work on it. Our Plasma developers noticed that this would be a rather good base for the tasks applet. Whether that’s possible or not we do not yet know, but it would have clear advantages to have a shared code base for all the different ways of getting an overview of open windows.

(Sorry for having once again written such a long blog post)

Posted on

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.

Posted on

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

        Posted on

        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.

        Posted on

        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.