Posted on

Akademy Impressions

Yesterday evening I returned from this years Akademy which means that today is a perfect time to reflect some of the impressions.

Overall I think this was one of the best Akademies I have attended so far. The atmosphere was just great, the location was overall quite good and the weather was awesome.

Akademy started for me at Friday with the AGM of the KDE e.V. It was a very interesting AGM. I think it was a good decision to move the AGM to Friday and hope that also next year will be like this. If you are interested in more about the AGM, just read Mirko’s blog post. A small reminder: if you are a supporting member of KDE e.V. you are allowed to join the AGM, but without voting rights.

On Saturday and Sunday we had the conference with the talks. I myself had 1.3 talks – the Quality talk I shared with David and Vishesh. Once the recordings are available I recommend to watch it as it also addresses the shorter release cycle discussion and why I think that this would improve our quality. Speaking about the shorter release cycle: we had a very constructive BoF later the week and I think we found a very good compromise to move forward.

The keynotes were overall quite good, I was especially interested in the Jolla keynote. But also Kevin’s keynote about the KDE democracy is worth watching. Quite interesting was the discussion about “Respect the elders” and what makes up a KDE project. That we discussed that the Linux kernel could not be a KDE project because of their bad mailing list communication skills is quite a saying. As if we would have known that LKML would become a big topic a few days later.

The most interesting talks from my perspective were of cause the technical ones. I really enjoyed Volker’s expression template talk covering the topic of implementing domain specific languages with the help of C++ meta programming. Also Milian’s talk about improving the performance of C++ is something you should watch if your application is critical (also if not). KWin already gained the first improvements thanks to this discussion. And more will follow.

The conference ended with the Akademy Award ceremony. I am quite happy with the decision the jury took – especially given that I thought about two of the winners last year when I was a member of the jury. So to say we chose a good jury last year 😉

What made me really happy at this years Akademy is that we are broadening our scope. This year we had talks about Mer and Razor Qt and like last year members of the VideoLAN project were around. And of course there was the Qt Contributor Summit co-hosted on Monday and Tuesday – though I did not attend any discussions.

Instead I spent most of Monday at the Kubuntu BoF and tried to give some useful feedback from an upstream perspective. And also of course my personal opinion like I would love to see Debian KDE and Kubuntu packagers to work more closely together. During this BoF we got an overview of the LiMux project of the city of Munich. It’s great to hear that we will soon have 15.000 KDE SC 4.11 installations, but this will take some more time – enterprise setups move rather slowly compared to us 😉

On Wednesday we had the release cycle BoF. I think the outcome is really good and I hope that the community agrees to trying this out. So far the discussion had been very positive and I am really happy that we can get in all the stakeholders. That distributions can share their opinion just as an equal is quite a positive sign that the communication between upstream and downstream is really good in KDE. In fact for quite many distributions I am not able to say if a developer belongs more to KDE or more to the distribution.

In the afternoon we had the day trip to the sea side. Thanks to that I can check the box for “swim in sea once a year” for 2013. In the evening we had a wonderful meal before heading back to the hostel.

On Thursday we had a Bof on Plasma Active, but apart from that I did not attend any further BoFs as I had to head to the airport in the late afternoon. Travel back was quite smooth and way better than the travel to Akademy. I almost missed my flight because the 30 min travel from Mannheim to Frankfurt Airport took 90 min with Deutsche Bahn. On the positive side I did not have to wait for the security check 😉

Looking forward to next years Akademy wherever it will be.

Posted on

An unexpected journey

Since my last post quite some progress has been made in getting KWin working on top of a Wayland compositor. My main focus of work has been on the input stack. This is something I am not really familiar with as so far we did not have to care about it.

As some might know input handling in X11 is very insecure. Every application is able to listen to every key event. And in the KDE workspaces we obviously make use of these “features”. For example the global shortcut handling is implemented as a kded module listening to all key events and notifying the application via D-Bus that the shortcut got triggered. In a post-X11 world this will not work any more: applications are no longer able to listen to all key events.

One of the important tasks therefore is to not send all input events to the
X-Server but just to the window which should get it, or to handle the input events inside KWin and discard them without passing to the applications. My current branch already supports activating screen edges and using fullscreen effects like Present Windows completely without passing the input events through X. This means that some of the longstanding issues are automatically resolved. We no longer “steal” the screen edges from applications and starting the screen locker should be possible even if present windows is active (not tested and still needs some screen locker support in KWin).

But this also means that features like the global shortcut handling start to break. Mostly because kded is not listening on my virtual X but that’s just detail 😉 So I also had to start working on global shortcut support inside KWin – otherwise I would have had a hard time to use some of the important features like switching desktops or using Alt+Tab. At the moment the latest code only supports KWin’s internal shortcuts, but global support for kglobalacceld will have to follow. We had some ideas on how to improve global shortcut handling in general anyway.

When the infrastructure was in place I couldn’t resist the temptation to work on features which had been requested for a long time and were not really possible to do with X11 (or only with huge hacks): mouse shortcuts. Ctrl+Alt+left click activates desktop cube. But that’s not enough. While sitting in the Kubuntu Developer Summit I added also mouse wheel support which allows us to ctrl+alt+wheel to switch desktops and also to use the zoom effect. This work can be found in branch kwin/global-shortcuts on my personal workspace clone.

I hope that we will soon have a decision on the “what’s master” discussion and I can start merging the changes in. Once this is done I plan to switch focus to the Qt 5 port and concentrate on this for the next few weeks.

Nevertheless this should not be a reason to stop the work on the Wayland efforts. There are so many small things which can be done and lots of low hanging fruit. I will try to setup a trello board with a few tasks, so that interested developers could start picking up some easy tasks and get their hands dirty. Once something is in place I’ll write another post.

Posted on

More Software Compositing

One of the most often repeated misconceptions about Wayland is that it requires hardware acceleration. I would have thought that this issues would have been resolved once the reference compositor, Weston, supported rendering through Pixman. The reason for this misconception is most likely that the earlier versions of Weston required hardware acceleration.

