Posted on

Continuous Integration for KWin

I decided that the life for my server is too boring as its only used to host this blog and functions as my mail gateway. As the system is rather powerful I decided to setup a Jenkins installation in order to continuously build KWin.

The first step is finished: the kde-workspace repository gets polled regularly and whenever there was a commit to master the sources are rebuild and in case it breaks I will be notified by mail. As KWin is not a standalone project, the complete kde-workspace repository is rebuilt. I want to further improve this process by doing several builds with varying configuration (e.g. the build for Plasma Active) and also for the kwin-wayland branch. But for those I first need to build a recent version of Mesa (no OpenGL ES on Debian Squeeze).
The really useful part of a CI system is that you can also perform some checks on the code. Unfortunately KWin does not yet have any unit tests (it is rather difficult to unit test an X11 Window Manager and OpenGL Compositor), but thanks to our modularisation effort I’m confident that we will soon be able to integrate the first unit tests.
But there are of course other possibilities except running unit tests. So I integrated a cppcheck execution on KWin’s repository as well as setting up Krazy tests, which are unfortunately broken for kde-workspace on quality.kde.org. Due to the lack of automated Krazy runs I have not managed to keep track of the issues lately.
I hope that these efforts help in the long to improve the quality of our software and to ensure that the code doesn’t break with unusual build options especially now when we transit to a major new windowing system.

=-=-=-=-=
Powered by Blogilo

Posted on

Shadow and no Oxygen

All users who do not use our default Oxygen widget style and window decoration might have had an unpleasant surprise after upgrading to 4.7. Our old shadow effect provided generic shadows for all windows no matter which widget style or decoration is used. In case the decoration provided its own shadow that one was preferred.

The new shadow system does not provide any generic shadow. The compositor is just providing a service to the widget style for rendering the shadow. This means that the widget style has to implement support for the new shadows. This has been done at least for Oxygen and Bespin, but it might also be added for other styles – so if you miss your shadows, check whether there is a new version of your preferred style, get in contact with  the author of the style or best of all: provide a patch.
Of course there is also the option to add a generic implementation again to KWin (which seems to be a need), though I must say that I will not spend any time on that myself. Given the experience from our old shadow effect, it is my belief that you cannot have a generic shadow which looks good with all widget styles, windows and color schemes. Nevertheless I am open to patches which add a generic shadow which can be used if decoration and widget style do not provide a shadow. The basic ideas of the new Shadow system are documented in our wiki. If you want to work on it and have questions just get in touch with us through either #kwin or #plasma on freenode or kwin at kde dot org.

=-=-=-=-=
Powered by Blogilo

Posted on

Running KWin with OpenGL ES 2.0

Today we expect the release of the KDE Plasma Workspaces in version 4.7 which is the first release including an OpenGL ES 2.0/EGL backend in KWin. This does not only allow us to run KWin on OpenGL ES powered devices (I am particular looking forward to see KWin on Tegra 2 devices), but also gives us a much better compositing experience on the desktop systems. Thanks to the work on OpenGL ES 2.0 our default compositing backend is now OpenGL 2.x based instead of OpenGL 1.x as it was till 4.6.

I want to thank all users who tested our beta version and release candidates and ensured by that a regression free update. I am very glad on how smooth this major transition of the compositor seems to work according to the very low number of bug reports in this cycle.
On Mesa enabled desktop systems there is also the possibility to go a step further and leave GLX completely behind by compiling KWin for OpenGL ES/EGL only. My personal experience is that it is often a much better experience to use the OpenGL ES build. If you compile KWin from sources ensure that the OpenGL ES 2.0 and EGL development libraries are around and enable the CMake option “KWIN_BUILD_WITH_OPENGLES”. If everything is setup correctly, CMake will tell you “Compiling KWin for mobile”.
Of course compiling from sources is not what most of our users do, so it needs distro help. Thanks to the awesome Kubuntu crew there will be a kwin_gles package available in Kubuntu 11.10. So users can switch to use this package.
But that’s still not perfect as users need to know that there is a better GLES variant. So today I pushed a change to master to build KWin twice: once with OpenGL and once with OpenGL ES. Thanks to our CMake Gods for all the help on getting this done :-). Now if OpenGL ES is available at buildtime a “kwin_gles” binary is compiled and can be used just like “kwin”. For all users of masters, do a git pull, recompile and run: kwin_gles –replace & and enjoy.
And that’s also just an intermediate step. Our GSoC student Arthur is currently working in close collaboration with me on decoupling our compositor from the window manager so that we can build just the compositor once with OpenGL and once with OpenGL ES. We will then put the compositor into a plugin and do a runtime check whether OpenGL ES is working and if it is we will load the OpenGL ES compositor. So if everything works fine, in 4.8 we will be able to offer and default to OpenGL ES 2.0 for most of our users.
This is also important for Phase 1 of Plasma on Wayland, which I will highlight in my talk at the Desktop Summit: Compositing after X – KWin on the road to Wayland. Hope to see you there.
Posted on

