Posted on

New Screen Locker

Some might have already read about it: we are currently working on a new screen locker. The old implementation is mostly a hack around X. There is the lock window which tries really hard to be the top most window. Obviously this does not often work, especially as the whole framework is way older than Compositing.

Too often I have come back to my system or resumed from suspend and seeing my windows shine through. Or seeing some notifications on top of the screen locker. We decided to change that and solve it once and for all in a proper way by putting security first and moving the screen locker into the Compositor.

The Compositor controls the rendering, so it can ensure that nothing gets above the screen locker. When we have the compositor being responsible for the screen locking we also get nice fading from and back to the desktop for free.

My initial idea was to just move the screen locker to KWin but not changing the unlock dialog. But now I started to play around with QML and need your help:

QML unlock dialog

You can see that I am really no expert in doing user interfaces. So if you have some QML experience or just want to help defining a very important area of Plasma, please get in contact with us. I will do all the JavaScript and coding, so that only the QML is needed.

The new way unfortunately conflicts with the existing screen savers. They are almost 20 years old and we have problems to keep support for them. At the moment we decided that if you have a screen saver configured the old implementation will be used with all the security issues. But we are not yet sure what to do in 4.9. As we use QML it would be possible to write new screensavers in QML. This would allow us to keep the improved security and to only need one code path. But we are unsure how our users will react on removing the X Screen Savers. To find that out we set up a poll on forum.kde.org and I would like to ask you to participate. This will help us to define our next steps.

The new screen locker will also be used by the first version of Plasma Active, which will be released in a few days. There we use the same architecture but ship a different QML file which does the unlocking without needing a password (we only want to protect for unwanted touch events). This shows that it is possible to exchange the QML files for custom screen savers.

Moving the screen locker into KWin has also more security advantages in addition to the protected screen content. Of course KWin is very crash resistant. So if the screen locker crashes KWin will just restart and lock the screen again. Even if KWin would completely fail it is more secure than before as without a window manager you can hardly do anything with the system. Also we have finally a real solution for the most often reported KWin crash of all time: the Intel driver crashes KWin when the screen saver is used due to unredirecting the fullscreen saver window. With the locker being a KWin effect it is impossible to trigger this driver crash.

Some users might wonder what that means if they don’t use KWin. Well as the screen locker has been moved to KWin you can no longer lock the screen if not using KWin (the same way you could not lock the screen if not using KRunner before). If you want to lock your screen in Plasma 4.8 but don’t want to use KWin you should get in contact with your Window Manager vendor. Sam from Compiz wanted to add support for it in Compiz. For anything else I don’t know. So why did we do it: we think that the security of most of our users is more important than the need of some users to use a different window manager. Also we had added many integration features to Plasma in the past and if you were not using KWin you lost these features. With the screen locker it is now exactly the same: you lose the integration feature when not using KWin. I also want to remember everybody who wants to complain in the comment section that the KDE Plasma Workspaces are an integrated product consisting of the Plasma Desktop Shell, KWin, KDM, Systemsettings and a few other applications. We develop this as one product, so if you want to remove a part, well that’s your decision, but we have to compromise and we clearly see that other vendors are integrating their window manager even further into the desktop shell than we do.

Posted on

Correcting misconceptions about Power Saving and Desktop Effects

Apparently the English I write is too difficult to understand for the average reader – including so-called free software journalists – (which surprises me as I am a non-native speaker), so I have to be more clear about what I wrote yesterday before more FUD is being spread.

What is going to be removed?

One checkbox in the power management settings to automatically disable compositing when battery runs low.

Does that mean I have to use Compositing?

No! You still can disable Compositings in Systemsettings, use the Alt+Shift+F12 shortcut or use a window specific rule to block compositing if e.g. you are using VLC or Wine. You can even write a very short script using our D-Bus interface to disable compositing when the battery runs low. You see even the exact same functionality is still there, it’s just a removed checkbox.

What about enforcing compositing you wrote about?

That is only the case if the screen is locked with the new implementation. As soon as you unlock you can disable compositing again and of course if compositing is disabled it stays disabled when the screen gets locked.

