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

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

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.

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.