Why I would not sign a Harmony Agreement

Jos blog post today reminded me that I had a look at the Harmony Agreements and tried to decide for me whether I would consider to sign such a CA. To make it short: signing a Harmony Copyright Assignment is for me unacceptable. I think it could be valuable to others why I would not sign such an agreement. As a note: I have signed the KDE Fiduciary Licensing Agreement, so I am not in general opposed to licensing agreements.

Issue 1: The Name

The name “Harmony” is really bad. Not only as there is already a relevant FOSS project called Apache Harmony, it is also the meaning of the name. The name implies that you have to sign it to have harmony. Harmony between whom? Obviously the company who wants the CA being signed and the developer who should sign it. So without the CA there would not be harmony? Why shouldn’t there be harmony? If the developer chooses to develop to a company driven FOSS project under a given license (e.g. GPL) I do not see any reason why there should not be harmony between developer and other corporate partners. So given the aim of the Harmony Agreements to standardize CAs, I only see one possibility to destroy the harmony: requiring a CA from the developers. If the CA is an obvious problem then I do not understand how the Harmony Agreements are going to fix this. To me the name just sounds like an euphemism or worse like Newspeak.

Issue 2: Written by a Company

The Harmony Agreements have been written under the lead of Canonical, a corporate institution. Personally I doubt that a corporation has the individual developer’s best interest in their mind. Especially in the case of Canonical I am very doubtfull since the Banshee incident. If I cannot trust that the other party does not fleece me, I cannot sign such an agreement without consulting a legal expert in that field. This means quite a monetary factor on my side just to contribute something for free. If I have to pay to donate, I rather do not donate. I would feel way more open to the agreements if they would have been written by the FSFE, an organization I as a developer can trust and do trust.

Issue 3: Patents

Disclaimer: I’m neither a lawyer nor is English my native tongue, I might just be missreading it (see Issue 2). The agreement contains the following sentence:

(b) You own the Copyright and patent claims covering the Contribution which are required to grant the rights under Section 2.

To me this sounds like I have to state that I own all possible patent claims for the code I contribute. I would not have a problem with that for Germany (where patents on Software are not allowed), but worldwide? Considering the completely broken American software patent situation I would be sure that for any code I write there is at least one trivial patent claim for it. This is a point in the agreement I cannot sign without calling myself extremely stupid. As far as I remember my law term at university as a private, non-corporate developer no company could sue me for patent claims. By signing such an agreement patents become a serious issue for me as an individual developer. If donating code results in a threat to my monetary future I rather not donate source code.

Issue 4: Copyright in Germany

Germany has a “Copyright” very different to the rest of the world. There is no fitting translation for Copyright into the German langue and vice versa. In Germany (and some German influenced contries) you are the author (“Urheber”) and you will always be it. There is no possibility to assign your authorship to someone else. There is also nothing you have to do to become the “Urheber”, when you do creative work you are automatically the “Urheber”. Being a German, living in Germany and have been educated with this in my mind, I consider the authorship as something very important and I am very respectful for the author.
Obviously a Copyright Assignment is not possible if you are German. The Harmony Agreements handle this case:

(b) To the extent that any of the rights in Section 2.1(a) cannot be assigned by You to Us, You grant to Us a perpetual, worldwide, exclusive, royalty-free, transferable, irrevocable license under such non-assigned rights, with rights to sublicense through multiple tiers of sublicensees, to practice such non-assigned rights, including, but not limited to, the right to reproduce, modify, display, perform and distribute the Contribution; provided that this license is conditioned upon compliance with Section 2.3.