Now KWin in 4.11 introduces the same mistake. Our experimental Wayland support is only available in the OpenGL compositor – even OpenGL ES is not supported (something is broken on my system I cannot start it). I think this is a bad situation. One of the huge advantages of KWin is the exchangeable compositor allowing to switch to software based XRender in case there are no proper drivers available. In fact KWin switches automatically to XRender if it detects a driver which recommends the XRender backend (e.g. software rasterizer).

So last week I started to work on some new Wayland related features and extended the XRender compositor in a way that it renders to a Wayland surface. It’s a pretty simple setup. Our XRender compositor uses an off-screen pixmap for rendering. The adjusted backend uses a pixmap created through XShm, so we get the frame rendered into a shared memory segment. From there we just copy it into a shared memory Wayland buffer to share it with the Wayland compositor. It would be better if we could create the shared Wayland buffer directly from the XShm segment, but I did not see a solution on how to achieve this.

In the end it’s also not really relevant. After all we want to use Wayland and the last thing we want to do on Wayland is using an X11 rendering API for compositing. So we can consider this more as a proof-of-concept and as a task so that I can get more familiar with Wayland 😉 It helped me to improve the code, so it was worth the effort. Even if it is a more academic solution it serves a concrete use-case: KWin uses XRender as a fallback and we can expect that the backend works. Given that we have to enforce compositing in future, it’s good to know that all backends work. The current state of this work can be found in branch kwin/wayland-backend of my clone (note: the link might change in case I force push).

Video on YouTube

If XRender is an academic solution, we are still facing the problem that we lost our software compositor. So I thought I need to also do something about this problem and started to work on a new compositing backend based on QPainter. It’s a quite simple compositor which uses a QImage as the rendering target. The QImage is created directly from the Wayland buffer, so in opposite to the XRender backend we don’t have the needless memory copy from one to another buffer. This is a very interesting compositor as it’s the first part of KWin which has been written from scratch only with Wayland in mind. It doesn’t support X11 (at the moment). This is the first new compositor written in years, so I found some things to improve and which are already under review. And as it was much easier to write a new compositing backend than I expected, I decided to document it in our wiki. It would be totally awesome if someone could have a look at it and write a dedicated compositor for the RaspberryPi 😉 The new compositor can be found in branch kwin/qpainter-scene.

The switch to Wayland does not only affect our software compositors, but compositing in general. So far KWin has always had the possibility to not require compositing. This doesn’t make any sense in a Wayland world. So I needed to teach KWin that we might need to enforce compositing. Of course on X11 we still want to have the option to disable compositing, so the changes only affect the Wayland backend. When starting KWin with the Wayland display environment variable set, KWin will require compositing. Even if it is disabled in the config options it will be enabled. Even more it ignores the shortcut to suspend compositing and options like unredirection of fullscreen windows. But still the backend might fail and in this case KWin is just exiting. There is no need to continue execution if one cannot see the output. This work can be found in branch kwin/enforce-compositing (which also contains all the other mentioned branches).

Posted on

What we did in KWin 4.11

With the release of the 4.11 Beta 1 behind us it’s a good moment to look back on this last half year on development. KWin 4.11 is a very important release for us. As you might have heard at the last Plasma sprint we decided to make 4.11 the last release of the KDE workspaces based on Qt 4. Fear not: the KDE Software Compilation with all it’s great application will see a 4.12 release – at least I have not heard anything else, just the workspaces need some time to do the Qt 5 transition. In addition we want to provide extended bug fix releases for the 4.11 release of the workspaces. So 4.11 is a very important release – being the bridge towards Qt 5.

This is clearly what dominated the development of this release cycle. While porting to Qt 5 is easy in 99 % of the cases, KWin hits the 1 remaining per cent. There are many non-portable X11 specific features in Qt 4 and sometimes I think we used them all and all of them got removed in Qt 5. That’s not a bad thing – in fact I think it’s a good thing. I don’t want to go into detail about the problems we hit and why we used these Qt features in the first place – if you are interested come to my Akademy talk.

In many cases the changes in Qt required to rethink the problem. A good example is that a QPixmap no longer references an XPixmap which we heavily used during rendering the window decorations. This was causing us quite some performance problems with the combination of Qt graphics system raster and the XRender compositor. At the moment I’m running this combination without any noticeable performance difference thanks to the restructuring forced by preparing for Qt 5. Also in the OpenGL case the decoration rendering got quite improved thanks to Fredrik forcing me to improve the proposed changes and also doing some further changes.

Speaking on performance improvements: Fredrik reworked our OpenGL 2 compositor code base and also introduced a new OpenGL 3.1 code path. By default we still use OpenGL 2 with the fallback to OpenGL 1, but one can easily switch. If the hardware doesn’t support OpenGL 3.1 it automatically falls back to OpenGL 2 or OpenGL 1. When running kwin_gles we default to OpenGL ES 3.0 if present otherwise OpenGL ES 2.0 is used.

But that’s not the only change done to the OpenGL compositor. Thomas and Ralf worked on improving our v-sync behavior. There are now multiple strategies one can choose from – this should help to serve all use cases and setups in a better way. Buffer age support has not made it for 4.11 yet, but I’m quite confident that this will end up in the next release.

One of the tasks we continued from 4.10 is the porting to XCB. This also forced us to rethink some of our code. One of the areas which got rewritten because of this is the screen edge handling. It’s now finally multi-screen aware, but still only the four real corners can be configured, corners between screens don’t make much sense. And here with the screen edges we have one of the few user visible changes in KWin: a highlight when approaching the edge. So this hidden feature is finally no longer hidden.

Another small visual change is concerning the outline when using quick tiling/maximizing on screen edges. The outline should now better indicate what area will be covered by the window. Also based on common feedback the moved window is put above the outline. This used to cause problems with dark Plasma themes causing.