I hope that clarifies everything. Just remember: we always do what is in the interest of our users. If you want to go OMG THEY ARE EVIL it is more likely that you misunderstood something than that we are evil 😉

I would appreciate to see updates to the blog posts which spread the FUD that we enforce compositing. This is really bad!

Posted on

Power Saving and Desktop Effects

For a long time KDE Plasma offered to turn off Desktop Effects when battery runs low. In the past we changed the default to keep compositing on and now in 4.8 we remove the option completely.

We all care about power saving and so it is important to understand why keeping compositing on will most likely save more power than turning it off. (As with all hardware and driver dependent functionality we can only offer what is best for the majority of users, it is possible that with specific hardware turning compositing off would in fact save more power.)

So let’s have a look at what happens when you turn off compositing:

Turning Compositing Off

Window decorations

Our default window decorations uses a shadow build into the decoration itself. When you turn off compositing the shadow has to be removed. Given the way the shadow is implemented, this means that each window has to be resized and moved back to its position. Furthermore all window decorations have to be completely repainted.

Plasma

Everything that is painted in the desktop shell is a pixmap rendered from SVG. Plasma uses a cache for the recently generated pixmaps. The themes itself come in three forms: one for no-compositing, one for compositing and one for compositing with blur. When turning off compositing the theme has to switch from one of the two composited to the non composited. This means we need to access the hard disk to load the SVG. Then we have to render the SVG in the correct size to a pixmap and access the hard disk again to save the pixmap in the cache. This has to be done for each Plasma styled window: the panel, KRunner, the tooltips, Alt+Tab, Kickoff. Also in later states during using it is likely that the same cycle happens again: e.g. the size changes of KRunner. With compositing it’s most likely in the cache, with non-compositing it isn’t.

KWin itself

When turning off compositing KWin has to be quite busy. All the effects need to be turned down, lot’s of resources have to be released. The OpenGL context needs to be destroyed. The overlay window has to be removed, quite some properties need to be removed from the root window (support for blur, taskbar thumbnails, etc.), the manager selection has to be released. So overall quite some roundtrips to the X Server till everything is teared down correctly.

X Server

With compositing disabled the X Server becomes responsible for rendering the screen again. It no longer has to redirect the windows into offscreen pixmaps and notice KWin through the damage extension about changes. It has to update the screen and perform the clipping of the content. Pretty much the same what KWin did before.

How the Desktop Effects work

As we see overall turning compositing off is a rather heavy operation. It involves many applications, many context switches and lot’s of I/O. All the things you don’t want to do when running low on battery. But later on having compositing turned off must really bring power saving, right? To answer that we have to look on how KWin performs the rendering.

How KWin renders

KWin is notified by the X Server about an update in a window (damage) and triggers the next repaint. The repaint starts with asking all loaded effects whether they are active. In a normal situation only the blur effect will be active, all other effects won’t participate in the rendering. Each participating effect is asked to perform its transformations and additional rendering. In the normal case the blur effect notices that the window does not have to be blurred and does exactly nothing.

The windows are rendered from top to bottom. That is if we have an opaque window on top, the one below won’t be rendered. Only if it is translucent it will be rendered from bottom to top (that is all windows). So in the normal case (area of a window updated) only one window will be updated. The rendering itself is just a very simple 2D texture rendering. Yes it’s 2D, not 3D.

After the window is rendered KWin goes back to sleep to wait for the next damage event, it does not perform constant rendering.

But it’s using OpenGL, that’s expensive on the GPU!

Well think about it. Someone has to bring your updated windows on the screen. This someone is the graphics card. You need it anyway, no matter whether it is KWin or the X Server. KWin uses OpenGL to do the rendering, which means it’s hardware accelerated. I do hope that the X Server uses hardware acceleration to do it’s rendering 😉 In the most modern architectures (like Gallium3D) 2D is just a special case of 3D. I honestly don’t see how using X instead of KWin to perform the 2D rendering should save any power.

But can’t you at least deactivate the effects?

