Plasma Phone and KWin

As you are probably aware by now we announced the Plasma Phone project during Akademy this weekend. In this blog post I want to discuss the role of KWin in Plasma Phone.

Plasma Phone uses Wayland as the windowing system with KWin being the Wayland compositor. This is our first product which uses Wayland by default and also the first product which uses KWin as the Wayland compositor. The phone project pushed the Wayland efforts in Plasma a lot and is the only reason why we are able to make Wayland a technological preview with the upcoming Plasma 5.4 release.

The phone project gave KWin/Wayland into the hands of many developers who started to actively use it and to develop with it. This obviously helped to find lots of small and larger issues which then could be fixed. It triggered a stabilization process which reached a stage that I can use a Plasma Wayland session on my notebook with enough confidence that I won’t lose data due to crashes. So thanks to the whole team for pushing the system to the limits.

An area which saw lots of work thanks to the Phone is the interaction between Plasma as the desktop shell and KWin as the Wayland compositor. With Wayland we keep the architecture of having a dedicated shell process which is not inside the compositor. This architecture has served us well in the past and we don’t see a reason why we should change this. It means that KWin can serve as a compositor for other desktop projects, but it also means that Plasma can be used with other compositors. Now unlike X11, Wayland’s protocols are secure by default. This means that Plasma as the desktop shell does not know anything about windows from other processes. To solve this problem we designed a special window management protocol which exports the required information. The protocols are still under development, but we hope that they can be also useful for other projects with a similar architecture (LXQt being an obvious candidate). Of course such protocols should only be used by the “blessed” desktop shell process – this is something we still need to implement and one of the reasons why at the moment Plasma/Wayland is only a technological preview.

Window management is not the only area where the shell process needs to be “blessed”. Also for announcing information about its own windows, we need some more information. We need to know whether a window is a “panel” or the “desktop” view. So on the phone the shell background is just a desktop window, the panel on the bottom is just a normal dock. This allows us to share the general layering code with the X11 implementation of KWin. Even more having the panels marked as panels allows us to properly define the maximized area. And the windows on the phone open maximized by using the “Maximizing” placement strategy in KWin.

Working on the phone project also had some surprises. For example the virtual keyboard just didn’t want to show. It turned out that the reason for this was that Qt(Wayland) only requests the virtual keyboard if it has keyboard focus. Keyboard focus inside KWin is bound to the “active” window. So we had to implement activating Wayland clients. But the initial implementation didn’t really solve it, we still had areas where the keyboard didn’t come up. E.g. on the desktop in the KRunner search field we couldn’t get it to show. The reason was related to the described problem: we did not yet support activating Wayland clients when clicking on them. This got solved by implementing mouse action (and touch action) support inside KWin. So thanks to this change (done for the phone) we can properly switch between Wayland windows on the desktop with a mouse driven setup.

Another nice touch is that KWin requires a running Xwayland server. This gives us support for all “legacy” X11 applications such as Qt 4 or GTK2 on the phone. Just we hit a problem with them: they did not react on touch events. The reason for this is quite simple: touch support is not yet implemented in Xwayland. As a solution we implemented simulating pointer events in case a connected Wayland window does not bind the touch interface. Thus all Wayland and X11 applications can now be used with a touch screen – be it on the phone or on a notebook with a touch screen.

So far I have only spoken about progress made in KWin which is relevant for the desktop. So what about the phone specific adjustments? Well there are hardly any. In the core of KWin there is no phone specific code. The only phone specific code is the hwcomposer backend. This is a plugin used for creating an OpenGL context using libhybris and for reading input events (unfortunately libinput cannot read events on a libhybris enabled system). According to cloc this plugin is just about 800 lines of code and about 200 are just very straight forward mapping of Android key codes to “normal” Linux key codes. For comparison: KWin + kwayland/server currently have about 120,000 lines of code. And even this hwcomposer backend is not phone specific. It could also be used to run a normal KWin/Plasma session on any libhybris enabled device. There is one important difference of the plugin to the rest of KWin which is worth to mention: it is GPLv3+ licensed, while everything else is GPLv2+. The reason for this change is the fact that libhybris is Apache 2 licensed and this license requires a change to GPLv3.

11 Replies to “Plasma Phone and KWin”

  1. I’ve got a question that’s not related to the post, but it’s still Kwin/Plasma Mobile related.

    There’s that one feature in SailfishOS that fixes a terrible flaw in mobile interfaces: when you start selecting text, the whole interface is zoomed. Looks like Kwin could already do exactly that using the zoom plugin, but does Kwin knows when a selection starts or end ?
    The question is, would it be possible to write a kwin script that reproduce that feature ?

  2. “it is GPLv3+ licensed, while everything else is GPLv2+. The reason for this change is the fact that libhybris is Apache 2 licensed and this license requires a change to GPLv3.”

    GPLv2+ already means that the software is also under GPLv3, therefore combining with the Apache License is OK.

    1. Technically you are of course right, but it’s not explicit. I prefer to make it explicit that the code in question is no longer GPLv2.

  3. Plasma phone is really an impressive achievement, I am not sure that the mainstream tech journalists really appreciate it.

    I’m looking forward to having x86 builds I can try on my tablet.

  4. Hello Martin, are those c++ applications, compiled for ARM, or are they running on top of the JVM and / or the whole android stack? (Forgive my illiteracy regarding android, I only know so much yet.) I haven’t seen a clear answer yet in the KDE announcements on the topic. Thank you!

    1. Well, there is nothing android about this: it’s based on Mer, which is a Linux distribution designed for mobile devices.

      It’s closer to MeeGo (the last OS Nokia used before the switch to WPM) than it is to Android, though, as SailfishOS already proved, it’s perfectly possible to run a pretty fully-featured Android environment on top of Mer.

      It seems the Kubuntu team also realesed images for Plasma Mobile, so these might be based on Ubuntu instead.

      You can run this on a Nexus 5 just like you can run SailfishOS on it, or merely other roms of Android. It’s a multi-boot, there’s no need to keep the Android basis.

      1. Actually we do not yet have images on top of Mer, our reference distribution is currently Kubuntu.

    2. We have a pretty normal GNU/Linux stack, so it’s just normal C++ applications compiled for ARM.

  5. Very nice work on the whole wayland/kwin front 🙂 Keep up the amazing work 🙂 Looking forward to running a plasma/wayland session (hopefully) with systemd user units soon 🙂

Comments are closed.