The agreement is just reduced to what the Contributor License Agreement is about. But it leaves me in legal doubt. What if I am at a conference outside Germany? Is the code I write there covered under the License Agreement or the Copyright Assignment? What if I move into another country where Copyright Assignment is possible? Given my German background it is for me unacceptable to assign the Copyright to anyone as nomatter where I live or work I consider myself as the “Urheber”. This is again a case of Issue 2. If it is just a license agreement in practice, why am I not allowed to just sign the license agreement? If the company is interested in controlling the copyright worldwide, wouldn’t it be a subsequent step to say that they don’t accept contributions from Germans due to the legal situation? How can a company know what parts of the code they have the copyright and for what they don’t?

Issue 5: Termination

There is plain simple no way to terminate the assignment. This is clearly in the interest of the company, but not neccessarily in mine. I am not sure if a could sign a treatment legaly binding for the rest of my life without the possibility to change my mind. Again compare issue 2.

Issue 6: Who benefits?

Why does a FLOSS centered company require CAs? I don’t have an answer for it and if I try to find one I can only come up with one solution. The company in question wants to improve the corporate value by having the option to make the software they develop in a community process proprietary. Or that the owner of the company considers to sell the company in future and wants to make it as profitible as possible. I hope there are better reasons for it and I am looking forward to the Panel discussion, but I fear my thoughts could be right. I personally would not give a company the right to turn my contributions to free software, and by that to mankind, into proprieatary software or even worse to sell it to $evil_company I would never want to work for, neither directly nor indirectly.
Overall there are just too many issues for me that I would consider signing it. As a note again, I do not in general consider copyright licensing as harmful and would also sign other agreements in case I am convinced that I can trust them. E.g. I would sign the FSF CA and would also contribute to Qt as the free software state is ensured by the KDE Free Qt Foundation.

=-=-=-=-=
Powered by Blogilo

Posted on

KWin Scripting’s Future Depends on You

In last years GSoC scripting capabilities have been added to KWin and have been shipped with 4.6. Unfortunately the student did not stick around so far which results in a situation that during the complete 4.7 releasy cycle there have only been two commits to the scripting component: one to fix some Krazy issues and one to change the coding style. With other words: the development of the component is dead.

For a new component this is very bad as it is unlikely that it is bug free and feature complete. There are probably many usecases where scripting integration might be useful and which is just not yet implemented. It also shows us that the core development team is not able to also maintain this new component. In fact due to lack of provided documentation the core team does not have the knowledge to further extend it.
This unfortunate development raises questions for the future. Currently we have a GSoC to modularize KWin core and it is likely that such a refactoring will break the scripting component at some day. Given that no core developer is knowledged about the scripting component, we are not able to see this in review requests (and we don’t have unit tests for it and cannot add them due to the lack of knowledge about the component). We are also not using the component so we won’t notice a breakage. My expectation for 4.8 is that scripting will be no longer functional and even if bug reports arise we would not be able to fix them.
The GSoC project is preparing KWin core to properly add support for multiple windowing system backends. I have already started to add support for a new windowing system and all the code so far does not integrate scripting. In the far future we want to be able to switch to this new windowing system which has also implications for scripting. Due to the current lack of scripting integration in the new written code it would mean that scripting no longer functions in future.
Overall this does not look good for the scripting component and I am currently considering various options. One of them is to remove scripting support again in 4.8. This is something I don’t want to do and I would feel very bad about it. Lots of work has gone into the code and it is a pity to remove it. Especially given that it was a successfully finished GSoC project and the slot might have been used in a better way for KDE if we remove the code after a year again.
I don’t want to do that! But I need your help to prevent that from happening. Step up and share scripts on kde-apps.org, provide a way to exchange scripts through GHNS, maybe add support for writing scripts to Plasmate and most important get in touch with the development: ensure that the code does not get broken in master, add support for further parts, help to document scripting in techbase, fix some glitches in the scripting related code.
I will keep the code at the moment and look how it evolves over the next months. In case the situation has not improved till soft-feature-freeze of 4.8 I see no other solution than to exclude the code from building 🙁

=-=-=-=-=
Powered by Blogilo

Posted on

Stripping Down KWin for Plasma Active