The last changes I want to mention are some effects rewritten in JavaScript. This is mostly to improve the maintainability of the code. The JavaScript effect API is optimized for animating windows based on state changes. If I remember correctly the rewritten effects are Dialog Parent, Login, ScaleIn and Translucency. Thanks to Kai Uwe for helping us with these tasks. There are still a lot of effects which would benefit from this work. So get your editor ready 😉

Overall the effects have seen some changes. BoxSwitch effect got finally the kick as the functionality is now completely available in the QML Window Switching functionality. Explosion got the kick as it has been unmaintained and broken for a long time. The Outline is no longer implemented as an effect, but moved back into KWin core. The add/remove desktop button in Desktop Grid and the close window button in Present Windows got reworked with QML and Plasma components – another nice improvement thanks to Qt 5. Present Windows has also an unpopular change: the mouse action for closing a window got removed. But also we have the code ready to rewrite Present Windows and Desktop Grid with QML (a task for next version). The Maximize window effect got a nice improvement in the OpenGL compositor: it cross fades with the previous window texture which removes the up/down scaling which was not looking that nice. Thanks to Aurelien for writing software exposing bugs in KWin which require reworks allowing to implement this feature.

I’m quite sure that I have forgotten to mention many really important changes which we did over the last half year. It’s a long time and after all we changed 666 files with 32516 insertions and 29217 deletions (git diff –shortstat v4.10.0..master — kwin (master being 4a172a9d)) including the changes by scripty.

Posted on

Fanboys in Free Software

Years ago I had a clear political opinion. I was a civil-rights activist. I appreciated freedom and anything limiting freedom was a problem to me. Freedom of speech was one of the most important rights for me. I thought that democracy has to be able to survive radical or insulting opinions. In a democracy any opinion should have a right even if it’s against democracy. I had been a member of the lawsuit against data preservation in Germany. I supported the German Pirate Party during the last election campaign because of a new censorship law. That I became a KDE developer is clearly linked to the fact that it is a free software community.

But over the last years my opinion changed. Nowadays I think that not every opinion needs to be tolerated. I find it completely acceptable to censor certain comments and encourage others to censor, too. What was able to change my opinion in such a radical way? After all I still consider civil rights as extremely important. The answer is simple: Fanboys and trolls.

When one starts to have a blog in free software one learns the hard way that being a relatively good developer means that you get hated. If you achieve something you get attacked, you get insulted, you get called a dictator [1], you get compared to Hitler [2], etc. etc. People say that you need a thick skin if you want to work in free software. I disagree. There shouldn’t be a need to have a thick skin. We are improving the world, we donated lots of our spare time to work on free software, we donate the source code we write for the public good and we are thanked by insults. This is not acceptable! Even if people dislike some specific software or are a great supporter of another software there is no reason to insult the people or the products. It never is! Not even if it is Microsoft or Apple or Google. There is no reason to attack them.

One of the first experiences I made in this regards was blogging about performance improvements. We can see that most users are thankful for the improvements but that there are also direct attacks. These are irrational, why would one attack the person who improved the situation? Why kill the messenger? People tend to discard it as “haters gonna hate”, but is that the answer to the problem? Do we have to tolerate such comments? Do we need to be hated just because we improve software and blog about it? Nowadays I would just delete such comments, that’s the change in my reaction to handle such situations. My skin became thicker over the years, but overall I prefer to have a thin skin as I used to have – it fits my overall character better.

Over the years I started to observe the behavior of the “haters”. For example I noticed that in the time after the release of GNOME Shell and Unity the hate against KDE increased. This was irrational, especially the reasons for the hate. KDE’s software had matured at the time when GNOME Shell and Unity did their release, so why attack KDE then. Yes after 4.0 that was kind of rational, but the attacks had mostly stopped. So why did they start again? I’m nowadays quite sure that if we would go back we would find an increase of attacks against GNOME at the time of 4.0/4.1.

Free software users are very enthusiastic about their used software. One could even say that they are religious about it. Not only that they also create a kind of split between mostly GNOME and KDE community. The decisions to use either KDE Plasma or GNOME Shell are hardly rational. There are emotions involved and used at the rational for why one uses KDE Plasma or GNOME. The software of the other projects is evil and one cannot use it. We tend to call users with such opinions as “fanboys”, but I find this word unsuited, I call them “religious fanatics”. I will explain in more detail why I compare to religion later on.

Now we all know the irrational reasons on why to not use GNOME software. GNOME is removing features, they are “interface Nazis” and don’t care about their users. KDE software on the other hand is ugly, too complex, slow and unstable.

When basing your decisions on irrational reasons it is inevitable that you will face cognitive dissonance. The introduction of GNOME Shell and Unity at the same time are good examples for triggering cognitive dissonance. The fanboys are convinced that GNOME is the best software in the world, but now they are transited to at that time incomplete software breaking their existing workflows and requiring to relearn. Many things are no longer possible. The belief that GNOME is better than KDE software is seriously challenged by the new experience.

One of the solution to solve this cognitive dissonance is to make KDE software worse in comparison to GNOME Shell or Unity. Being convinced that KDE software is still worse than the other software the dissonance is resolved. That is a blog post about performance improvements is a wonderful way to be confirmed that KDE software is slow, a news about fixed bugs is a wonderful way to show that KDE software is unstable. This explains the strong hate against KDE starting with the releases of GNOME Shell and Unity. Fanboys are trying to resolve their cognitive dissonance.

Obviously GNOME Shell and Unity are only an example. We can observe the same kind of cognitive dissonance with KDE fanboys. An example I can observe in regular intervals is that “the next version is much better and solves all problems” whenever a user is reporting about instabilities or other problems. The fact that another user is experiencing problems is challenging the beliefs of the fanboys which can be resolved by stating that the next version resolves it. We can see these comments for each version since 4.1.