As explained above only active effects will participate in the rendering. So if you don’t use the cube effect, it won’t be used and cannot consume power. If on the other hand you use the effect than it is adding usability features. Imagine a user who switches windows using the Present Windows effect. Of course using this effect actively will affect the battery life. But what is worse? Using the effect once very shortly or searching a minute for the window in the taskbar? What will affect the battery life more? The minute searching (one minute less battery) or the animation?

But at least Blur should be disabled!

It is true that Blur is the most expensive effect we have depending on the hardware you have. That’s why we are optimizing the effect (thanks to Philipp for all the work on it). First of all: if the rendering of the window does not intercept any blurred area, the blur effect won’t do anything. If the rendering intercepts a blurred area the part has to be updated. Thanks to some optimization we only have to update this part and we cache the blurred background. So blurring is no longer that expensive as it was. Now we could nevertheless turn blur off, but that would require to generate new pixmaps (see above) and I doubt that this is better than doing some blur operations.

What about the animations?

Animations are probably the only thing where it might make sense to deactivate when running low on battery. Animations trigger repaints so they are not cheap. But to change that quite some work is required and I am not sure if it is worth it. So if you can do an evaluation on how expensive the fade effect is for the battery life we might consider to add a way to disable the animations.

Where Compositing helps to actively save power

There are operations where compositing is much better than good old X. For example when moving a window only some texture rendering need to be performed. With X the areas where the moved window used to be needs to be repainted. The same is of course true for resizing. Another advantage is that KWin renders with a well defined frame rate. No matter how often a window tries to render, KWin will throttle it. So a window generating damage events each millisecond will be rendered only each 17 msec. And yes there are applications out there trying to render as often as you can. Preferable some old icons in the systray or non-standard toolkits.

Where we enforce Compositing

KWin in 4.8 is the first version which will temporarily enforce compositing. This is currently related to the new screen locker. The new screen locker is implemented in the compositor to ensure that the screen is always blanked (something the old one could not guarantee). When we use the new locker KWin ensures that compositing cannot be turned off! So imagine we would allow turning compositing off when running low on battery.

First scenario: active usage. Compositing is turned off and later on the system goes to suspend and locks the screen with the old insecure implementation. I hope you all see that security is important.

Second scenario: screen locked when battery is running low. The power management functionality will try to turn off compositing, but it will fail and the power management will never notice about it. There is in fact no way how the power management could notice that and it would have to try again and again to turn off compositing. That sounds clearly wrong to me.

But 4.8 will hopefully have another situation where we need compositing: Wayland. When we run a Wayland server we will not allow to turn off compositing, because you would lose your Wayland windows. Currently the code is not yet merged and most likely the distros won’t have packages available anyway but it is something we have to plan for. With Wayland we need compositing, so turning it off doesn’t make sense.

Overall I hope you see that turning compositing off will be worse for the battery than keeping it on. We are concerned about helping the environment and giving our users the best of the limited resources. That’s why we removed the feature: to help you and not use wrong settings just because you assume that 3D is worse than 2D.

Posted on

Fighting the Schism of Free Software

Over a decade ago an event happened which is still influencing our life in free software. Instead of one, two projects emerged to bring a fully free desktop to Linux based systems. Back then we failed to see the advantages of having multiple available desktop environments and we basically created a schism between the KDE and the GNOME world.

The Schism is still in place!

Without noticing it the emerge of multiple desktop environments (and with that I mean not only GNOME and KDE) created something positive: nowadays we have several superb environments the user can choose from. We have what nobody else can provide: choice of the desktop shell and software for the personal needs. The free software world does not provide a one size fits it all solution, but the user can choose between multiple products. This is a great advantage.

In the end it does not matter whether a user is using GNOME Shell, Unity, KDE Plasma, XFCE or any other environment. As well it does not matter whether he uses KMail, Evolution or Thunderbird. What matters is that the user has been liberated from the lock-in systems of our competitors. Our goals are all the same: we want free software to succeed.

If a user switches from GNOME Shell to KDE Plasma, it is not a lost user to GNOME. It is a user won for free software and not lost to the proprietary competition. If a user switches from KDE Plasma to Unity, it’s not a lost user to KDE, but a user won for free software. We have to realize that we are not in competition with each other, we are in competition with the proprietary lock-in systems. United we have something to compete with our real competitors.

