Setting up a virtual machine with virgil support

Recently I wanted to try how virgil, the OpenGL solution for KVM/Qemu, works with KWin. Virgil (sometimes also referred to as virgl) is a wonderful solution, but so far I hadn’t been able to test it. Especially I was interested in seeing how it works with Wayland. Unfortunately I did not find much information on how to setup a VM which supports virgil, so a good reason to write a blog post.

As base setup I used Debian testing, as guest system KDE Neon Developer edition, for virtual machine management Virt-Manager. To enable virgil support one needs to configure the Video device with Model “Virtio” instead of QXL which was common in past. When using the Virtio driver there is a checkbox “3D acceleration” which needs to be checked.

But this is not the only place where adjustment is required. In the “Display Spice” section one needs to check the “OpenGL” checkbox. It allows to select the graphics device. For me “Auto” just worked fine, but I only have one GPU installed. On “Listen type” one needs to select the “None” entry. Otherwise you get a very cryptic error when trying to start the virtual machine.

With these adjustments the virtual machine was ready to go and I got the sddm screen (which uses OpenGL). So all good? Unfortunately not: sddm seemed frozen. Disabled virgl, booted again, reconfigured sddm to do auto-login, enabled virgl and restart. The desktop loaded, KWin was picking up OpenGL, Plasma was properly blurred. Also a restart into Wayland worked without any problems. But KWin of course does not really know about virgl yet and just shows an unknown device when checking the support information.

As I had installed a developer edition, I wanted to give this a try. Started kdevelop, checked out KWin, edited the relevant sources, compiled, installed, committed. I was very pleased with the out-of-box experience for hacking on KDE software on KDE neon developer edition. In less than 2 hours I went from setting up a VM to pushing the accepted change to the git repository. And the largest challenge was setting up phabricator (arc is not installed, though migration to gitlab…) and getting my ssh key into the VM. The result is KWin detecting the virgil renderer in support information (screenshot taken on X11):

I hope to find some time to investigate why sddm seemed frozen – this is unfortunately currently quite a little bit of a showstopper for using virgil. Otherwise I am very pleased with the results. Having a working virtualized GPU is a big step for Linux as it allows to run modern desktop environments such as KDE Plasma and GNOME on a full free software virtualization stack.

KWin and shadows for client side decorated windows

Quite regularly we see bug reports or user support questions about why KWin does not add its shadows to client side decorated windows such as GTK’s header bars. As this topic comes up so often I think it’s time to write a blog post to explain the situation.

First of all: this is a big misunderstanding. KWin does not have any shadows. KWin does not add shadows to any windows at all. There is no such thing as a generic shadow which KWin would add. Due to that of course KWin cannot add shadows to client side decorated windows.

Instead KWin provides a shadow rendering service. The windows can specify a shadow which will be rendered by KWin. This was created for Plasma’s windows which are after all also client side decorated. But is also used by the widget style Breeze and Oxygen for popup menus, etc. The protocol for the shadow rendering is available for X11 and Wayland. Also our window decoration API provides a possibility to set the shadow and inside KWin shadows are rendered using the same code path, no matter whether it’s provided through X11, Wayland or the window decoration.

The approach we chose here works really well for non-composited and composited setups. It also works well with other window managers and compositors as applications can easily check whether it’s supported and adjust rendering or just not provide the shadow. Thus a good experience is kept. Also the control over the design of the shadow is completely with the window and not enforced by the window manager. We noticed that enforcing by the window manager doesn’t work as the window manager has no idea how the light model of the window looks like. Does it require drop shadows, or is there a central top light requiring something like a glow? We don’t know only the application can know.

So if you wonder why a window is not having shadows it’s due to them not providing one. Not because KWin is evil and doesn’t add it’s shadow to it. We would be very happy to add the shadows if applications allow us to hook in. E.g. GTK could provide a plugin infrastructure so that we can add the shadows using our mechanism. We don’t expect GTK to add support for our shadow service – that’s too much asked for, though would be great. Instead all we need is a hook that allows us to add a plugin. That’s how we can do it in Qt (Qt Platform Theme plugin, QStyle plugins).