For the usage of KWin in Plasma Active many of KWin’s advanced features are just not needed. For example on Plasma Active we target OpenGL ES/EGL compositing, so the for desktop usage still useful XRender compositing is just unneccessary bloat added to the binary.

In 4.7 we started to add some build-options to remove unused parts from the build. We decided that on Plasma Active we do not need window decorations and added an option to exclude the decorations from the build and the basic functionality to start KWin without any decoration plugin present (which was not possible before).
Now with master open and a GSoC working on modularizing KWin, we were able to split out more stuff which can be disabled at compile time. There is a new build option to group all the settings for KWin on Plasma Active which currently includes:
  • No window decorations
  • No configuration modules
  • Reduced set of effects
  • No Alt+Tab (window switching)
  • No Screenedge interaction
  • No XRender Compositing
  • Default build to OpenGL ES if available at compile time
Some of the removed parts also affect the size of the KWin binary and/or the KWin internal libraries. I was interested in the differences of size when building KWin for desktop and for Plasma Active. So today I did a release build of current master with “normal” build flags and with the active build flag and compared the size of:
  • kwin.so
  • kwin_effects_builtins
  • libkdecorations
  • libkwineffects
  • oxygen decoration
For the desktop this sums up here on my system to 3239.5 KB and for active it’s only 1987.3 KB. And this is without considering the size of the installed package where the difference is much bigger as we do not install any decorations and configuration modules on Active. I’m really quite impressed seeing that the size of KWin is so much decreased. The biggest impact has the removal of some desktop effects: the size of kwin_effects_builtins goes from 927 KB to 269 KB. And there is more to go like disabling window tiling support, desktop change OSD and so on and so on…
I hope to get some “real” numbers on comparing the package size once both builds based on master are available as a package.

=-=-=-=-=
Powered by Blogilo

Posted on

Need an ATI R300

The ATI R300 is a very “special” and rather old GPU. It supports OpenGL 2 with one well-known limitation: there is no full non-power-of-two-texture support. KWin has code to handle this situation, nevertheless I broke our R300 support completely one week ago just before the branching of 4.7 without noticing it.

R300 used to be a very important Notebook GPU chip, so we cannot just stop to support it. I am sure that I will fix the regression with the help of users willing to test my patches, but for the long run it’s no solution. Even if we fix this regression I am (after reading our code again) very sure that some new features are not working at all with R300.
Given the situation that we do not notice such regressions during development, it is likely that changes will break support in future again (at least I am not able to develop correctly without testing ;-). This makes it very difficult as we cannot easily bisect. I see only one real solution: I need to have such a GPU to be able to test recent changes for regressions and implement the (rather trivial) adjustments for R300.
If anyone has such an old card and would be willing to donate it for KWin development, please get in contact with me.
Thanks.

=-=-=-=-=
Powered by Blogilo

Posted on

And There was Text

Short update from the Wayland efforts:

This is quite a success as it took me several days to work out how to activate the window and get keyboard events to it. Now with that done I can start looking at the real window managment bits.

=-=-=-=-=
Powered by Blogilo

Posted on

Neues Spielzeug

Es sollte ja kein Geheimnis mehr sein, dass der X Server mitlerweile angezählt ist und mit Wayland der potentielle Nachfolger bereits in den Startlöchern steht. Auch wenn es noch lange dauern wird bis wir X endlich in den Ruhestand schicken können, ist für mich bereits der Zeitpunkt gekommen, mich etwas intensiver mit der neuen Technologie zu beschäftigen. Für KWin ist es wichtig früh Wayland Anwendungen zu integrieren, da man unter KDE Plasma Wayland nicht benutzen kann, wenn KWin Wayland nicht unterstützt.