I think most developers have already realized that we are not in competition but have to work together. We can see this through events like Desktop Summit. But if I look around, I see that there is still a war between GNOME and KDE – at least among the users. KDE users are happy that GNOME Shell is not yet ready and similar idiocy. This is something we have to fight. If for example somewhere a user is complaining about KDE Plasma it is totally fine to suggest them to give GNOME Shell a try. We have the choice, we have different environments to support different workflows. We do not provide software which is suited to all users. I am sure we have the software component to make each user happy, we all have to help the users to find the right software for their needs.

When Linus turned first from KDE Plasma to GNOME and later from GNOME Shell to XFCE he was exactly demonstrating the advantages of choice. Neither KDE Plasma nor GNOME Shell can suit the needs of a power Kernel superlord but free software in general does offer the possibility to have a desktop shell available for everyone. These two events have not shown a failure of GNOME or KDE as the media seemed to suggest, but the opposite: it highlighted the great advantage of choice in the free software ecosystem.

My hope is that our users would stop to fight each other. While our users fight, they demotivate the developers, they undermine efforts to improve the collaboration. There is no need to fight for KDE. If a KDE user writes bad about GNOME, he is not harming GNOME, he is harming both KDE and GNOME. KDE and GNOME belong together, we are in no competition, we need each other. Only together we have a chance of bringing the merits of free software to all possible users. I also hope that the media would stop to compare the systems: they don’t need to be compared. GNOME Shell has a different workflow than KDE Plasma. What would be the need for GNOME Shell to simulate the behavior of KDE Plasma or vice versa? Comparing the systems is wrong from the start.

I hope that also the two organizations around KDE and GNOME can help to make a united vision come true. Why is there no mention of GNOME on the KDE web site? Why is there no mention of KDE on the GNOME web site? Why are release notes of GNOME not published on the KDE news site, isn’t it a news worthy event if our collaborators have a release? Why is it so strange that a picture of a GNOME developer is in a release note of KDE that it has to be mentioned in a keynote at Desktop Summit? Such collaborations should be normal and nothing which needs to be mentioned.

And we can also do something to make the acceptance for our users better. New users will end up with either GNOME Shell, Unity or KDE Plasma. There is a good chance that they don’t like the system they got by chance. In that case they are lost again to the proprietary competitor. Why don’t we offer a “discover more” mode in our systems? Make it easy to install and try GNOME Shell from inside Plasma and vice versa. We have so many awesome software and nevertheless we are still in our GTK-only and Qt-only world. Why do we not include GTK applications in the default offerings in KDE Plasma? If there is a better alternative, do we really need to ship a maybe unmaintained and half broken Qt application, just because it’s Qt?

We all – users, developers and media – can do much better than we already do to finally end the schism of free software. It’s not KDE vs. GNOME, it is KDE and GNOME. We are one free ecosystem. If we want we could say KDE Plasma is just another desktop shell for GNOME OS, just like GNOME Shell and Unity are shells for GNOME OS. We have to finally be united to bring the merits of free software to all users. Let’s all pull together to make free software more awesome. Let’s stop the so often childish and ridiculous comparisons between GNOME and KDE software. They are alternative options and not competing products.

Posted on

Developer and User Interaction

A free software project such as the many projects under the KDE umbrella do not need users, they only need more developers. A user which is not able to develop is useless. Because of that it is totally acceptable that you demand that user’s should start learning programming to fix the bugs they report.

Of course such an opinion is as ridiculous as users demanding that bugs get fixed or insulting the developers who spend hours and hours of their spare time to produce an awesome product.

What I want to indicate is that the relationship between users and developers in a free software project is very special. And we need both: we need the developers and we need the users. What’s the fun of developing if nobody is going to use your software? How do you get new software if there are no developers?

A recent incident on a mailinglist and similar incidents before motivated me to finally write this blog post which I had in mind for quite some time. I hope this can help users in the interaction with developers. Now I have to add that I am not an expert in that area and most of the things I put down here are based on my personal opinion and experience.

The Value of Free Software

