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.

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

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

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