Letzte Woche habe ich angefangen KWin um ein Wayland Backend zu erweitern. Glücklicherweise ist das Wayland Server Protokol extrem einfach gehalten wodurch man sehr schnell erste Ergebnisse erreichen kann:
Dieser Screenshot ist sehr interessant. Das Terminal Fenster ist ein Wayland Client, die Fensterdekoration ist jedoch ein klassisches X11 Fenster. Wir kombinieren hier also beide Technologien. Dies zeigt sehr schön die Strategie, die wir bei KDE Plasma einschlagen: schrittweise Unterstützung für Wayland Fenster implementieren ohne unseren bestehenden Desktop zu zerstören. Erst wenn wir volle Unterstützung implementiert haben, werden wir X11 verlassen und auf Wayland wechseln. Bis dorthin werden wir eine Strategie fahren bei der Wayland Clients unter X11 verwaltet und gerendert werden.
Auch wenn der Screenshot schon nach sehr viel aussieht, darf man sich nicht täuschen lassen. Bis wir auf Wayland sind, ist noch ein weiter Weg. Viel muss erst noch implementiert werden. Für mich ist das gerade extrem spannend und ich fühle mich wie ein kleines Kind mit einem neuen Spielzeug. Schritt für Schritt kann ich nun die Fenster benutzbar machen. Dabei lerne ich auch richtig viel noch über KWin Interna. Mit dem X11 Fenstermanagement musste ich mich eigentlich nie beschäftigen, da es vollständig und korrekt implementiert ist. Nun bin ich dabei Fenstermanagement für Wayland nachzuimplementieren.
Richtig toll ist wie viel einfach so ohne jegliche Anpassung funktioniert. Vor allem unser Effekt Framework interessiert sich überhaupt nicht dafür ob ein Fenster nun X11 oder Wayland ist. Es wird einfach integriert und angezeigt. Auch wie man im Screenshot sehen kann, ist es den Fensterdekorationen egal ob sie ein X oder Wayland Fenster dekorieren.
Experimentierfreudige Nutzer können das ganze auch schon testen (auch wenn es extrem langweilig ist) wenn sie selbst aus den Quellen bauen. Bis das ganze in Distributionen verfügbar wird, wird noch einiges an Zeit vergehen. Da wir ja in Feature Freeze für 4.7 gerade sind, werden all Änderungen erst in 4.8 erscheinen und auch dann ist es fraglich ob Distributionen mit den entsprechenden Build Flags bauen werden (wer hat denn schon Wayland in den Repos?). Bei OpenSUSE wird es wahrscheinlich in den Factory Builds verfügbar sein, sobald die Änderungen in den master branch einfließen. Bei Kubuntus Project Neon ist das auch denkbar, jedoch könnte die Wayland und Mesa 7.11 Abhängigkeit das ganze erschweren.

=-=-=-=-=
Powered by Blogilo

Posted on

Discovering a New World

This weekend a group of KDE hackers met in a small mountain village, Randa, in Switzerland to discuss the future of the KDE Frameworks. I was not present, but started on Saturday an endevour for the future of the KDE Plasma Workspaces. Yesterday evening I arrived in the new world:

desktopgrid-with-wayland
This is not just the Desktop Grid effect. The gears window you can see on each of the desktops is a Wayland client, all other windows are X clients. For me this is a rather historic event, not just for KDE but also and especially for Wayland. Up to now there have only been the demo compositor and the QtCompositor as Wayland Compositors. They are more or less just proof of concept. But this is different event: we have here a normal X11 window manager and are able to integrate Wayland clients into the compositing scene just as if it were an X client. This is not a Wayland compositor, it is a X compositor with an implemented Wayland Server component.
This is the proof that there is a sensible migration path from X11 to Wayland. We can use our normal and known X system and manage Wayland clients in it. There is no need to implement the complete stack on top of Wayland first with possible regression. As we can see the Effect Framework does not need any adjustment to support Wayland Clients, which means we can give the user their known KDE Workspace experience. For the user it is irrelevant if a window is an X or Wayland client, it is just a window. For KDE this means that we don’t need and won’t break the desktop. We will switch to Wayland when we are ready, but at the same time we can offer Wayland to interested developers and users who want to experiment with it. For Plasma Active on the other hand we will switch to an X less Wayland-powered KWin as soon as possible.
Of course there is still a long way to go to get to Wayland. This is just rendering, we still need to implement the complete Window Management, transition the compositing away from X, break out X from KWin and lots more. It’s the result of four days where I spent a few hours each day on hacking on that topic. Which shows how simple the Wayland protocol is, although the documentation could be better 😉
Now the next steps will be to clean up the code, document it and push it into a git branch. I hope to see many developers to pick up on it and to start implementing the window manager functionality and extending e.g. Plasma Desktop to support Wayland Clients in the Tasks Applet and many more such things.
I will present the complete KWin Wayland strategy at Berlin Desktop Summit in August.

=-=-=-=-=
Powered by Blogilo