Free Software is something incredible: hundreds of developers write software in their spare time and not only do they give it away for free, no they also give you the right to do whatever you want with the source code. Furthermore you are allowed to give feedback directly to the developers: through bug reports, through mailing lists, through blog posts and many more possibilities. Each user can interact directly with the developers. There is no expensive support hotline in between. Keep that in mind whenever you have the urge to communicate with developers. It is one of our greatest values and it would be a pity to lose it.

Developers are not evil

No developer is going to destroy his software. No developer is going to introduce bugs on purpose. No developer is ignoring bug fixing. Whatever you think, developers are not evil. They are more interested in a successful product than you as a user. It’s what they invest time for, it’s what they like doing. If a developer is not fixing a bug or not even reacting to it, it’s not because he does not care, it is more likely that he did not see it, that he does not encounter it, that he just does not have time or something else. It’s never about ignoring the user. Also developers do not remove features to harm their users. They have to think about more than just a collection of features. Sometimes it is required to remove a rotten log in order to get something better. It might be worse for you, but in general it’s better for all. Developers don’t change for the sake of change – we are lazy.

You are not a Developer

Remember that you are not a developer. You should not try to discuss about technical details with developers: you cannot win. No matter how good your opinion is, no matter how smart you are, the developer is most likely an expert in his area and has a better view on issues. If he tells you something is not possible, it most likely is. If he tells you he cannot fix a bug, that’s the case. If he has to remove a feature, he has to. Please accept it, don’t argue, you will make a fool out of yourself.

Developers might be busy

Even developers might be busy: they have a day job, they might have to learn, they might have to write a thesis. Accept that they cannot answer to your bug reports instantly. It may take some days, maybe even months till there is a response. It’s not optimal, but that’s the way it is. Please also respect the private life of the developers: don’t query them in IRC without asking, don’t send them private mails asking for bug fixes. At least for me it’s a certain way to ensure that the bug won’t be fixed any time soon. Just think if everybody would send their bug reports via private mail, it doesn’t scale.

Bugs belong into the Bugtracker

It’s obvious, right? A bugtracker is the only available tool to ensure that the bugs can be tracked. A comment on a dot article won’t fix your bug, a mail to a mailinglist will be ignored. Use the bugtracker. Even if it seems to be a dumping place, it’s the best we have.

Don’t state the obvious

A unresolved bug in the bugtracker is not fixed. You don’t have to repeat in each minor release that it is still not fixed. If it were fixed, it would be closed or you could close it. Repeating the obvious just causes even more mail in my already overcrowded mail account and it does not increase the chances that I fix the bug for the next release.

Not all bugs are equal

Just because you have a bug which really annoys you, don’t assume that anyone else has the bug. It’s possible and likely that no developer is using the same workflow as you do. So the very obvious bug might be completely hidden to the developers. Also developers run a different version than you do: they run the latest development version. They might be not aware of a bug in an old version. So don’t assume that everyone sees your bugs.

Everybody has his pet bugs

Yes, you are not the only one having bugs. At the time of this writing the KDE bugtracker lists 23374 open bug reports with a rate of more than 400 new bugs per week (more gets closed). So every user has his personal very important bug which has to be fixed. Also there are many more open bugs than the developers could fix. Yes it’s software, yes that is normal. So don’t rally for the bug to get fixed. I as a developer decide which bug I’m going to fix and if I see that you think your pet bug is more important than the pet bug of someone else, I go for someone else pet bug.

Don’t insult

It should be obvious but it isn’t. Don’t insult the developers. It won’t help your case. Do you really think I’m going to fix your problem (which I do not experience) if you are insulting me? It is contra-productive and harmful. Remember that we spend our spare time. If I get insulted in my hobby, I might pick a different hobby. Your problem is never that important that it is worth the risk that developers are leaving the community.

We are not going down the GNOME road

It’s the argument I hate most when it comes to adding new features or removing existing ones when needed. Nobody is going down the GNOME road and it’s a very insulting statement towards the awesome GNOME developers for whom I have great respect. Such arguments are not going to help you: you want a feature and you try to convince me with such an argument? If you need a feature convince with real arguments under consideration that the developer has to take care of more than just collecting features.

Features are Expensive

