Posted on

This week in KWin (2012 week 44, 45)

The last two weeks have been very important in the KWin development area. First there was the release of 4.9.3 which includes a very important performance bug fix for Mesa 9.0 Intel users. If you had problems please consider an upgrade.

On Thursday we had the hard feature freeze and many features got merged in during that period. Bellegarde Cédric merged in the appmenu support, allowing to have the window’s menu inside the window decoration. I love it as it’s very clean and I hardly use the menu in any application.

Fredrik merged in the initial port from XLib to XCB. This is an important step on the road towards Qt 5 support inside KWin and will probably require still quite some work during the 4.11 cycle.

Casian Andrei’s Google Summer of Code project on color correction got merged in as well. Unfortunately the merge did not go well, so there is still some work to do before the beta release. I hope that I can point to some documentation how to setup a color corrected system very soon.

We have received a nice performance improvement for moving windows when using compositing. This should help alleviating some choppiness when using vsync.

I merged in an improvement to window decorations, so that they can inform the compositor when they are not translucent. This improves the situation for rendering e.g. a maximized window with Oxygen but is most important for the new Plastik QML decoration which is not using translucency at all.

Due to so much going on during these two weeks I’m sure that I have forgotten to mention something important. This could be summarized as “I don’t like feature freezes” – it’s so un-git.

Summary

Bug Fixes

  • 308633: Window tab group separated in shaded windows
    Git Commit
  • 308759: Forgotten “${…}” witihin CMakeLists.txt
    This change will be available in version 4.10
    Git Commit

New Features

  • 102607: Display application menu and title bar side by side for maximized windows
    This change will be available in version 4.10
    Git Commit
  • 296773: GHNS support for Scripted Effects
    This change will be available in version 4.10
    Git Commit
  • 308995: Support shortened titles like in bespin in all decorations
    This change will be available in version 4.10
    Git Commit
  • 308990: Animate Window Maximize/Restore
    This change will be available in version 4.10
    Git Commit
  • 266596: Add support for appmenu-qt
    This change will be available in version 4.10
    Git Commit
Posted on

Notice for users of KWin master

With KWin master as of today the configuration of the Translucency Effect changed. It used to have translucency values in the area [0.0, 1.0] which got changed to [0, 100]. If you rebuild and just restart KWin it might be that you do not see any windows at all, because the windows are completely translucent.

To circumvent this problem run the KConfig Update application in $KDEDIR/lib/kconf_update_bin/kwin_update_settings_410 or just log out and log in again.

Users not running master are of course not affected by the change, the KConfig Update handles it correctly on first login after update.

Posted on

This Week in KWin (2012, week 40-43)

First of all I want to say sorry for not providing an update for the last few weeks, which makes this post more a “This month in KWin” than a “This week in KWin”. There are many reasons why I haven’t provided an update, one of them is that not that much has happened, as new features were merged in just this week and given that 4.9 has been out for quite some time not so many new bugs are reported.

Since Thursday we are in soft feature freeze, which means that only features listed in the Planned Feature Document are allowed to enter master. And there are quite a few nice additions which went into master lately. We have two new effects: one to animate when a mouse click has been performed. It’s a really nice effect especially for screen casts. The other one is a small JavaScript effect which animates the maximize window state change. If you don’t want to wait till 4.10 for this effect: it’s compatible with 4.9 and can be downloaded.

This brings me to the next topic: finally the categories on kde-look.org for our new scripted elements have been created which means we get GHNS integration. Luckily I prepared the code for Scripts and Window Switcher Layouts for 4.9 and the download button was just visually hidden. Now that the integration works, I pushed a change for 4.9.3 to show the button. For scripted effects this had not been prepared, but GHNS integration will be available in 4.10.

Given that GHNS for effects works and I really want to see many effects being developed, I was finally forced to create the API documentation. Tutorials will be added sometime soon, also including how to write C++ effects, my old tutorial is no longer up to date at all.

Summary

Bug Fixes

  • 307609: Zoom effect broken in master
    This change will be available in version 4.10
    Git Commit
  • 307866: kwin fails to build when the GLES support is disabled
    This change will be available in version 4.10
    Git Commit
  • 308248: Incorrect offset for decoration-maximized elements
    This change will be available in version 4.9.3
    Git Commit
  • 308283: [JJ]: DimInactive effect does not update on config changes
    This change will be available in version 4.9.3
    Git Commit