Quite recently we could observe the same kind of cognitive dissonance with the Ubuntu fanboys. Mir was a real challenge to anybody who deeply believes that Canonical is doing the right thing all the time. Given that I wrote a few blog posts on that topic I was able to observe how fanboys tried to resolve their cognitive dissonance. My favorites were that I am the reason why free software is failing because I don’t support Mir. Canonical made it quite difficult for their fanboys to resolve the created cognitive dissonance. Of course reasons were provided but those had been shown as wrong very fast. Fanboys tried to resolve the dissonance by coming up with reasons like “development was too slow, someone had to do something”, which didn’t really resolve it as it’s obvious that the development power would have also helped Wayland. Just yesterday I was able to observe a fanboy in my blog comments. “Please re-read it and make it logically sane and spelling error free.” A wonderful example of adjusting the reality by making my arguments invalid because I had a typo in a reply. My argument that we cannot support distro-only solutions got discarded because there is also YaST which is also distro-specific. On a rational view this argument doesn’t make any sense but under the light of resolving cognitive dissonance it makes all the sense in the world. The fact that distro-specific software is a problem is diminished by pointing out other distro-specific software even if doesn’t matter for the argument (we do not depend on YaST).

I consider these fanboys as a threat to free software. By being irrational they harm everyone. They use emotions for something which should not have emotions. They make it difficult to work in free software. In fact it’s not a problem specific to free software, but can be observed overall in IT. Apple is also a good example for such fanboys. But only in free software fanboys can interact directly with developers and spread their harmful behavior. In the proprietary world they are blocked at the marketing department which is trained to work with such situations.

We need to find solutions to the fanboys and one of the solutions I came up with is to block them on my blog posts. I can tolerate trolls as it’s much easier to handle them. But fanboys are only there to harm you to diminish your work so that their world view doesn’t break. And that’s why I call them religious fanatics. They behave exactly the same. Just compare that to Intelligent Design to resolve the cognitive dissonance caused by evolution. I dislike any religious fanaticism whether it’s a crusade, jihad, IRA or free software. Any religious motivated fanaticism is harmful and needs to be fought, even if it is free software. Yes one can grow a thick skin to handle the fanboys, but that just shouldn’t be needed. Being compared to Hitler hurts no matter how thick your skin is. And if a GNOME developer stops work because of KDE fanboys it’s not GNOME who lost a developer, it’s free software who lost a developer. It’s one of us. We are also GNOME!

Final remark: please don’t come and tell me that I’m the same by criticizing Mir. It’s not the same. Criticizing decisions and having discussions is important, but of course critic has to be constructive. I have never attacked any of the Mir developers or have attacked the software in any way. I criticized the decision and the reasoning and pointed out the problems it causes for us, but I have in no way attacked Canonical, Ubuntu or Mir.

[1] Yes there are free software developers who are called a “benevolent” dictator. I disagree. There is no such thing as a benevolent dictator. Every dictator is bad and one shouldn’t define dictatorship down by calling someone a benevolent dictator.

[2] Yes all of that happened to me. Someone even compared me to one of the worst mass-murderers in human history because I do free software and have an own opinion.

Posted on

Starting a full KDE Plasma session in Wayland

This week there will be the release of KDE SC 4.11 Beta 1 and this will come with an interesting new feature: an experimental Wayland backend inside KWin. This backend does not allow to manage Wayland clients, but uses another Wayland compositor as the rendering target. Instead of rendering to an X window, KWin renders to a Wayland surface. From an architecture point of view this means that there is a Wayland system compositor and KWin is running as a Wayland session compositor (although KWin is not yet a Wayland compositor).

Disclaimer: this is a highly experimental feature and not intended for productive usage. Please do not report any bug reports in the bug tracker. If you find an issue please open your editor, hack and submit a review request.

Now I expect that you are also excited about Wayland and that you want to run your KDE Plasma session on top of Wayland instead of X, right? So here are the instructions: First of all you need to change the “Tearing Prevention (VSync)” in KWin’s Advanced desktop effects settings to “Full scene repaints”. This is needed because KWin does not yet support the buffer-age extension needed to properly repaint in Wayland. Note: when using X11 you probably don’t want to use this option, it wastes quite some power.

The KDE Plasma session startup is controlled by a script called “startkde”. In order to start the KDE Plasma session with Wayland we also need this script, but need to have a few environment variables set to tell KWin that it should use Wayland. So best copy this script and call it” startkde-wayland”. Edit this file and add the following exports after the shebang:

export DISPLAY=:99
export WAYLAND_DISPLAY=wayland-system-0
export KWIN_OPENGL_INTERFACE=egl_wayland

Now all we need is another small shell script to start Wayland, Xvfb and the modified startkde script. Let’s call it kwayland:

#!/bin/sh
weston-launch -- --socket=wayland-system-0 &
Xvfb -screen 0 1366x768x24 :99 &
startkde-wayland &

Please change the screen resolution to the one used by your screen. KWin is not yet able to update the resolution of the X server to what Weston uses. This also means that you cannot change the resolution or add multiple screens (as I said: it’s an experimental feature).

Now log out of your running KDE session, switch to a tty and stop the still running X server. With X out of the way you can start the kwayland script. You should see Weston starting and shortly afterwards KWin should take over. If everything is configured correctly you should see the normal splash screen (seems like my system is not configured correctly).

Once the system is fully started you can just use it. If everything works fine, you should not even notice any difference, though there are still limitations, like only the three mouse buttons of my touchpad are supported 😉 I would post a screenshot but it’s fairly uninteresting as one cannot see a difference.

This blog post was written in a KDE Plasma session running in Wayland.

Posted on

New KWin Scripting Feature in 4.11

Today is the feature freeze for 4.11 which is a good point in time to blog about the new functionality in KWin Scripting in the upcoming 4.11 release.

Configuration Interfaces

Since 4.11 our scripted components support configuration interfaces. Already in previous releases it was possible to define a KConfigXT file which can be read in the script. In 4.11 it’s now possible to have a ui-file bound to the KConfigXT file and KWin generates a config module from these two files. All that is needed is to modify the metadata.desktop file so that KWin knows that this script comes with a config interface:

X-KDE-PluginInfo-Name=kwin4_effect_foo
X-KDE-PluginKeyword=kwin4_effect_foo
X-KDE-Library=kcm_kwin4_genericscripted
X-KDE-ParentComponents=kwin4_effect_foo

The X-KDE-Library needs to be set to “kcm_kwin4_effect_genericscripted” and X-KDE-ParentComponents and X-KDE-PluginKeyword need to have the same value as X-KDE-PluginInfo-Name. The KConfigXT file is expected in contents/config/main.xml and the ui-file is expected in contents/ui/config.ui.

If these few steps are followed the effect respectively the script KCM shows a configuration button for the component.

Set and Cancel Animations

The animation API got a small addition: each animation has an id which can be canceled later on with the id. Cancel stops the animation immediately, it is not reverting the animation. So if one wants to revert the animation one still needs to schedule an additional animation.

Canceling an animation for itself is not that interesting, but in combination with another new feature it becomes very important: set animations. The new set animations are just like a normal animation but they stay in the final animation position until the animation gets canceled. A normal animation just performs the state changes, e.g. fading in or out a window. But it’s not possible to fade out a window and keep it faded out. When the animation ended the window will be visible again. Now the new set animation will keep the window faded out. This is used for example in the JavaScript version of the translucency effect to animate the moving of a window:

moveResize: {
    start: function (window) {
        window.translucencyMoveResizeAnimations = set({
            window: window,
            duration: translucencyEffect.settings.duration,
            animations: [{
                type: Effect.Opacity,
                to: translucencyEffect.settings.moveresize / 100.0
            }]
        });
    },
    finish: function (window) {
        if (window.translucencyMoveResizeAnimations !== undefined) {
            // start revert animation
            animate({
                window: window,
                duration: translucencyEffect.settings.duration,
                animations: [{
                    type: Effect.Opacity,
                    from: translucencyEffect.settings.moveresize / 100.0
                }]
            });
            // and cancel previous animation
            cancel(window.translucencyMoveResizeAnimations);
            window.translucencyMoveResizeAnimations = undefined;
        }
    }
}

This code snippet shows how to use the set animation and where one can best store the returned id: just use dynamic properties on the window. Also it shows how the animation can be reverted by specifying an animation in the opposite direction.

When using the set functionality one needs to be aware of one aspect of the behavior which can be considered as a disadvantage: the window will considered to be rendered with this animation until it gets canceled. Even if the window gets closed, minimized, activity changed or virtual desktop changes. The window will be there. So one needs to connect to events which could make windows go away and cancel the animations. Also when a window becomes visible again one should start the set animation again. There is a very easy test to see whether a window is currently visible: a new property called visible which is defined on the EffectWindow. It’s true if the window is currently not minimized, on the current desktop and on the current activity.

New Animation Types

4.11 also allows to animate in two new ways. There is Effect.DecorationOpacity which allows to just animate the opacity of the window decoration without changing the opacity of the whole window. Like before using Effect.Opacity animates both window content and window decoration. Obviously this only works with server side decorations.

The other new animation type is Effect.CrossFadePrevious which is a rather interesting new animation type for improving animations when the size of the window changes. When used KWin will keep the previous window texture and render it on top of the current window texture. This allows to cross fade from the previous window size to the new window size. If one wants to see it in action: the maximize effect is using it. This feature is currently only available in the OpenGL compositors.

New QML Components

The KWin QML Scripting API got extended by one new component: DesktopThumbnailItem. This component can render a preview of a virtual desktop:

KWin.DesktopThumbnailItem {
    id: thumbnailItem
    clip: true
    desktop: model.desktop
    anchors {
        fill: parent
    }
}

This component is used for example in one of the new desktop switchers.

Client Models

4.11 comes with a set of new models which can be instantiated in QML.

ClientFilterModel {
    id: filterModel
    clientModel: ClientModelByScreen {
        exclusions: ClientModel.DockWindowsExclusion
    }
    filter: screens.filter
}

These models are meant to be the base for functionality like Desktop Grid or Present Windows. 4.11 includes a SimpleClientModel, ClientModelByScreen and ClientModelByScreenAndDesktop. More models can easily be added, just let me know what you need. Also there is the ClientFilterModel which is a helper model to perform searches like known from the Present Windows effect.

Although these models are shipped in 4.11 KWin does not yet use them. They are meant to replace Present Windows and Desktop Grid in future, but this has to wait for QtQuick 2.

Posted on

Announcing the Duplicate Finder

DrKonqi is really awesome in finding possible duplicates when a new crash report is created. This makes the work for triagers much easier because they get the information directly in the report. But my work with bugzilla shows that it’s not good enough. In many cases one gets a list of about five bug reports which are all marked as duplicate of another bug. So which one is it? One has to click all possible duplicates and trace them down. Sometimes one finds not triaged bugs, sometimes they all link to the same bug.

What one would want is to get presented the most likely duplicate directly to start with. And it would also be awesome to see all related crash reports which are not yet triaged. I spent some time thinking about it and thought that there most be an automated solution to this problem. We have the information on which are the possible duplicates, we know that the possible duplicates have further possible duplicates and we have the duplicates directly. So overall there is a network which goes from our report we start with directly to the report which should be used as the duplicate. If we add all the links we get a most likely duplicate, just need to compare the backtrace and are happy.

So I started to work on this using bugzilla’s WebService API to query a bug, find the duplicates and start to connect the various reports in a graph. The result is:

duplicate-finder

It’s a small application which takes a bug report, loads it and builds up the graph of all related crash reports. It finds the most likely duplicate and offers to mark the selected bug as a duplicate. The visualization helps to see whether there are further reports in the network and one can use the tool to also mark those as duplicates.