Each added Feature means more code to maintain, more code paths which could break, more time to spend, less users which actually use a given code path and by that worse testing. There are valid features, there are not valid features. If the developer decides against your idea, please accept it, he has to take care of more than adding a bunch of functionality. Also please think about how likely it is that you find a new great idea which has not yet considered in the past? Please also use brainstorm.forum.kde.org to suggest new features. Everything else is most likely to just be ignored.

Developer Mailinglists are for Developers

It’s great that users can follow the development process directly by reading the internal mailinglists. But please remember that this is the think tank where the developers need to speak freely. There they exchange their ideas, there they might post controversial ideas on purpose. Don’t jump in and tell your opinion on how stupid the developer is. The mail was not intended for users but to get valuable feedback from other developers. Respect that, don’t destroy the discussion by pulling it in the wrong direction.

Don’t mention the war

Yes KDE 4.0 was a bad release, not ready for productive usage and aimed at developers. There is no reason to bring up KDE 4.0 in a discussion about a present bug or missing feature. It is our past and we cannot change it, especially not the developers who joined after 4.0. If you keep mentioning the state of 4.0 people will ignore you, even think that you are a troll. So just forget about it.

You don’t need to learn C++ to help

Everybody can help, so please give something back. It’s the best way to convince developers to fix your bugs by becoming part of the community. There’s documentation which needs to be written, there are translations which need to be done, there is a marketing team which needs help, there is user support which is lacking supporters, there are designers who need more clones, there is the bug tracker which really needs to be cleaned up. Especially if you hate that your bugs don’t get fixed, help the developer team by taking away the burden of going through all the useless and duplicate bug reports.

I hope these items help to keep KDE the friendly place which it is and helps to keep the relationship between users and developers healthy.

Posted on

Second Strike for KWin Scripting

I already blogged about it: KWin Scripting needs help from the community if it should be available in 4.8. Unfortunately nothing changed about the state, except that I added a build flag to not compile Scripting.

I just wanted to apply a patch and got a compile error because of scripting and I remember that my GSoC student had also problems with scripting during his project.

So this is the second strike for scripting. And you know what will happen when I have to proceed to the third strike 🙁 Step up now, or scripting will have to go.

Posted on

Rendering at 60 Frames

Full credits go to Alex Fiestas for complaining about the performance in a way that I wanted to do something about it, instead of being just annoyed and ignoring the comment!

Alex’s complaints got me wondering why we are not able to render 60 frames/second. Each frame should only take 16.67 msec and knowing that our repaint loop is fine, I could not imagine how a frame could take longer to render than the 16.67 msec. Knowing the KWin’s source code pretty well I suspected two parts of the repaint loop to be slow: the method which actually renders each window and our effect chain. The effect chain calls each effect in turn to transform windows. I had an idea to improve the effect chain for quite some time by calling only the currently active effects. That is currently each effect checks first whether it is active and just does nothing. So you basically call all effects again and again and nothing is actually performed except waisting cycles on checking whether it should do nothing (some effects are heavy there).
Of course I do not just optimize without checking if the code needs to be optimized, so I did an analysis of callgrind output and I was surprised. The effect chain was way more heavy than expected. In fact it’s so heavy that the paint method doesn’t matter in comparison. A deeper analysis of the code showed that there is a small bug, which we will fix in 4.7.2 (too late for 4.7.1), so that we can give the benefits as fast as possible to our users. But the real optimization by only calling the active effects will hit only 4.8. After that change the effect chain is no longer visible in the hot pathes of KWin. Also the change immediatelly helped to identify some expensive checks in some effects which are now ensured that they are not called in each frame (unless the effect is active).
After the optimization of the effect chain we are still not yet there and do not reach 60 frames during the animation, but you can really feel the improvements 🙂 Now the paint method shows up as one of the most expensive in callgrind (as expected previously) and I will now spend some time and thinking in how to optimize this one further by moving heavy operations out of the repaint loop.
In the long term I hope to be able to move the compositor into an own thread (also something I have in my mind for quite some time), so that heavy operations in window management and the decoration plugin do not slow down the repainting of the compositing. This might be tricky as we can run into dangerous deadlocks (imagine compositor and window manager both blocking the X Server), so we will probably first concentrate on moving e.g. texture loading into threads – something one of our new deelopers in KWin experimented with.
Overall very nice improvements, I’m happy with, but not yet satisfied as we do not yet reach the constant 60 frames/second.

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

