Last week I had been at the 2014 X.Org Developer’s Conference in Bordeaux, France. After Nuremberg two years ago this was my second XDC and I am very glad that I was able to attend and want to thank KDE e.V. for sponsorship. With the X.Org windowing systems (X11 and Wayland) being at the heart of KWin it is good to get an update on the latest development efforts.
Especially the talks about Wayland related topics were quite important. It was interesting to see what the Tizen developers are working on with their IVI-Shell and the discussions around the talk highlighted the need for a careful put out standardization process for the Wayland shell interfaces: if the interface does not contain enough functionality, multiple incompatible interfaces could be the result making it difficult for applications to interact with the system. On the other hand if the interfaces are too broad it will result in compositors not being able to completely implement the interface resulting again in compatability issues.
More directly touching our development were the talks concerning input handling with libinput. I already have some code prepared and expect that KWin/Wayland 5.2 will come with libinput support (more about that in a future blog post when the work is ready). The talks also showed that I need to reach out to the Krita community to get support for tablet devices. I don’t have access to such a device and even if, I would not know or understand the needs for these kind of input devices. There I will need the expertise of developers using tablet devices and I hope to find this within the Krita community.
KWin/Wayland 5.1 gained support for the fullscreen shell interface. My idea when adding this was to not have to implement DRM support in KWin, but (for the time being) leverage Weston. This simplifies development and allows us to move forward on a higher speed. Jason Ekstrand’s talk showed that the fullscreen shell provides more interesting aspects than our use case. The shell can also be used for use cases such as screen sharing: a compositor renders in addition to a fullscreen shell provided by a different compositor which can use it to e.g. capture a video stream or forward an rdp session. Very interesting and quite useful that we already support it and won’t have to add additional support for rdp into each compositor.
Last but not least I want to highlight Steve Dodier-Lazaro and Martin Peres’s talk about security in a Wayland world. They presented a solution for privileged clients which is very important for our development in the Plasma world: there will be interfaces between Plasma and KWin and nobody except Plasma should be allowed to bind to them. The library presented in this talk will solve this problem and many more. Even more the talk touched various interesting security related topics which I had never thought about in that way. For example setting a window fullscreen provides a security risk: it could fake a lock screen interface tricking the user into entering the password. On X11 the Window Manager/Compositor is unable to mitigate this risk. But on Wayland a compositor can e.g. overlay the window and explicitly ask the user whether the window is allowed to go fullscreen – compare to what browsers already do today. I’ll reach out to the VDG to come up with a good solution.
More interesting is the question on how we can trust password dialogs. This is something I already spent some thoughts about in the past. The problem right now is that a malicious application can easily trick the user into entering the password by faking a system dialog (e.g. polkit authentication or kwallet dialog). We need to find a way to show to the user that this is a trusted dialog and that the password is entered for a trusted application. A difficult task. There are many ways we can make the dialog in a way that nobody would be able to fake it: color the decoration, wobble it, put it into the Plasma’s notification area, but none of them are obvious to a user that no other process can fake it. As explained in the talk it needs an out-of-band communication channel to inform the user that this dialog is trusted. An idea which came to my mind is using KDE Connect to send a token to the connected smartphone to indicate that the dialog is secure.
Unfortunately the state of KWin/Wayland has not processed enough compared to Akademy that I could have done a talk about it. After all it was just a few weeks. So instead I decided to give a talk about what we mostly did last year: port KWin to XCB.