Posted on

Wayland accelerated at CERN

Last week I attended the KDE sprint at CERN to discuss the next steps in Wayland development with my fellow Plasma developers and our awesome crew of the visual design group.

With the feature freeze just behind us it’s a good time to look at where we stand and what still needs to be done. For me it was a quite exciting sprint as it meant one week of working on Wayland. My notebook is my Wayland test system, so also during the sprint I worked on Wayland. The only exceptions to be on X11 was to investigate problems in Wayland which is still easier from a nested setup on X11 (mostly due to the fact that my notebook has only Qt 5.5 which doesn’t support pressing Ctrl+C in a Konsole). But I was not the only one testing Wayland: my fellow developers did as well and reported interesting bugs I never hit (if you hit a Q_UNREACHABLE something is seriously wrong) due to running a Qt release build. At some point we had the majority of attending Plasma devs running a Plasma Wayland session.

While using a full session one realizes what’s missing in the workflow. As a result we have KRunner working on Wayland now (including a nice improvement for X11) and Yakuake working (with the Ctrl+C exception mentioned above). Some devs also need Ctrl+Alt+Backspace to kill the windowing system in their workflow. So that’s now also implemented – don’t be afraid: it follows the X-server settings and is by default disabled in the keyboard layout.

One problem we noticed is that our possibilities to debug a running Wayland session is rather limited. Especially we are lacking tools like xprop and xwininfo. A window is misplaced, why is that? Currently answering that is still rather tricky. So for the next event cycle I want to improve here to make it very easy for debugging a running KWin instance without needing external tools like xprop and xwininfo. As a start I hacked together a small debug console which can be invoked through DBus:
KWin Debug Console

Of course we did not just hack, but also plan the future. Most importantly we had a session together with the visual design group to explain what new possibilities are there on Wayland. The VDG will hopefully soon come up with some new ideas on how to improve the workflows 🙂 Also we had a good discussion about dynamic window decorations – Ken is going to report about that, so I won’t steal the show on that.

KWin was not just a topic for the Plasma crowd. Also WikiToLearn has a very interesting setup with KWin in the cloud. This is really exiting and looking promising. It might be that some of my crazy ideas might finally get implemented as I now see use cases for KWin streaming textures into a HTML5 web socket.

And of course we saw KWin in the CMS control room 🙂
CMS Control Room

Thanks to CERN for hosting us and making it possible to visit the LHC. Thanks to KDE e.V. for sponsoring the sprint. WikiToLearn and especially Riccardo for organizing the sprint.

If you want to support our sprints in future consider becoming a supportive member.

Posted on

February KWin/Wayland update: all about input

I haven’t blogged for quite some time about the progress on KWin/Wayland and had a few people requesting an update. As we are now approaching a feature freeze and I have most of the things I wanted to do for Plasma 5.6 done, it’s time to blog again. I use this also as a public service announcement: thanks to Let’s Encrypt my blog is also available through an encrypted connection.

Last month my development focus was on the input handling in KWin. That is the part between input events enter through libinput and are sent to the Wayland client. There are many things the compositor needs to consider for input events: updating the window which has focus, ensuring while the screen is locked to not pass events to normal windows, handling focus follows mouse, etc. etc. On X11 KWin has already code for most of these things, but the code is quite dependent on X11, so it needed to be partially adjusted and partially rewritten.

The code we had in KWin/Wayland for input handling so far already showed it’s age. It was written and designed before KWin really became a Wayland compositor, from the time when KWin could render X11 windows to another Wayland compositor. So it mostly cared about sending the events to the X server. Everything else continued to work as the X11 event handling was still in place.

So the first task was to untangle the code so that it’s easier to extend and at the same time guarantee that it won’t break. As we are now able to start KWin/Wayland on a virtual framebuffer, we can run it during our auto tests. This was a rather important corner stone for reworking the input as it allowed to write test cases for everything KWin does.

With that done existing features from X11 could be ported to Wayland including mouse actions (what to do when clicking inactive window), unrestricted move/resize with alt+(left/right) mouse button, focus follows mouse and auto raise, etc. All those features are now also under test coverage and as the code is mostly shared with the X11 implementation we now also have test coverage for these features on X11. That’s quite an improvement for our X11 implementation thanks to Wayland.

Another area of work is keyboard layout handling. So far KWin defaulted to use the us layout without any possibility to change. That was a huge drawback for my own usage as I couldn’t even write my name. Like with many other input related areas I’m not really familiar with the technology, so I had to look into it in more detail. I am very pleased with xkbcommon, it was really easy to get this working and hooked up properly in KWin. The result is that KWin/Wayland now fully supports keyboard layout switches and also the integration with Plasma’s keyboard layout configuration module. I was rather pleased to see that the configuration module was hardly X11 dependent and just works on Wayland. With KWin listening to the correct DBus signal it allows to reconfigure layouts. But there is still work in that area. So far I have not added support for compose keys, the systemtray applet for switching layouts is not ported yet, accessibility features are still lacking. If you are interested in these areas some help is appreciated.

In case you tried Plasma 5.5 on Wayland you might have noticed that the cursor was sometimes rather incorrect. Not anymore in Plasma 5.6. The cursor image handling got also redesigned and put under test coverage (unfortunately our CI system doesn’t like them yet, locally they pass). But having KWin handle cursors correctly is unfortunately not sufficient to have proper cursor images. Cursor images are set by the clients and if they set an incorrect cursor image, KWin cannot do anything about it. For example QtWayland doesn’t support animated cursors and doesn’t support custom cursors. With the feature freeze for Plasma 5.6 behind us I’m also looking into these issues now. Overall client bugs make it really hard to test features as you never know whether it’s a bug in your application or in the client (or XWayland). The fact that GTK+ and wayland-demos just crash, because KWin doesn’t support xdg-shell yet, doesn’t make it easier to test new features.

The last input area I looked at and landed just in time for feature freeze is drag’n’drop. The implementation is not yet using the updated protocol from Wayland 1.10 as we had already passed dependency freeze when I started to implement it.

Overall the improved input handling gives us a nice feature set for Plasma 5.6 on Wayland. On a single screen setup it’s quite useable already. Of course there are bugs and those need you. Please give it a try and report all bugs you see.

In the area of input there is also more work to be done. We need support for graphic tablets. If you are interested in it: I’m willing to mentor a GSoC project about it. We have a few GSoC ideas for Wayland, check them out!

So what’s next in Wayland world? Till the release of Plasma 5.6 I want to concentrate on bug fixes to make the experience better. Than there’s xdg-shell quite high on my priority list and making multi-screen work correctly (that’s blocking me to switch my main system, the single screen notebook is mostly used on Wayland nowadays).