Posted on

Thoughts about KDE Plasma on non-Linux Systems

This post represents my personal opinion. It does not need to represent any official opinion from any association I am involved with.

The Readme of the KDE Plasma Workspaces states clearly that our desktop is an X11 desktop environment:

KDE Workspace consisting of what is the desktop. The applications and libraries included aren’t required to b e portable and probably will only work with X11. On other desktops such as OS X and Windows, users wouldn’t r un these applications, but use the native ones instead. The typical application shouldn’t have dependencies i n workspace unless they are a component such as a screen-saver or panel applet.

So what does that mean? Our base system should work on every operating system supporting X11. Be at Linux, FreeBSD or Solaris. But how does the world look like, is this still the truth?

The world around us is changing and I would say that the statement is no longer true and soon needs to be adjusted to also include Wayland. This shows that we are at the point thinking beyond the X Windowing System. So what does that mean for the operating systems we support? At the moment Wayland is a Linux only system and given the current requirements it looks unlikely to be supported by non-Linux systems any time soon.

Wayland is of course only one example. There are more. Think about the deprecation of HAL or introduction of systemd. HAL we are still able to support in KDE thanks to our good hardware abstraction through solid. Systemd is not yet used, but I hope that this will change soon. Given these changes we must face the from a technology point of view all non-Linux are far behind Linux which means that on the long supporting the legacy technologies only for non-Linux becomes more and more a hurdle.

Personally I do not know any core developer of the KDE Plasma Workspaces using a non-Linux operating system. So you would expect that we have lots of bug reports for the non-Linux OS. Given that we already have hundreds of bug reports in KWin just about the stack on Linux which we use, there have to be even more for the non-Linux systems. No dev uses it, it gets not as tested as our Linux system, so there have to be bugs! So here the stats for KWin over the last 12 month:

  • Linux: 1054 opened bugs
  • FreeBSD: 4 opened bugs
  • Solaris: 3 open bugs

All three Solaris bugs are actually build errors on Solaris containing patches – they should have been opened on reviewboard. Due to miss of quality non of the patches was included in the software. From the four FreeBSD bugs, two are crashes lacking debug symbols – something that does not happen on Linux any more. One bug was actually also present on Linux, but seemed to only apply for legacy technology. So we have something like 250 bug reports for Linux for each non-Linux bug report.

For Plasma it’s 3529 bug reports for Linux compared to 30 non-Linux (only X11). From the seven Solaris bugs, six are again build failures. FreeBSD are mostly crashes again with missing backtraces and so on.

So this tells us that basically Solaris does not have any users and that it only creates work for us, because they use different compilers. Nevertheless we do not seem to accept the patches. So it’s great that Solaris wants to provide packages for our workspaces, but it should not create work. And yes reporting a bug and discussing it and even rejecting a patch is creating work.

And there is more we have to consider: KDE Plasma Workspaces are nowadays more than a set of applications for X11. It’s an integrated system providing a consistent user experience. Important parts of this experience is also our Oxygen design which does not only require compositing but also advanced OpenGL effects such as the Blur filter. Unfortunately free drivers are not able to provide these requirements on non-Linux systems due to lack of KMS and Mesa frozen at the last version before KMS. What we provide for non-Linux does not match what we want to provide.

The free desktops still have a considerably small market share, but as also the bug reports show the non-Linux users make less than one percent of our user base. If we now think about the global market share for non-Linux KDE Plasma systems we come to a number very close to 0. Our resources are spare and we should make the best out of it. Spending time on hardly used systems which are lacking behind in the technology we want to use and cannot provide the minimum requirements for our workspaces, does not sound like a sane idea to me.

To me it is clear for quite some time already that I won’t accept patches any more for non-Linux. Including another code path or even a build flag for non-Linux systems is not worth the increasing maintaining costs. If non-Linux systems want to include patches they should do it downstream.

