Posted on

Next step: running

Last week I reported that KWin compiles and links against Qt 5 and KF 5. This week I’m glad to report that I got KWin also to run. The biggest issue was a PEBKAC – if you try to run anything build against frameworks make sure to not have KDE 4 libraries in your LD_LIBRARY_PATH.

Aus KWin

Before you are tempted to run KWin next in the new Project Neon setup a word of warning: it will dead lock. The current code base I use for testing depends on not yet upstreamed changes in frameworks and Qt. Obviously I have not yet pushed the KWin code needing these library adjustments but without them KWin will hit a dead lock – more to that explained later on.

Project Neon has been a huge help over the last days. Harald reported again and again build issues which we were not able to detect on our system because we also have Qt 4 installed. One example was a file being included which does not exist anymore in KF 5. As it was installed in /usr/include I was not able to detect such a problem, but with a clean setup like Project Neon it becomes immediately obvious.

So what is already working in KWin on 5? The most obviously visible one is the compositor. This doesn’t surprise me much, I didn’t expect any problems there. So far I have mostly tested the XRender compositor as I’m currently mostly working with Xephyr which only provides llvmpipe OpenGL and I rather spent my CPU cycles on compiling than drawing triangles. Since yesterday I have also Oxygen shadows working again which I had initially disabled as it needed XCB porting. But it just looked too strange without them, so I had to enable it 😉 I think Hugo ported Shadows in Oxygen for the same reason.

Related to the compositor is the effect system and our effects. This was rather surprising for me: they just worked out of the box. The only major problem is that global shortcuts are not yet supported so I have problems triggering them. For some effects I solved this problem by just adding a DBus interface – might be an idea to keep this; some users might appreciate it. Only the scripted effects were not loaded because I did one mistake during the initial porting – this is fixed since today as you can see by the dialog parent effect being applied in the screen shot above.

Also window decorations work, though there is still quite some work to be done. For example the QML based Aurorae does not like to work which is the reason why I ported Oxygen over. It’s overall nice to see that it works, but it seems to be only working with compositing enabled. Not so surprising as this hits areas which changed a lot inside Qt.

The window manager seems also to be working, though obviously I have not tested all features and are using only a minimal sub set of the available functionality. Due to missing global shortcuts support it’s difficult to test all features and due to missing port of the configuration interfaces I cannot even adjust the configuration (well I could just edit the config file, but…).

Nevertheless there are still quite some issues which need investigation and fixing before I can start to consider using KWin 5 in production. The biggest problem at the moment is that all windows present at startup get unmapped and are kind of lost to the window manager. So far I have not yet been able to figure out why this is happening. That is for example a show stopper if you would want to use it in a neon setup. (Update: This issue is fixed as of 3bddd1100aa)

The biggest change for KWin is the port of the event filter from XLib to XCB and this is still causing some headaches to me. With XLib one was able to look into the future by inspecting the XEvent queue or to the extreme wait till a specific event has arrived. With XCB the event queue doesn’t allow to be inspected which makes porting properly a non-trivial task. KWin was using this functionality at three places (at least that’s what I found so far). During move/resize operations we only process the last mouse motion event currently in the event queue to limit the resizes. This functionality should be possible to emulate with a more async event handling approach. The second usage is that we do not deactivate a window on focus out event if there is also a focus in event following. The documentation says this is to prevent flickering. In a composited world it doesn’t really matter as the compositor should prevent the flicker, but also here a more async approach should be able to handle it.

The big problem though is the third usage: updating the current xTime. KWin needs to have the most recent X time to be able to properly compare timestamps. This is done by changing a property and waiting for the event which contains the timestamp. In addition KWin does some more tricks like looking at the first event in the queue containing a timestamp, to get it really correct. Now with XCB event queue not being available to us this is a sever issue as without this functionality KWin doesn’t function properly. While looking at how to solve the problem I discovered that the XCB QPA internally uses a method providing this functionality of getting a current timestamp. Not with all the bells and whistles as we used to have in KWin, but good enough for a start. So my solution at the moment is to have my local Qt copy to make this function available and by that solve the problem. That’s the change I talked about in the beginning of this blog post.

As you can see there has been quite some progress and I hope to get KWin in a dogfoodable state quite soon. And that’s something where you can help. There are many easy tasks available which just need you to be able to compile KWin and with Project Neon this just became easier. So drop by the Trello board and claim your task. This week I was already able to push one first time KDE commit with a small cleanup for our code base 🙂 So who wants to be next?

Posted on

Help porting KWin to Frameworks 5

With Akademy behind me and the situation about “what is master” in kde-workspace resolved I decided to switch my work away from Wayland towards getting KWin on top of Qt 5 and KDE Frameworks 5. After a few days of hacking the compilation of KWin is re-enabled in the frameworks-scratch branch of the kde-workspace git repository.

