Posted on

Evolving 3D desktop effects in Plasma

The latest Plasma release dropped a few desktop effects: the cube family, CoverSwitch and FlipSwitch. All of those effects were written back in 2008, the early days of KDE 4.x and the early days of desktop effects in KWin. The effects were implemented by me and when Vlad asked about removing them I saw the need for this and supported this step for technical reasons. With this blog post I want to share a little bit of why it was needed to remove them and why this means that they can come back in better ways than ever before.

State of CPU in 2008

To really understand this we need to time travel back to 2008 and the years before when desktop effects were introduced. This can help to understand how the hardware architecture changed and how that influenced design decisions in the effects API which are nowadays problematic. First of all CPUs. The Intel Core 2 Duo architecture was launched in 2006 as the brand new thing which had multiple (namely 2) cores which slowly replaced the NetBurst architecture which dominated Desktop computing for the beginning of that decade.

Also for developers these multi-core systems were a new thing. And that meant lots of software written before was single threaded. Especially KWin at that time was single threaded as it also depended on libraries which were not really thread safe such as the Xlib library and back at that time even OpenGL. Even years later when Qt introduced the threaded rendering in Qt 5 on many Mesa drivers this was disabled due to thread safety issues. Nobody would have thought of having any benefit of a threaded compositing approach back in 2007 with the state of hardware and the available libraries. Thread libraries were of course already available such as QtConcurrent or ThreadWeaver, but not of a useful use in KWin. This means the API written back then did not support ideas like doing rendering on a second thread or even rendering for each screen in a thread.

State of OpenGL in 2008

KWin’s compositing pipeline was written for OpenGL 1.4 which was the only supported version in the Mesa stack. KWin supported shaders written in OpenGL Shading Language which replaced parts of the fixed functionality pipeline in OpenGL 1.4 and emulated the fixed functionality pipeline. This was only supported on the proprietary NVIDIA driver. OpenGL 3 was released in 2008, but it was years till it became available on the Linux desktop (according to Wikipedia in 2012).

Thus the design of the OpenGL compositing scene and desktop effect system was written for the fixed functionality and only with this in mind. While KWin gained support for the programmable pipeline and is the only supported way nowadays the design is still in place and problematic.

State of multi screen support

Multiple screens were not that common back in 2008 and there existed multiple competing technology approaches. There was the old “one X screen per screen” approach with a different DISPLAY variable for every screen. There was Xinerama, with the NVIDIA implementation called TwinView and there was the “new kid on the block” XRandR. Using multiple screens still required hacking the xorg.conf file and then with luck it was working. Especially if you had an NVIDIA card which one needed for good desktop effect performance.

 

From https://xkcd.com/963/

From an X11 perspective there was (and even today) there is not such a thing as multi screen. For the compositor everything is one screen and we have to present all screens at the same time. So much for variable refresh rates (AMD FreeSync introduced in 2015), buffer age extension (implemented in KWin in 2013) and so on. From rendering point of view there was not much difference between rendering one screen or multiple screens. All we had in KWin was an integer variable telling us the count of known screens and the geometries.

State of Alt+Tab

Alt+Tab, which CoverSwitch and FlipSwitch provide, was still a hard coded implementation in QWidget. With the effect system an API was added to suppress the QWidget and use a desktop effect as replacement. This allowed to have an effect (BoxSwitch) which showed thumbnails for the windows. Overall this was rather a break with the other parts of the effects API as the effects are mostly used to influence position and drawing of the windows. With the Alt+Tab API an internal part of KWin was exposed and suppressed. It was it’s own API inside the API.

CoverSwitch and FlipSwitch even took this a step further by introducing 3D elements in the so far 2D world of desktop effects and completely intercepted the rendering. Most effects do not change the order how windows are rendered, but with those effects it was important to render the windows exactly in the order Alt+Tab wants them. So the effect intercepts the normal render calls and renders the windows in another order. To make this worse the CoverSwitch included reflections which meant the windows needed to be rendered twice. And the effects had to combine windows from multiple screens. The cube effect family did even more horrible things.

How Alt+Tab evolved

The biggest change to Alt+Tab happened thanks to QtQuick. While it was reworked before already and was no longer QWidget based, QtQuick allowed to easily define new layouts. The internal Alt+Tab API was one of the first parts to be exposed to QtQuick in KWin. Furthermore we introduced an interesting concept to make it possible to render window thumbnails in the QtQuick scene. This was done by telling the compositor to draw a thumbnail at a specific region of the QtQuick Alt+Tab window. As this was perfectly synced we finally had an easy to use API to make Alt+Tab layouts with all the fancy things only desktop effects could give us. Though we could not put other elements on top of the thumbnails (e.g. a close button) or transform them from within QtQuick. This was the end to the already mentioned BoxSwitch effect and the Alt+Tab mode in PresentWindows. Thus the only remaining effects for Alt+Tab are FlipSwitch and CoverSwitch.

With Qt 5 there was the hope to further improve that. Now also QtQuick used OpenGL for rendering which meant that in theory it would be possible to make our window textures available to QtQuick. Thanks to the work on the compositing engine lately this is now possible and gives even more flexibility to render Alt+Tab and makes it possible to implement FlipSwitch and CoverSwitch with QtQuick. This is really awesome as it means we have much better tools at hand to implement such fancy effects, we don’t have to develop our own toolkit and implement our own transition handling. Instead we can use all the great things like PathView in QtQuick. The C++ desktop effect implementation of CoverSwitch was 1000 lines of code, while the new emerging QtQuick based implementation is just about 200 lines of code.

How the effects evolved

Also the KWin effect system had a transition. We noticed that most effects are actually animations and added a dedicated implementation for it. This implementation is exposed to JavaScript and most of those effects are nowadays written in JavaScript. The effects in C++ are often the odd ones which do too much and use the wrong toolkit for the wrong thing. Such as I said years ago that PresentWindows and DesktopGrid need to be rewritten in QtQuick. The effect system should be for animating, not for developing a user interface. With QtQuick we have a way better toolkit.

Overall huge effects such as the cube family, CoverSwitch and FlipSwitch are standing in the way of evolving the effect system. While we have better tools to implement and maintain them thanks to QtQuick.

Posted on

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
Posted on

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.

Posted on

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.

Posted on

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).

Posted on

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″

Posted on

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.

Posted on

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.

Posted on

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.

Posted on

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.