KWin in 2018

This year was a very interesting year in the development in KWin. After having been the maintainer for several years, I knew that I would not be able to continue being maintainer for personal reasons. Personally I had tried to lower my contributions for quite some time already and encouraged others to do reviews, keeping out of some reviews completely. In 2018 several of such code contributions landed which I hadn’t looked at all and which work out greatly – an example is the new excellent blur effect which I didn’t look at the code at all.

When I stepped down as maintainer I had to read many negative and fearful comments doubting the future of KWin. Personally I was very positive that me stepping down would not have a negative impact, in fact I even hoped for positive impact as it gives new blood the chance to fill up the gap and bring in new ideas. I had become very conservative over time.

So I just run some git stats [1] over the KWin repository to try to verify the assumption that me stepping down had no negative impact: In 2017 there were 614 non scripty commits. The author with most commits was me with 387. Overall 37 developers contributed to KWin.

In 2018 (01.01.2018-26.12.2018) there were 644 non scripty commits authored by 48 developers. The developer with most contributions is Vlad (241). I am no longer the top contributor in KWin (“only” 115 commits) – the last time this happened was 2008, the year I joined KWin development.

I am very happy about this development. We have new developers like Vlad and Alex working on areas which had been neglected for quite some time. The way the effect system improved thanks to them is really great. We have developers like David and Roman improving the Wayland support and overall KWin core. The knowledge about KWin gets spread and the development work is spread over more shoulders. Having a single developer doing the majority of commits is not always healthy. We can see the positive effects this year: we have more contributors overall and more contributors contributing multiple patches.

[1] git shortlog -sne –since=”01 Jan 2018″ –before=”01 Jan 2019″ and git shortlog -sne –since=”01 Jan 2017″ –before=”01 Jan 2018″

It’s not a good bye

As you might have heard I decided to step down from my maintainer positions in KDE, especially KWin. Unfortunately I had to read very weird things about it and so I think it’s time to write about what it means that I am no longer maintainer of KWin.

First of all: I’m not leaving KDE. I’m still contributing in form of code, bug management and reviews. And I intend to continue to do this.

Second of all: I did not step down as maintainer because of the VDG or the usability group. I understand that my mail read like this, but it’s not the case. That I would step down as maintainer was inevitable and I’m sure it didn’t come as a general surprise to my fellow Plasma and KWin hackers. Personally I decided to step down as maintainer once the Wayland port is finished years ago. In my opinion KWin reached that state about two years ago. I continued to be maintainer to prepare for a good hand over. I deliberately reduced my involvement and passed responsibility to others. This was a long process and worked great in my opinion. As an example I want to point out the new and awesome blur effect introduced in 5.13. My first comment on the phabricator code review was that I’m not going to review it, but leave it to others. I think the result is great and I’m very happy how this worked out.

Over the last year I thought a lot about passing on the torch for maintainership. I realized that I contribute less and less of code but are at the same time blocking many changes due to me reviewing the code and giving a nak or through inactivity by just not reviewing the code at all. In KDE we have a saying: “Those who do, decide”. I realized I’m not doing enough anymore to decide. This results in the timing of me stepping down: I once again nak’ed a change and afterwards realized that I cannot do this. Either I need to actively veto a change I consider wrong and by that anger those who do or step down as maintainer. I decided that I don’t want to be the grumpy old conservative who is against progress and thus did the only logical consequence. It was inevitable, I would have stepped down as maintainer in the next half year for personal reasons anyway, it was just a little bit sooner to help those who are currently working on improving our products.