This means that KWin compiles, links and installs when compiling against KF5. A quite important step and only very few code areas got ifdefed. The preparation work of the last months showed it values as for example the compile errors due to QPixmap were extremely easy to resolve (just delete the code) without loss in functionality.

But of course at the moment KWin does not work yet when compiled against KF5 as the event filter is not yet ported to xcb. This is what I will focus on next so that we can soon start testing a KWin on 5 and start to adjust the areas which need to be tested against a running KWin, where “ship it, it compiles” is not enough.

Of course getting KWin to KF5 is still a long road and we need help for this. There are many, many tasks which are rather easy and do not need a working KWin. It’s just a matter of changing for example KPushButton into QPushButton and verify that it still compiles. This means that right now is a perfect time to get started with KWin hacking.

And obviously I started to prepare for that and created a wiki page for KWin on Frameworks. I plan to update this page whenever new information becomes available like how to run KWin on 5. Most important I created a Trello board listing the tasks which can be done to help the porting. I will add tasks as I notice them. So if you want to get involved, just ping me, tell me your trello username and I’ll add you to the board and start hacking. If you look at the list you will notice that some tasks are really simple. Let’s rock to get KWin working on Qt 5 as fast as possible to get an awesome next release.

Posted on

The road towards KWin on Qt 5

The last three weeks I have been on vacations which explains the lack of blog posts. My batteries are fully recharged to work on KWin full time starting from January thanks to Blue Systems.

By pure chance I stayed close to the San Francisco Bay Area which allowed me to go to the Qt Developer Days in Santa Clara. It was great to see all the KDE and Qt people again and it was totally worth going there. I’m now looking forward to some great Qt technology coming up with Qt 5 (congrats to the release!) and I’m very very glad that ICS and KDAB organized the Dev Days and showed everyone that Qt has a bright future.

For me the conference was very valuable as I had the chance to discuss a few things about the next versions of our KDE workspaces with Aaron and David. And even if we do not yet have plans for a KDE workspaces release based on Qt 5 and KF 5 it became clear to me that my work for the 4.11 cycle will be mostly focused around the porting to Qt 5. This might sound surprising given that Qt promises 99 % source code compatibility. Well Lars Knoll mentioned that only platform dependent code needs to be adjusted and yeah: KWin is the 1 %. I will start to document lots of the tasks which need to be done in our wiki and will blog about it so that you can help with this task. A good example is that QPixmap is no longer bound to an X11 pixmap and well we used to do texture from pixmap from it (only with X11 PaintEngine in Qt).

Personally I do not mind much that we have to spend time porting to Qt 5. It gives us the opportunity to improve a few areas where we kept methods around for backwards compatibility in e.g. the D-Bus interfaces. Such methods are already marked as deprecated and some of them had been marked as “Should be removed with KDE 4”. It seems to me like the needed cleanup had been forgotten when we last had the chance. And that’s why I want to get done with the porting early. I would prefer having KWin run on top of Qt 5 as of 4.11 (of course that release will still be Qt 4 based) so that we can spend the 4.12 cycle to do lots of the cleanup.

One of the major areas for porting is the switch from XLib to XCB. As far as I have seen we would not be required to port everything to XCB, but overall it is a good idea to do so. It will make KWin faster and of course it’s better to have everything using XCB and using XLib only where – for legacy reasons – it is required: the GLX compositing backend (looks like our current EGL backend is also bound to XLib). Also the porting allows us to do some things “right”. Some KWin effects for example are interacting with X11 directly and that is something which should be tried to be abstracted properly so that we do not need to adjust the effects once we are running on Wayland.

Now that I mentioned the W word: you might wonder what happened to the plan to start working on Wayland from January. Well that has not changed much, it’s just that I learned more about the Qt Compositor which is a wonderful Qt-like abstraction on top of the Wayland C libraries. Nothing against the Wayland library, but it’s C. And I prefer working with a C++ Qt like API with CamelCase instead of underscores as so often common in C APIs due to lack of namespaces.

Internally we would have used a C++ abstraction anyways, because it’s just easier to work with it. With Qt Compositor we do not only get that for free but we also get a better API as the people at Qt have more experience in defining APIs than we do. And as another plus if we need something further we can just add it to Qt Compositor and share it with everyone. So all the code is set to greater usage.

The only “disadvantage” of Qt Compositor is that it absolutely requires Qt 5. So to be able to integrate it into KWin we need to first port to Qt 5. It is hardly any difference: we would have needed to go to Qt 5 anyway, when does not really matter, just that I now have a wonderful motivation to get there.