New Features

  • 183996: Add a rule to select the screen
    This change will be available in version 4.10
    Git Commit
  • 296773: GHNS support for Scripted Effects
    This change will be available in version 4.10
    Git Commit
  • 296774: GHNS support for KWin Scripts
    This change will be available in version 4.9.3
    Git Commit
  • 297636: GHNS support for Window Switching Layouts
    This change will be available in version 4.9.3
    Git Commit
  • 306436: GLPlatform should recommend either OpenGL1 or OpenGL2 compositing
    This change will be available in version 4.10
    Git Commit
  • 308990: Animate Window Maximize/Restore
    This change will be available in version 4.10
    Git Commit
  • 309006: Mouse Click effect
    This change will be available in version 4.10
    Git Commit

Tasks

  • 297634: Request category for scripted KWin Effects on kde-(look|app).org
    This change will be available in version 4.10
  • 297635: Request category for KWin Scripts on kde-(look|app).org
    This change will be available in version 4.10
  • 297637: Request category for Window Switcher Layouts on kde-(look|app).org
    This change will be available in version 4.10
Posted on

[Help KWin] Fix Warnings

Today I once more present some easy tasks to help the KWin development. This time it is a small coding task, though it’s not a very difficult task, but a very important one.

As you might know there is a new C++ standard available, which is called C++11. This standard provides quite some nice and useful additions to the language which we would like to use.

Unfortunately the new standard is not completely backwards compatible and there are some usages inside KWin which would no longer compile if we would enable C++11. This used to be totally valid code which did not even raise a warning. With gcc 4.7 we nowadays get a warning for all these code fragments which would not compile with C++11.

We need to fix those warnings, because we want to use C++11 in future and because they make it more difficult to spot the “real” warnings.

Therefore I set up a wiki page which contains all the warnings the compilation of KWin is currently causing and I would like to fix them all and that’s an easy way to help.

All you need is a current checkout of KWin and you need to be able to compile it with (at least) gcc 4.7. Please follow the instructions about building KWin. When you work on a warning just set the row in the table on the wiki page to InProgress and add yourself to the contact information. Please do this step as it prevents that multiple people start to work on it. Once you have a warning (or multiple) fixed, just open a review request on Review Board for group KWin.

If you work on it, please concentrate on warnings mentioning C++11.

Posted on

A journey through virtualization

This weekend I had a look on enabling the OpenGL compositor when running in a virtual machine. My assumption was that given that the next version of Ubuntu is going to require OpenGL, there should be no problem with getting OpenGL running in a virtual machine.

I normally use KVM when I have need for a virtual machine running a Linux guest. As far as I know you cannot get OpenGL with this technology, so I hadn’t looked into it for quite some time.

My first attempt was to just use the project neon weekly build. Unfortunately I failed to convert it to a VirtualBox image, nevertheless I decided to run it and verify that KVM does not support OpenGL. Well I was rather surprised once the machine was up to see that OpenGL was functional, but well it was slow. Restarting KWin showed me that there is a missing slot (which I am aware of and is already fixed in one of the pending reviews) in master which makes the fallback to XRender not work, but KWin just uses llvmpipe. OK, result incorrect, but at least validated that KVM is not working.

I then decided to try VirtualBox with an install of Kubuntu Natty. Install went well but no OpenGL available. The Xorg log file told me that VirtualBox does not know the XServer version. Installed the latest version of VirtualBox, installed the latest version of guest additions in the Kubuntu guest, but no success: driver does not work.

So I decided to test with an outdated system, aka Debian Testing as I’m also running this on my workstation. Here I was more successful. After installing the system in the virtual machine OpenGL worked out-of-the-box. And what surprised me even more was that OpenGL in KWin worked when using KWIN_DIRECT_GL=1 and KWIN_COMPOSE=O. This means OpenGL works in general and it’s only blocked by KWin not knowing the driver.

KWin with OpenGL in VirtualBox

The main reason is that KWin does not use direct rendering if it finds an unknown driver and VirtualBox only provides OpenGL in direct rendering mode. If LIBGL_ALWAYS_INDIRECT is set, it falls back to Mesa’s software rasterization and KWin sets this environment variable if it doesn’t know the driver.

This meant I had to perform some coding to recognize the driver and had to test it in the virtual machine. Thanks to host and guest running the same version of Debian I was able to setup a NFS share and just use my normal development version of KWin.

After a little bit of hacking and fighting with NFS I got the driver reported correctly and KWin running with OpenGL without using environment variable hacks. But VirtualBox’s driver is not complete. Some methods we (optionally) use from GLX 1.3 are not implemented and trying to use it resulted in warnings. That unfortunately needed a hack inside KWin (it’s small and well contained, so it’s not much of an issue).

With VirtualBox working I decided to also look into VMware and have installed VMware Player for the first time in years. Converted my Debian image into a VMware compatible format, enabled 3D acceleration and started the system, just to be presented with warnings that 3D is not working.