For KWin this means a significant improvement. A maintainer who is not responsive to reviews is not helpful to the project. By stepping down I give others the possibility to accept changes and nobody needs to wait for me to acknowledge changes. This is especially important for new contributors who we want to integrate better. Also for me personally it is a great improvement as it takes away a lot of burden for not reviewing the code. I now feel way more relaxed to do code changes I’m interested in and chiming in to reviews where I feel like I want to say something. And at the same time I can ignore other review requests as I know there will be a good review on them and it won’t depend on me. Also KWin is currently in a great position to step down as maintainer. We have more developers working on KWin than we had for years. KWin is in a great shape and I’m very positive about the future.

I read a few comments where users expressed the fear that the quality of KWin would suffer by me stepping down. I feel honored that users think I acted positively to the quality. Personally I am quite certain that the quality of KWin won’t suffer. As example I present you the 5.13 release with more user visible changes in KWin for years and me hardly contributing anything to that. Also KWin has an awesome test suite which would catch regressions.

On the other hand I read some disturbing comments about NVIDIA support getting improved by me stepping down as maintainer. Let me assure you that I never blocked any change which would be NVIDIA specific. In fact I encouraged NVIDIA to implement the changes required to get EGL stream working in KWin. Unfortunately NVIDIA has not contributed such patches.

Now a few words on how I maintained KWin. My aim as maintainer was to hand over the code to the next maintainer in a better shape than how it was when I became maintainer. I hope that I could contribute to this aim and many of my decisions as maintainer were motivated by that aim. I learned what went well in past KWin and tried to apply the lessons from it. I considered KWin as a standalone product inside KDE Plasma and judged changes from the perspective of a window manager. One of my highest rules was: no workarounds! No workarounds for broken applications, no workarounds for broken drivers and no workarounds for Plasma. No matter how many users a software has, KWin won’t add workarounds. This applies to software such as Spotify, Chromium and even GTK. If the applications or toolkits are broken, they need to be fixed, so that it works in all window managers and not just in KWin. With the time I found workarounds, e.g. for Netscape Navigator. Of course such workarounds don’t make sense, but clutter the code and negatively affect all users. Or there were workarounds for kdesktop and kicker (the KDE 3 panel, not the Plasma 5 menu). KWin is older than Plasma and I expected that Plasma would evolve and change (which did happen with Plasma 5, Plasma Active and Plasma mobile). KWin needs to be flexible enough to handle such evolution without having to rely to workarounds. Thus if something was needed we did the proper solution instead of finding fast workarounds. I think that the refusal to add workarounds helped the product KWin to achieve the level of quality we have today. Of course it results in disappointed users – as an example the NVIDIA users who would like to have a better experience – but in the long term all users benefit from the strict and hard line I used to maintain KWin.

I also learned that the number of options is a problem in KWin. We have optional features with even more optional features. Over the years I noticed that most of the breakage is in such areas. By trying to do too much we degraded the usability and quality of KWin. I reacted to this by making KWin more flexible and allow users to influence how they like to have KWin without having to carry the code in KWin. The result is KWin scripting, scripted effects, Alt+Tab QML switching themes and in general moving all of the UI elements to QML. This allowed us to streamline KWin and provide a high quality for the areas we offer, but at the same time give users the full flexibility to adjust KWin as they need. Simple by default, powerful when needed.

On the other hand this of course did not go well with all users. Many users requested features and my general response was: no. Any addition to KWin should go through scripts and be maintained by users. Of course not every user understood why they should fork an effect just to get another option. Or why I said no to a contributed patch. But in the end I think this helped to keep the quality high and have KWin in a maintainable state. In that sense I understand that not every user appreciated how I maintained KWin. The hard rules I applied in bug reports unfortunately created tension and the community working group had to step in more than once. For those users hoping that they can get their pet bugs resolved now that I stepped down as maintainer: I’m sorry to disappoint you. I still go through the bug reports and will continue to manage them the way I did as maintainer as long as my successor decides to apply different rules for maintaining KWin.