I hope that this is a useful tool for our bug squad team. It can be downloaded from my scratch repository. As dependencies it needs QJson, Qt4, kdelibs4 and kdepimlibs4. As runtime requirements it needs dot (Graphviz) and you should have a mailtransport configured in KMail. This is needed to mark the duplicate reports.

To start the tool use:

./duplicatefinder --from=your-bugzilla-address@email.de bugid
Posted on

KWin running in Weston

This week I decided to do some research for the Wayland porting of the KDE Plasma workspaces. One of the features we will need in future is a Wayland session compositor which runs nested on a Wayland system compositor. Of course one could think of setups without a system compositor, but overall I think that a nested compositor simplifies the setup and allows to have all the low level technologies in one place without duplication in all the various compositors. +1 for working together.

After three days of work I already have something to demo (video on youtube):

Sorry for the bad audio. I’ll just explain what one can see. The video starts with the normal X-Server. After that it switches to a VT and we start Weston there. On Weston I’m starting KWin with some environment variables set to pick the correct libraries and force KWin into Wayland mode. KWin creates a connection to Wayland, creates a Wayland surface and uses it for OpenGL output. All the windows from the running X Server are rendered into this surface just as if it were a normal X11 output.

KWin also gets input from Wayland and passes it to the X Server. That’s the reason why we can see mouse interaction and working keyboard.

How it works

The OpenGL backend

KWin supports multiple backends for providing an OpenGL context and doing the texture from pixmap operation. At the moment we have an GLX and an EGL backend. Both create the OpenGL context on the XComposite overlay window and provide the texture from pixmap in the GLX case through the GLX_EXT_TEXTURE_FROM_PIXMAP extension and in the EGL case through the the EGL_KHR_image_pixmap extension.

A new backend is added which creates the OpenGL context on a Wayland surface. The backend started as a fork of the existing EGL backend with the X code stripped out. What’s a little bit tricky is getting the texture from pixmap working. The extension used in the normal EGL on X11 backend is not available. The proper solution would be a setup with XWayland, but that’s still too early as KWin does not yet support Wayland clients.

The solution I came up with is inspired by a fallback mechanism in KWin from the time when GLX_EXT_TEXTURE_FROM_PIXMAP was not guaranteed to be around: XShm to copy the pixmap content into an OpenGL texture. Not a nice solution but it works.

Input handling

Input is currently also a rather hackish solution until we have XWayland up and running. We just take all input events and forward them to the XServer with the XTest extension to inject fake events. It’s a huge hack and one can see how old X is there and how limited. I was rather surprised that it works at all. At the time of this writing the code supports keyboard events and the left, middle and right mouse button. Wheel events are tricky as X uses mouse buttons for them and for more mouse buttons I have problems with mapping them as I’m lacking a multi button mouse.

We are also not able to back sync the mouse position from X to Wayland. As far as I understood the Wayland protocol there is nothing like XWarpPointer, so if something in X warps the pointer we have a mismatch. I agree that warping is evil, but we use it in KWin for activating the screen edges 🙁

Next Steps

Cursor

What is to do next is to get the changes to the cursor in X11 and set the cursor on the Wayland surface. That should not be really difficult as the XFixes extension provides everything one would need for that.

Thread

A rather huge limitation at the moment is that the connection to the Wayland display is hold in the main thread. We cannot block there, so we only get events when we actively check for them. This is currently during repainting the screen. So if you wondered why the ShowFPS effect in the video is turned on: it’s to force repaints and to keep the connection alive. This connection needs to go into a thread so that we can block there.

Buffer age

Currently the code forces as to do full-screen repaints. The two solutions we have for non-fullscreen repaints in the EGL backend do not work in the EGL on Wayland backend. The Wayland demo code shows that the EGL_EXT_buffer_age implementation could be used. We wanted to have support for that one anyway in KWin.

Giving it a try

Building from source

I just pushed the code into branch “kwin/wayland-egl-backend” on my clone kde:clones/kde-workspace/graesslin/kde-workspace. Be aware that I intend to force push to this branch.

To build you need to have the Wayland libraries around. The CMake module tries to find it through package kit. Watch the output of CMake, Wayland is only an optional dependency! If you build Wayland and Weston from source, please follow the instructions. You might also need to build Mesa from source.

How to start

Starting is rather simple. Just have an Xserver running somewhere, start Weston on a VT (don’t do nested on X, you would only get a black screen once KWin started) and open a terminal. Setup your environment variables to be able to start KWin and then start KWin in the following way:

DISPLAY=:0 KWIN_DIRECT_GL=1 KWIN_OPENGL_INTERFACE=egl_wayland kwin --replace &

KWIN_DIRECT_GL makes KWin skip the OpenGL Test application which is currently only supporting GLX and seems to fail if one is on a different VT. KWIN_OPENGL_INTERFACE tells KWin which backend to use. So by using “egl_wayland” one forces KWin to use the Wayland backend. In future we will probably detect whether the Wayland display environment variable is defined and just pick it directly (though that is dangerous in case of nested Weston on X).

When will it be available in a release

I want to get this work into 4.11 as an experimental feature for multiple reasons. I wanted to have a build dependency to Wayland in 4.11 for quite some time. So that’s a nice excuse. Unfortunately feature freeze is approaching.

Of course I want to give users something to play with. We have talked about Wayland for such a long time and there is nothing to really see that we are walking the way. Last but not least that might be a rather important solution for Plasma Active as that hopefully allows to run on hardware where we currently would not get OpenGL. With libhybris we should be able to get KWin working with OpenGL and being an X11 compositor even if the driver doesn’t support X11. Though I have not tested this case yet and have no devices to play with. But I know a few people in the community who might be interested to play with that.

Posted on

Mir in Kubuntu

As you might have seen in Jonathan’s blog post we discussed Mir in Kubuntu at the “Mataro Sessions II”. It’s a topic I would have preferred to not have to discuss at all. But the dynamics in the free software world force us to discuss it and obviously our downstream needs to know why we as an upstream do not consider Mir adoption as a valid option.