Also for the inclusion of new technologies we should not wait for the non-Linux to catch up or do sacrifices in order to still support non-Linux. If a new technology brings us great advantages on Linux but means we have to stop supporting non-Linux because they do not provide the technology, I think it’s better to be really good on the one system.

Please remember: this is my personal opinion.

Posted on

Smooth Window Resizing

As Thomas does not blog and this is quite impressive, I had just to do a video and provide it here. Without further ado I present smooth window resizing with KDE Plasma 4.8:

(Direct Link)

Much Kudos to Thomas for fixing the XSync implementation inside KWin!

Posted on

Guest Post: Crash – Exam – Relaunch

This is a guest post from my Google Summer of Code Student Arthur Arlt.

Isn’t it a funny title for a blog post? But there is a reason for that because it happend a lot in the last weeks…

Crash

Having done my first review requests for my GSoC project, my new (six week old!!!) solid state drive stopped working from one moment to the other. I tried to get it running in other systems, but it was no longer detected by any BIOS. Taking a look at the homepage of Kingston I had to discover, that they found a technical issue of exactly that brand of SSD I had installed to my system. They are strongly recommending to do a firmware upgrade because this failure could lead to a total crash of the drive…
Thanks for the information 🙁 Luckily I made my review requests before, so at least the work done for GSoC so far was saved. But everything I did in these six weeks on my laptop is gone…
I got the SSD replaced, but this took almost two month, since the producer had to check by itself that the SSD is broken… So I bought a new one, because it was no fun working with my slow, old HDD.

Exam

I did not have too much time to be angry about the loss of data. I had to study for an exam in “Principles of Dependable Distributed Systems” which took place at Friday before Whitsun. After that, I have spent a lot of time to (re-)set up the build environment during the holidays.

Relaunch

I am now working into Martins hands supporting him to port KWin to Wayland. Especially the class Scene and its subclasses were provided with some signal and slot functionality.
A very important step to Wayland is to remove all X11 specific stuff from class Toplevel and to insert it into a new class XWindow which will then provide the functionality for X11 based windows. This refactoring emerged to be too difficult at that moment and Martin and me decided to do some other refactoring first. The parts I am currently working on is on the one hand to move all Workspace functions implemented in the file composite.cpp to an own class Compositor. On the other hand I am introducing a new class
DecorationPaintRedirector, which handles the composited decorations.

Work done so far

Some functionality of KWin was moved to own classes or even deleted. For example the broken functionality of TopMenu was removed. The functionalities of screen edge handling and Tabbox were moved to its own classes. The same happend to the tiling functionality. I also added some build option to chose whether KWin should be build with or without supporting a specific functionality. These build options are provided for Tabbox, Tiling, DesktopChangeOSD and ScreenEdges. They are automatically deactivated if building KWin for mobile devices is enabled.

Benefits

Thanks to the refactoring work done so far some parts of KWin are better structured and readable as before. One thing which confused me when I was starting coding for KWin was that in one file there could be several classed implemented. That issue was changed for some classes like Tabbox and Tiling by introducing new files or classes and by moving the related functions to the appropriate classes. These changes do not only make the code better readable but also better maintainable.

Desktop Summit

Two weeks ago I attended the Desktop Summit 2011 in Berlin. I was helping as a volunteer for video operation. Since I did not know anyone there, doing the volunteer work was a great decision. I never expected that I will get to know so many nice people. I was talking to other GSoC students and we were telling each other about our projects and the current state. Meeting some developers of KWin and Plasma was a great occasion. It’s kind of funny meeting them in real life if you had only virtual contact before 🙂 Last but not least the daily social events were the best opportunity to meet new friends. And one can say: Partying with open source people kicks ass!
The days in Berlin were very exhausting, but I had a wonderful time and I don’t want to have missed it.

Outlook

The GSoC project “Modularization of KWin” did not have a specific goal to reach, since we did not know how much work it will be to refactor all this stuff. One can say that there are still lots of things to do, but I am satisfied with my work done so far. The main point for me was to get into the community and I can say that doing a Google Summer of Code is a great opportunity to achieve this. I am really looking forward to go on with my contribution on KWin because it is really fun working with such a great team.

Cheers,
Arthur