Last but not least a few words to my criticism on the VDG and usability project. First of all I need to apologize for mixing this in my mail about stepping down as maintainer. I should have raised my concerns at a different time as this was unfortunately received as I stepped down due to conflicts. I’m somebody who speaks up when he feels things go wrong. Given the way how I maintained KWin as explained above this creates tension with the usability project. My aim is to not implement every feature request and move the responsibility to users while the usability project tries to implement everything which makes users happy IMHO. This is obviously a clash of cultures and due to that I very often had to take an opposite position to what the usability project tried to achieve. I raised my concerns quite often. For me it was personally difficult to hold up such a position over a long time. Due to that as explained in my mail I lost motivation to review changes. My mail was mostly to explain why I lost motivation and I think to those in Plasma who know how I maintained KWin and what my aims are this was understandable. I was very unhappy on how this got communicated in some news postings and social media. As all those internal information were missing. I urge users to keep project internal discussions to the projects.

What I want to point out is that I really appreciate the work the usability project and also the VDG are doing. They are super enthusiastic and try to bring our software to the next level. I do not disagree with their work. The criticism I expressed in my mail was focused on the process and the transparency on how decisions are made. That’s where I personally see the need for improvements. What’s quite important to me is to point out again that those two projects are not responsible for me stepping down as maintainer.

Thank you.

Shadows in Window Screenshots

Every few months there is a review about Plasma by dedoimedo and one critic point is that screenshots include the shadow. As I’m rather annoyed of these complaints about this I’m now doing a blog post to explain the situation so that in future this can be skipped.

Shadows in the screenshots are not a bug, but an intended feature. It was implemented by me in 2010 on request by Nuno Pinheiro, our Oxygen god. Before screenshots did not support shadows and looked really, really bad as the window decorations are round and contained black corners. Shadows were part of the design and that was completely lacking. So we came up with a rather decent solution on how to screenshot the window with shadows included. I first mentioned this new effect in this blog post from August 2010.

This has been eight years ago. I cannot remember any bug report about this being an issue. But dedoimedo reports about this every few months in a rather aggressive way:

I can see your heartbeat, coming from the shadows. Seriously, toggle on, toggle off. Plasma Kid.

Given that literally nobody else cares about this: no, spectacle won’t get a checkbox to toggle shadows. We are not going to reduce the usability of all users by adding another checkbox due to one reviewer having problems with it. In future you can know blame me personally for this instead of doing bad reviews on Plasma. It’s all Martin’s fault. Thank you.

Unsetting QT_QPA_PLATFORM environment variable by default

Since the introduction of the Plasma/Wayland session we set the QT_QPA_PLATFORM variable to wayland by default. After a long and hard discussion we decided to no longer do this with Plasma 5.13. This was a hard decision and unliked by everyone involved.

The environment variable forced Qt applications to use the wayland QPA platform plugin. This showed a problem which is difficult to address: if Qt does not have the wayland QPA platform plugin the application just doesn’t start. If you start through the console, the application will tell you:

This application failed to start because it could not find or load the Qt platform plugin "wayland"
in "".

Available platform plugins are: minimal, xcb.

Reinstalling the application may fix this problem.
Aborted (core dumped)

That is not really a useful information and does not tell the user what to do. Neither does it tell the user where the actual problem is and how to solve it. As mentioned when using a graphical launcher it’s worse as the app just doesn’t start without any feedback.

But how can it happen that the qpa platform plugin is missing although Plasma itself happily uses it? The problem is that application installed outside of the system bundle their own Qt and Qt does not (yet) include QtWayland QPA platform plugin. This affects proprietary applications, FLOSS applications bundled as appimages, FLOSS applications bundled as flatpaks and not distributed by KDE and even the Qt installer itself. In my opinion this is a showstopper for running a Wayland session.

The best solution is for Qt including the QPA platform plugin and having a proper auto-detection based on XDG_SESSION_TYPE. The situation will improve with Qt 5.11, but it doesn’t really help as the Qt LTS versions will continue to face the problem.

