Using maliit-keyboard in a Plasma Wayland session

For some time Plasma Wayland had built-in support for Qt Virtual Keyboard. This got dropped for better support based on the Wayland input method protocols. An application supporting this protocol is maliit. In this blog post I want to describe how to enable and configure maliit in a Plasma Wayland session.

The support for Qt Virtual Keyboard was added by me as it is quite important to offer first class virtual keyboard support out of the box. Unfortunately the best technical option, maliit, was unavailable back then in most distributions. This made it rather impossible to built on it and instead Qt Virtual Keyboard was used. Given that I am very happy that now maliit support gets added to distributions. When installing maliit please make sure to install the newer maliit-keyboard instead of the older maliit-framework and make sure that it has an up to date git snapshot.

For example in KDE Neon the package is called maliit-keyboard. If your distribution does not yet provide a package, please file a bug report.

To enable maliit in your Wayland session you need to edit your kwinrc configuration file:


kwrite ~/.config/kwinrc

and add the following:


[Wayland]
InputMethod=/usr/share/applications/com.github.maliit.keyboard.desktop

To be sure it gets activated correctly, log out and in again and enable the virtual keyboard in the system tray.

Virtual Keyboard in systray

The keyboard has some default settings. To modify you need to use gsettings. I am not aware of a gui configuration thus it needs to be done from a command line.

E.g. to change the enabled languages from English and Emoji to English, German and Emoji use:


gsettings set org.maliit.keyboard.maliit enabled-languages "['en', 'de', 'emoji']"

And to switch the theme to BreezeDark use:


gsettings set org.maliit.keyboard.maliit theme BreezeDark

Maliit Keyboard in a Plasma Wayland session

On forking

This blog post expresses my personal opinion. Currently I’m not an active KWin developer, thus I think I have an outside view. I’m not contributing due to personal reasons, mostly lack of time. I would love to start contributing again, but in the current pandemic situation I won’t find the time for it. Given that I’m just an armchair developer with some background view of KWin.

As the former maintainer of KWin I’m rather shocked to read that a fellow KWin developer announced a fork. Personally I find this very disappointing and very sad. In my opinion a fork should be the last option if any other option failed. There are very few legitimate reasons and I think a fork always harms both projects due to the split of development efforts and the bad publicity such a fork creates. The announcement renders KWin in a light it doesn’t deserve. There are of course successful forks such as X.org and LibreOffice.org, but those forks were created due to serious issues with the project and had most of the developers on board. I do not see any reason in the current KWin development! For the same reason I also do not like the lowlatency fork. Of course it is an important area where KWin needs improvements, but I would love to see that happen in the KWin repository and not in an outside repository. Working together, bringing the experience together is much better than working on your own.

Personally I am very happy how KWin evolved since I stepped down as the main developer and maintainer. I was afraid that my loss in activity could not be compensated and I am very, very happy to see that development activity in KWin is much higher than it was most of the years before. Looking at the mailing list I see new names and old ones. KWin looks very healthy to me from a developer perspective.

Having read the announcement and the reasoning for the fork, I was left puzzled. What went wrong? When I looked at the mailing lists I never noticed any conflicts. In fact there is even strong agreement on the areas which need work. Such as a reworked compositor pipeline, the KWayland situation, etc. Of course we need to be careful when rewriting, reworking central parts of KWin. One of the main areas in the work for preparing KWin for Wayland was to move the code base in ways allowing to rewrite parts without risking the stability of the whole project. Personally I think this served KWin well. And even if the KWin team does not want a quick rewrite of central parts it’s no reason for a fork. This still can be handled upstream, through branches. One could even release an “experimental” KWin release with central parts reworked. Overall I just don’t get it and hope that what matters is a good KWin.

Also I must say that if I wanted to write a new Wayland compositor I would not fork KWin. KWin started as an X11 window manager and those roots will always be there. In our decision on how to handle the transition to Wayland this was a central aspect as we still have to provide an X11 window manager for those who cannot and do not want to switch. Thus we needed to evolve KWin instead of starting something new. But for a Wayland first compositor I would not start with KWin.

This blog post has comments disabled as I won’t have the time to moderate or answer.

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.