The Internet told me to add

mks.gl.allowBlacklistedDrivers = TRUE

to the vmx file. But that did not resolve the issue. The two warnings went down to one, but still a warning. Apparently one has to install libtxc-dxtn-s2tc0 in order to get 3D support.

Installed and no warnings: yeah. Started the system, but no OpenGL. Installed the guest additions, but it told me that the system already has X11 integration. Looked into the Xorg log and yes it complained that something is wrong with the module. So no OpenGL inside Debian guest.

KWin with OpenGL in VMWare player

Resolved to my previous plan of trying Kubuntu 12.10. Started it in a live session and KWin is not composited. But glxinfo reported a driver, so I restarted KWin with KWIN_COMPOSE=O and there it was: OpenGL running also in VMware.

Looking at KWin’s output I was quite happy to see that it is a Gallium3D driver, which means we don’t need any adjustments at all. KWin uses OpenGL out-of-the-box, it was only not running, because of the live session of Kubuntu. So all that was needed was adding some detection code, that KWin doesn’t print out “unknown” in the debug output. Unfortunately using my KWin from Debian did not work, so I could not yet verify the output, but that can be done once it hit project neon.

Once the patches are merged into master KWin will use OpenGL in virtual machines – if supported. But given the experience it looks like at least on Linux hosts OpenGL is basically not supported in default setups. I would like to also support Parallels and Windows Virtual PC, but am of course lacking both required host operating system and licenses.

Posted on

To llvmpipe or Not?

Some days ago I prepared a patch which moves the decision which compositor to use inside the driver detection code. This allows us to remove hacks we currently have inside the compositor initialization code to move specific drivers (e.g. the software rasterizer) to a better suited compositor. The base idea is that we always give a user the compositor which is best suited for her system. It’s in my opinion not a good idea to push users on the OpenGL 2 compositor, just because the hardware supports the required extensions, if we know that the hardware is actually not capable of performing well. For such users the OpenGL 1 based compositor is better suited or maybe even the XRender based compositor.

As well for rather old hardware it’s a better idea to not provide any OpenGL based compositing even if theoretically the driver supports it.

But automatism is not always the best solution. Yes giving from experience the best suited compositor is a good idea, but still it makes sense to allow the user to overwrite it. In this case the “user” is mostly myself and other developers who have to be able to easily switch the compositor. For me this is most easily done using an environment variable as I am restarting KWin all the time anyway and is faster than going into a UI and changing the settings and afterward changing them back. Of course although this is controlled through an environment variable, there are also settings to control the chosen compositor. E.g. you can select XRender or disable the OpenGL 2 based compositor. But there is no UI option to enforce the OpenGL 2 compositor if our driver recommendation is to use OpenGL 1 or XRender (we don’t want to provide users the option to destroy their system).

One of the side-effects of this driver based recommendation is that the hack to switch to XRender for software based rasterizers has been removed in the patch. Instead these drivers now recommend to use the XRender based compositor. And in combination with the changes in the handling of the KWIN_COMPOSE environment variable this results in the possibility to run OpenGL based compositing with the llvmpipe driver.

But as you can see one has to manually enforce it through an environment variable and I would not recommend anybody (or any distribution) to use it. OpenGL based compositing over llvmpipe is considered as a fallback approach for other OpenGL based desktop environments like GNOME Shell and Unity. But I do not consider it as a solution for the KDE Plasma Workspaces. I think we have better solutions for fallback (XRender or no compositing).

Let’s have a look on the use cases for llvmpipe based compositing:

  • Outdated hardware not providing OpenGL
  • Too new hardware without driver yet
  • Embedded hardware without driver yet
  • Virtual machines
  • RMS not like binary drivers

If your hardware is too old to provide the requirements for OpenGL based compositing, it is quite likely that your CPU is also rather old. We can assume a single-core CPU of either the Pentium era or an early Atom. You don’t want your CPU which is not suited for this task to spend all the time rendering the desktop. If I enable llvmpipe for KWin on my system (quad core) it puts about one core under full steam.

The case that there is new hardware without drivers available on Linux has luckily become a very rare case. Basic modesetting support for NVIDIA’s latest hardware (Kepler) was available on the same day as the announcement of the hardware. And the blobs do support also their latest hardware. So in most cases all that is needed is installing the latest driver or upgrading the distribution. If you spend lots of money for new hardware you probably want to use it and not have the CPU emulate what your expensive hardware is supposed to do.

In the case of embedded hardware it’s unfortunately still rather common that there are no drivers available. But ARM based systems are also not known for having extreme power. If you don’t want your high-end system to use llvmpipe based OpenGL compositing you even less want your low-end system to do it. You bought your Raspberry Pi hopefully for more useful things than running at full-steam to render the desktop.