For now we implemented a change in Plasma 5.13 so that we don’t need to set the env variable any more. Plasma is able to select the appropriate platform plugin based on XDG_SESSION_TYPE environment variable. Non-Plasma processes will use the default platform plugin. With Qt < 5.11 this is xcb, with Qt 5.11 this will most likely change to wayland. KDE’s flatpak applications pick Wayland by default in a Wayland session and are unaffected by the change.

What is really sad about the change is that the Wayland qpa platform plugin gets less testing now. So we would like to ask our users to continue testing application with the Wayland platform plugin by setting the env variable manually or specifying –platform wayland when starting an application.

On Benchmarks

A well knwon Linux website published a “benchmark” about Plasma Wayland vs Plasma Xorg vs Gnome Shell (Wayland and Xorg). Before anybody tries to draw any conclusion: this is not a proper benchmark. It shows no statistical relevance as it was only tested on one hardware and only on one distribution. It shows numbers, that’s it. The numbers might be nice or not, I don’t know. I am not able to draw any conclusions from these numbers.

This has been a general problem with those benchmarks for years. The setup is IMHO utterly stupid and not helpful for development. Rather the opposite as we have to spend time on explaining why the benchmark has a useless setup. There are two possible ways to address those benchmarks: ignore or volkswagen. On X11 we do to a certain degree volkswagen those benchmarks as we turn the compositor off if the games used in the benchmark request it. But we don’t do the full story yet, we don’t check for any of the benchmark applications and do not yet adjust our rendering to get better numbers. If anyone is interested: most of it should be easily achievable through KWin scripts. But yeah, if the numbers show better results for X11 than for Wayland it might be due to KWin cheating on X11.

Server side decorations and Wayland

I heard that GNOME is currently trying to lobby for all applications implementing CSD. One of the arguments seems to be that CSD is a must on Wayland. That’s of course not the case. Nothing in Wayland enforces CSD. Wayland itself is as ignorant about this as X11.

The situation is that GNOME Shell and Weston require CSD, but KDE Plasma and Sway do not. In fact we created a protocol (supported by GTK) that allows to negotiate with the Wayland compositor whether to use CSD or SSD.

I’m the one who drafted that protocol and I get requests about upstreaming it regularly. If I think about it, I got contacted by pretty much every toolkit about it in private – except EFL and GTK. And every time the toolkit developers tell me “this is what we want!” My answer to this is that I’m keeping out of the discussion. I’m burnt from it and are not interested in it any more.

But of course: if toolkit developers think that this is needed, don’t get fooled by GNOME asking you to implement CSD. In the same way you can ask GNOME to support server side decorations. They could do it, because they need it for XWayland anyway.

And I can totally understand you toolkit developers to not want to implement CSD. It’s a lot of work and it’s difficult to not look like an alien in the various desktop environments.

KWin/X11 is feature frozen

Yesterday the KDE Community released the Beta for Plasma 5.12 LTS. With that release the feature freeze for 5.12 is in place and also an eternal feature freeze for KWin/X11. To quote the release announcement: “5.12 is the last release which sees feature development in KWin on X11. With 5.13 onwards only new features relevant to Wayland are going to be added.” This raised quite some questions, concerns and misunderstandings in the social networks. With this blog post I try to address those question and explain why this change in policy is done.

Is KWin/X11 still maintained?

Yes! We are just in the process of releasing an LTS. Of course KWin is fully maintained in the LTS life time. While in 5.8 only X11 was maintained, now we are able to offer maintenance for both X11 and Wayland. For the maintenance we do not differentiate between windowing systems.

Will X11 bugs still be fixed?

As X11 is under maintenance, I expect bugs to still get fixed.

Does this mean that in 5.13 X11 will be unmaintained?

We are going to forward port bug fixes from the 5.12 branch to master. Thus any release after 5.12 will get all bug fixes from 5.12. Given that I would say 5.13 will also be maintained on X11.

Does this mean that in the next LTS X11 will be unmaintained?

We will decide when the time comes. Currently I do not expect that we would drop maintenance.