This highlights a huge problem Canonical created with Mir. I cannot just say “Canonical sucks”[1] to discard Mir as an option, I have to provide proper technical arguments why we won’t integrate Mir. I have to invest time to investigate the differences, advantages and disadvantages. As I have those arguments, I thought it might be a good idea to share them in a blog post.

The discussion started during a presentation about X11 and Wayland to my fellow team mates at Blue Systems. I decided to first explain X11 as I think one cannot understand the needs for Wayland without understanding X11. I did not intend to discuss Mir at all, but somehow the discussion drifted into the direction and the valid questions were raised about what are the differences and advantages of Mir or Wayland. What followed was kind of a rant about Ubuntu and Canonical [2]. So later the week we discussed “Mir in Kubuntu” in more detail to try to find answers to the many questions this raises for our downstream.

Introduction

Frustration and lost Motivation

Before I go into more detail I want to make one thing clear: Canonical is totally allowed to develop whatever they want. I’m totally fine with this and don’t care whether they develop another display server, an own os kernel or yet another desktop shell. I couldn’t care less. It’s Canonical/Mark’s money and he can invest it in any way he considers as useful. I wouldn’t even care if it would be proprietary software, that’s all fine.

What is not fine is causing a major disruption in the free software ecosystem by giving false technical arguments and doing bold statements about software Canonical does not contribute to. This is not acceptable. This was very frustrating and destroyed lots of trust I had in Canonical. It will be difficult to rebuild this trust. Canonical can be glad that it is the free software world and not the normal corporate world. There were quite some statements which could have raised the legal department in the normal corporate world[3]. It also cost lots of motivation at least on my side and I even questioned whether it’s still worth to be a member of the free software ecosystem. Instead of working together we now have a situation where members of the ecosystem become a competitor and which badmouth part of the software stack. A very frustrating situation.

There certainly are valid reasons for developing Mir which also make sense. Unfortunately they have not been presented so far. I’m quite sure that I know the reasons and if they would have been said straight away it would have been for me and other projects probably much easier. It would have taken away the frustration which the announcement caused and we would not need to discuss it at all, because those question marks would not exist. But apparently Canonical decided to give false technical arguments over the real ones.

Not ready yet

At the moment Mir is not there yet, this is important to remember. With the announcement we basically had four options on how to handle the situation.

  1. Continue with the Wayland plan and ignore Mir
  2. Switch to Mir and ignore Wayland
  3. Support Mir and Wayland
  4. Delay decision until Mir is ready

If I map our time line for Plasma Workspaces 2 against the time line of Mir I see no overlap. We want to support Wayland before Mir is ready. So delaying the decision would be a rather bad idea. It would just throw us back. This also means that option 2 is not valid especially as we would need to delay until Mir is ready for this to happen. So the only valid options are supporting both Mir and Wayland or only Wayland. At the moment the code is not ready yet to properly decide whether supporting Mir in addition to Wayland is a valid approach or not. Last time I checked the source base I hit a few stubs and then obviously stopped looking at the code as it’s not worth the effort yet. So we have to evaluate on the knowledge we already have and that doesn’t look good on the Mir side.

Wayland vs Mir

Possible Advantages of Mir over Wayland

The differences between Mir and Wayland are rather minimal. One of the differences is that Mir uses server allocated buffers while Wayland uses client side buffer allocation. I cannot judge whether this is an advantage or disadvantage. But I trust Kristian and the Wayland team more on that topic.

Another difference is that Mir uses test-driven development. To me development methodology is not a technical argument. I rather use a working system without unit tests than a system with unit tests that doesn’t work [4]. Also KWin does not use TDD. If I would consider TDD superior I would have to question my own development methodology.

But that’s it. That are the differences I found so far which could count as an advantage for Mir. But of course there is the advantage that Mir is going to be awesome. For the disadvantages I will spend a complete section on each point.

Distro specific

So far Mir is a one-distribution solution. So far no other distribution has shown any interest in packaging Mir even if it would become a working solution. Unfortunately I don’t have the ability to see into the future, but I can use the past and the present to get ideas for the future. The past tells me that there are other Canonical specific solutions which are not available in other distributions. I do not know of any distribution which packages Unity and from all I have heard it’s even impossible to package Unity on non-Ubuntu distributions. Given that it is quite likely that Mir will go the same road. It’s designed as a solution for Unity and if distros don’t package Unity there is no need to package Mir.

This has quite some influence on a possible adoption. I do not know of any kde-workspace developer using (K)Ubuntu. I do not see how anyone would work on it or how we should be able to review code or even maintain code. It would mean all the adoption would have to go into ifdef sections nobody compiles and nobody runs. This is the best way to ensure that it starts to bit-rot. Even more our CI system runs on openSUSE so not even the CI would be able to detect breakage. Of course a downstream like Kubuntu could develop the adoption and carry it as a patch on top of upstream, but I would highly recommend them to not do this as KWin’s source code churn is too high. Also we all agree that downstream patches are evil and we would no longer be able to help in any way downstream’s user from a support perspective.

Architecture

Mir’s architecture is centered around Unity. It is difficult to really understand the architecture of Mir as the specification is so full of buzz-words that I don’t understand it [5]. From all I can see and understand Unity Next is a combination of window manager and desktop shell implemented on top of Mir. How exactly this is going to look like I do not know. Anyway it does not fit our design of having desktop shell and window manager separated and we do not know whether Mir would support that. We also do not know whether Mir would allow any other desktop shell except Unity Next, given that this is the main target. Wayland on the other hand is designed to have more than one compositor implementations. Using KWin as a session compositor is an example in the spec.

License