If you run a virtual machine your resources are rather limited. It needs to share the resources with other virtual machines and your host system. If you run in a cloud you probably don’t want to pay for rendering the desktop through llvmpipe. You have a task to solve and the more CPU that task gets the less you have to pay. In case of a local system you also don’t want to have the virtual system run at full-steam just to render the desktop. There are really better things to do with a VM.

Last but not least there are the users who don’t want to run binary drivers. Sorry I cannot help you there. If you really think you want to spend lots of money for hardware that you don’t use, that’s fine with me. But I would suggest to only buy hardware which has free drivers available and there are nowadays options from all of the three big GPU providers.

Overall we see that llvmpipe as a backend for OpenGL based compositing is actually not needed in the case of the KDE Plasma Workspaces. We have working fallbacks like XRender or no compositing at all and those do not put the system under full-steam.

Given that I am not considering to turn llvmpipe into an option for KWin. I think that most users who would need llvmpipe are better suited with XRender based compositing even if a few effects are missing then. For me as a developer on the other hand llvmpipe is a very interesting target as it can help to optimize our rendering stack.

Of course what I considered in this blog post is only relevant for OpenGL based compositing of the KDE Plasma Workspaces. We do have proper fallbacks like XRender or no compositing which is not available in other environments which decided to use llvmpipe as a fallback. They have to do a different evaluation and I cannot provide it for them as my evaluation result would be: use KWin 😉

Posted on

KWin Hacking++

Very soon after joining the KWin development team almost five years ago, I realized that KWin would need at least one full time developer. It is one of the most important parts for the user experience of the KDE Plasma Workspaces and we have seen quite often that important changes for the user experience could not be implemented due to lack of manpower.

With the upcoming required changes like Qt 5 and Wayland the need for developers is increasing. I think it’s currently a wonderful time to join the KWin development. It’s a very interesting and challenging work and working on KWin means working on the future of the free desktop.

Lately I had more possibilities to work on KWin and starting from January I will join Blue Systems for working on KWin. I want to thank Blue Systems for this great opportunity and also for all the other sponsored work in the KDE community.

I’m really excited about this new possibility and are looking forward to it. I want to use this chance to work on bringing KWin to the world of Wayland. As explained in my blog post about the current state of development, I’m very satisfied with all the preparation work which went into KWin and I think it’s now in a state that we can start hacking on it 🙂 And I hope to see lots of involvement from the community. All the work will go directly into master, so it will be easy to test the new features but also easy to contribute to it. I intend to continue setting up simple tasks for the community and announce them through my blog.

Posted on

[Help KWin] Document Effect Animations

Given the success of the two community involvements I recently tried with KConfigXT and UI files (both merged into master), I decided to set up regular tasks and announce them through my blog. I will mark those in the caption with [Help KWin].

And this weeks task is a no coding task, but a documentation task. It is a task which can be considered as part of the Extra Mile project.

Let me introduce to the idea: some days ago I sent a mail to the kde-artist mailing list to get help on having better animations, because somehow it doesn’t feel as smooth as other compositors, but performance is not a problem. So our animations have to be wrong (I assumed) and I wanted help from people who understand it.

Well we figured out quite fast that the actual issue is that our animations are not consistent, e.g. two fade animations don’t look the same. Now that is actually pretty easy to fix and would give a much better user experience.

But before we can do so we need to know our animations and to be honest we do not know. So I call for help! Help us document all the animations going on. This would allow us afterwards to define basic patterns for the animations.

I just created a wiki page to document the progress and to explain how one can find the animations even if one is not familiar with C++. While programming skills can be helpful it’s not required for this task, it’s basically just “reading text” in the browser.

Posted on

This week in KWin (2012, week 39)

And another week gone. Major event of course tagging of 4.9.2 and a few more bug fixes for this version. But that’s not the only work that happened. I still have a few changes under review but also merged in some further changes for the OpenGL compositor I had been working on during XDC. Nothing really special except maybe that the specific OpenGL compositors can now be referenced by an enum type which simplifies the code checking for OpenGL 1/2 specific code in the effects.

Summary

Crash Fixes

    Critical Bug Fixes

      Bug Fixes

      • 307365: Decoration broken in maximized state
        This change will be available in version 4.9.2
        Git Commit
      • 307609: Zoom effect broken in master
        This change will be available in version 4.10
        Git Commit
      • 307125: Closed Windows stay in dock apps like AWN and docky with desktop-effects enabled
        This change will be available in version 4.9.2
        Git Commit

      New Features

        Tasks