Does this mean Plasma 5.13 will default to Wayland?

This is about feature freeze for X11. Whether Wayland will be the default or not is completely unrelated to this.

Will X11 users not get any new features in KWin?

Of course there will be new features! Most functionality in KWin is independent of the windowing system. Any improvement to those areas benefit Wayland and X11 users. Currently we have a few improvements in the pipeline, for example tooltips on decoration buttons, improved blur effect, a rework of slide desktop effect, improvements to the cube effect and a few more. All of them will be available to both X11 and Wayland users.

How do you decide whether it’s an X11 only feature?

In the case of KWin this is very simple. There are areas in our code structure which are only get pulled in if run on X11, other areas are marked in an if (x11) section. If the new feature touches this code, it’s probably not going to be added.

Does this feature freeze also apply to other KDE software?

No, but personally I would recommend any maintainer to apply a similar feature freeze. I personally will not help developing any X11 specific feature any more and resigned as maintainer of various X11 specific frameworks this week.

What are you going to do if someone present a feature for X11?

It won’t be merged.

But why?

This requires a little bit more explanation. I had a look at the most prominent issues we had over the last years. Where are our stability problems, where are our quality problems, what costs most development time? I observed that it was always in new features specific to X11. Very often even for features we added to Wayland without causing problems.

So I started to look into why that’s so. The obvious answer that we don’t get bugs for Wayland because nobody uses is, is not the case. We get many bug reports for Wayland and many users are nowadays running Wayland. So the reason must be somewhere else.

On Wayland we are able to test the code. Let’s take an example: we get input events through libinput. For this we have unit tests through mocking. Thus we can automate the testing of the lowest layer. From libinput events are sent into KWin core through an internal API and that we can also use in the integration tests. So we can simulate everything from the point where libinput events would hit KWin core. We can test this properly, we know that we get all events (because KWin is the display manager) and we can test every aspect. We can lock the screen and verify how it works, we can make applications grab the pointer or keyboard and test this. We can invoke global shortcuts, etc. etc. It’s all just as if we get the events through libinput. The quality of these new areas in KWin feels really good.

A few weeks ago some commits I did hit the Linux media about KWin/Wayland without X11 starting too fast and due to that causing bugs. These issues were found through our test suite, before any user would ever be exposed to them.

What we did in the past was taking these new features and bring them to X11. But there we cannot test. There is no way on X11 to e.g. fake a touch screen. On X11 we cannot test how this behaves if we lock the screen or used Alt+Tab. We can write the code and manually test it. Hey it works, awesome! But that was mostly not the case. There were corner cases which caused trouble. And to this comes that the main devs run Wayland instead of X11. If features break they are not exposed to the bugs.

Could you give some examples of things that broke?

Sure! The first feature we backported to X11 was “modifier only shortcut”. We spent months fixing the fallout because of X11 weirdness. Another feature backported was panels on shared screen edges. It worked great for Wayland, but on X11 some corner cases were overseen and caused issues, which affected our users and required time to fix. We backported the touch screen swipe gesture on X11 which was a mess. On X11 touch screens are also mouse events, that made it difficult and created many corner cases.

The problem is not adding the feature. The problem is fixing the bugs created by the new features.

But if a new foo requires adjustments?

KWin won’t be adjusted to any new requirements in the XServer, Mesa, input stack, proprietary drivers, etc. If something breaks it’s the fault of those components which broke it.

Ten years of KDE

At the end of the year 2007 I sent my first patch to KWin. At that time 4.0 was about to be released, so that patch didn’t end up in the repo in 2007, but only in beginning of 2008 and was released with 4.1.

Ten years is a long time and we have achieved much in KWin during that time. My personal highlight is of course that KWin is nowadays a Wayland compositor and no longer an X11 window manager. According to git shortlog I added about 5000 commits to KWin and another 500 commits to KWayland.

So up to the next ten years! Merry Christmas and a happy new year 2018.