Wayland is licensed like X under the MIT license, which served us well for a display server. I think this is a very good choice and I am glad that the Wayland developers decided for this license. Mir is licensed under GPLv3-only with CLA. I think this is very unsuited for such a part of the stack and would render quite a risk for usage in KDE Plasma. KWin (and most KDE software) is GPLv2-or-later, this would no longer be possible, it would turn our code into GPLv3-only as KWin (or any other software which would depend on mir-server) would be a derived work of Mir. I do not consider GPLv3-only software as a possible dependency of any core part of our application stack. It renders a serious threat for the future in case of a GPLv4 which is not compatible with GPLv3. I also dislike the CLA [6]. So from a licensing perspective Mir is hardly acceptable.

Unity Specific/No Protocol

One of the most important aspects from Wayland for us is the ability to extend the protocol. This has already been a quite important feature in X and we are using our own extensions over ICCCM and EWMH to implement additional functionality. Of course our workspace has own ideas and it is important for us to be able to “standardize” those and also make them available to others if they are interested. This is possible thanks to protocol extensions.
Mir doesn’t have a real protocol. The “inner core” is described as “protocol-agnostic”. This renders a problem to us if we would want to use it. Our architecture is different (as described above) and we need a protocol between the desktop shell and the compositor. If Mir doesn’t provide that we would need to use our own protocol. And that already exists, it is called “Wayland”. So even if we would support Mir, we would need the Wayland protocol?!? That doesn’t make any sense to me. If we need to run Wayland on top of Mir just to get the features we need, why should we run Mir at all?

But it gets worse, the protocol between Mir server and Mir clients is defined as not being stable. In fact it’s promised that it will break. That’s a huge problem, I would even call it a showstopper. For Canonical that’s fine – they control the complete stack and can just adjust all bits using the protocol like QMir.

For us this looks quite different. Given that the protocol may change any time and given that the whole thing is developed for the needs of Unity we have to expect that the server libraries are not binary compatible or that old version of the server libraries cannot talk with the latest client libraries. We would constantly have to develop against an unstable and breaking base. I know that this sounds overly pessimistic but I know of one case where a change got introduced in a Canonical protocol late in the release cycle completely breaking an application in Kubuntu which wanted to use the protocol. Given this experience I would not trust that the protocol doesn’t change one day before the release meaning that Kubuntu cannot ship.

This is not awesome, it’s awful. It means KWin will not work just fine on Mir.

I hope this shows that using Mir inside the KDE Plasma workspaces is not an option. There are no advantages which would turn Mir into a better solution than Wayland and at the same time there are several showstoppers which mean that we cannot integrate Mir – not even optionally in addition to Wayland. The unstable protocol and the licensing choice are clearly not acceptable.

What this means to Kubuntu

Question marks

For Kubuntu the Mir switch by Canonical created quite some questions. One of those questions is answered: Upstream has no interest in supporting it and would most likely not accept patches for support. With upstream not using Mir the question is how the graphics stack for Kubuntu will look like once Ubuntu switched to Mir? The questions cannot be answered right now but it doesn’t look good.

Patches to the stack

Ubuntu has always had one of the worst graphics stack in the free software world. I can see this in the bug tracker. The quality of the Mesa stack in Ubuntu is really bad. For Mir Ubuntu will have to patch the Mesa stack even further. This is nothing which I would like to see. Also Mesa needs to be packaged with Wayland support. But will Canonical continue to do this? If not, would Kubuntu (and other Ubuntu flavors) need to ship their own Mesa stack? What if the changes by Canonical are so large that a standard Mesa stack doesn’t run on top of the Ubuntu stack?

Switching Sessions

One of the advantages of free software is that one can select the desktop environment in the login manager. This looks like no longer be possible in a Mir world. Unity will run with a Mir system compositor with LightDM nested underneath. We will need either the X Server or a Wayland system compositor. So from the login manager it will not be possible to start directly into a session using a different system compositor. How will it continue to be possible to use both Unity and KDE Plasma on the same system? Running a Unity and a KDE Plasma (or GNOME or XFCE or anything) session at the same time seems to no longer be possible.

System Compositor

How deep into the system is the system compositor going to be? Will it be possible to disable the Mir system compositor and replace it with X or Wayland? What if the packages start to conflict? Will it still be possible to install Kubuntu and Ubuntu on the same system? Will Canonical care about it? Will the system compositor mean that one has to decide in Grub whether to boot Ubuntu or Kubuntu?

Packages from Where

So far X, Wayland and Mesa have been packaged by Canonical. But what about the future? Will there still be packages for X, will there be packages for Wayland? If not, where to take them from? Debian unstable, most likely. But Debian might be frozen. Will it be possible at all to use the Debian packages for X and Wayland in the Ubuntu stack? Will they meet the requirements for KDE Plasma[7]? If Canonical doesn’t provide Wayland packages, they would drop to universe, so Mesa in main cannot depend on them. How to get then Mesa with Wayland support?

Only Future can tell

Those questions cannot be answered right now. It will have to wait until Mir is integrated into the Ubuntu stack. Then Kubuntu developers will see how far the stack broke. I’m not really optimistic that it will still be possible to provide the Ubuntu flavors once the transition to Mir is done. I don’t think that Canonical has any interest in the community provided distributions on top of Ubuntu any more. There are many small changes in the direction which indicate that. But we will see, maybe I’m too pessimistic.

[1] Given how Canonical introduced Mir with incorrect information about Wayland I consider this as a valid approach to dismiss the technology.

[2] I was very fed up with Ubuntu at the time anyway because our bug tracker once again exploded after the Ubuntu release.

[3] I do admit that I thought about asking KDE e.V. to send an Abmahnung after the statement that KWin would just work fine on Mir.

[4] In fact I consider TDD as utter non-sense and as a useless methodology though some aspects are useful.

[5] “with our protocol- and platform-agnostic approach, we can make sure that we reach our goal of a consistent and beautiful user experience across platforms and device form factors”

[6] Yes I know that Qt also has a CLA, which I have signed. But for Qt there is also the KDE Free Qt Foundation agreement.

[7]Last week a feature hit KWin which I cannot test/use because the X-Server is too old in Debian testing.