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).
13 Replies to “February KWin/Wayland update: all about input”
Does primary selection (a.k.a. primary clipboard) works in KWin on Wayland?
You mean middle-click paste? No that’s not yet implemented.
Will there be any way to disable middle-click paste when it’s implemented? I’m a TrackPoint user, and with it middle button is used extensively for scrolling around. The problem is that sometimes that gets whatever is in the clipboard pasted in unintended places. Remapping middle button to something else is not a solution since it also disables things like closing a tab in a browser with middle click, opening a link in a background tab, closing an application window (in Smooth Tasks task bar widget), etc.
if not a secret what are you using on your note book with wayland?
Sorry I don’t get the question.
what hardware do you use? cpu, gpu, etc..
lenovo thinkpad x220
Ah, another thing I remember: is there an analog to Coordinate Transformation Matrix? It is mostly used for touch-pad calibration, but there are also other use-cases, i.e. for X11 it was the only way to emulate increased mouse sensitivity (i.e. not the «acceleration» but rather a speed, the «acceleration» have bad impact for gaming).
are you implementing kwin with vblank signalling in mind?
It is used w/ embedded DisplayPort connections in notebooks/AiO devices for power saving by dynamically lowering the display’s refresh rate for static content. It is also used for Adaptive Sync, a rather new VESA standard utilised by AMD (and ‘soon’ by Intel, too) to prevent tearing but avoid the downsides of v-sync.
Adaptive-Sync/eDP LCD panels could be clocked on demand from rates around ~10 Hz up to 144 Hz (depending on the panel).
How does a tear-free KDE desktop w/ power-saving and latency improvements sound?
KWin only updates if something is to be shown. If there are no changes, KWin won’t trigger a repaint and not present anything. Thus the architecture should support everything going down to 0 Hz.
Thanks for the answer. That also applies on wayland?
So this stuff I was talking about would have to be implemented in drm?
yeah it also applies to Wayland and to our DRM platform abstraction. If we don’t render we don’t trigger a page flip. I would assume that the driver handles this then automatically.
Comments are closed.