September was a busy months in the KDE Wayland world. We have worked hard to bring Plasma closer to a workable system and could cross off some very important milestones.
Transient window positioning
One of the biggest oddities when trying out Plasma on Wayland in the 5.4 release is the fact that menus open at random positions. The reason for this is that KWin applied it’s placing strategy on it and ignored the hints provided by the window. We have now implemented support for the so-called transient windows in KWayland and use the provided placement hint in KWayland. So now all menus open at the correct position. A useable Wayland session is much closer now.
Plasma/KWin specific extensions
Marco did quite some work for the integration of Plasma. KWin provides some Plasma specific extensions like the sliding popups effect, blur and background contrast effect, etc. We have an abstraction through KWindowSystem so that applications do not have to use low level X11 calls directly. Now we extended this abstraction to also Wayland: if the application uses the API it will work on both X11 and Wayland. Granted it will only work with compositors providing the specific protocols, but that is no difference to X11. Also there the compositor needs to implement the custom protocol.
On the client side the protocol is implemented in KWayland and the integration for KWindowSystem is provided through
a plugin provided by the kwayland-integration repository. On KWin side the protocol is also provided in KWayland allowing a very easy to use API. Of course also KWin needed small adjustments in the effects to announce support for the protocol and read the information provided by the windows. Thanks to nice wrapping in KWayland the code is cleaner and simpler than in the X11 case.
Support for multiple X Servers
A change not directly relevant for KWin went into KWindowSystem and will be released with the upcoming 5.15 KDE Frameworks release. KWindowSystem provides an X11 API which looks like it supports multiple X Servers (e.g. one application talking to multiple servers), but that has never worked as it fetched required atoms only on first connection. We refactored the relevant code to no longer have this limitation.
Granted normally applications do not talk to multiple X servers, but there is a mode in KWin which uses just that: a nested kwin_wayland on X11. To explain: it needs to talk to the host X server for rendering two (one server) and it starts it’s own Xwayland server (second server). In case you have ever wondered why the nested kwin_wayland window released with Plasma 5.4 neither has a window icon nor a window title: that’s the reason. We couldn’t use Qt’s abstraction (wrong QPA plugin) and also not KWindowSystem as we needed to make sure the atoms get resolved for the Xwayland server. Now with this restriction removed the window has an icon and a title. Even more I added a “grab input mode” as one might know from virtual machines. While it’s easy to implement I didn’t want to implement it without having a way to tell the user what happened and what the current grab state is.
Preparing KWin for the cloud
The most exiting new feature in my opinion was born last Friday based on frustrations about testing KWin Wayland. Last week Marco and I spent quite some time investigating a few regressions (as it turned out due to adding transient window support). The way to test it was just uncomfortable. We had a test case but it meant starting KWin, waiting till it’s started, start the test application, perform some clicks and interpret whether it worked. Once we fixed that issue I started to look at a crash and the process was similar annoying. What I wanted was a way to automate the test condition, that is an autotest which we could even run in our CI system.
So on Friday I decided to dedicate my development time on a virtual framebuffer backend.This backend (to start use
kwin_wayland --xwayland --virtual) doesn’t render to any device, but only “simulates” rendering by using a QImage which then isn’t used at all. Well not completely true: there is an environment variable to force the backend to store each rendered frame into a temporary directory.
Why is such a virtual backend so exiting? Well it means we can run KWin anywhere. We are not bound to any hardware restrictions like screen attached or screen resolution. With other words we can run it on servers – in the cloud. The first such instance runs on our CI servers in the form of an automated integration test. And in future there will be much more such tests.
But that is not only interesting for KWin to have it’s autotests, it’s also interesting for all other projects of the workspace as we have now a virtual Wayland server which is functional identical to the one we use. We also have a better virtual X server now as we have Xwayland instead of Xvfb (e.g. support for XRandR extension).
Once I had it implemented ideas came to me for improving our CI system: we could use it for something like OpenQA (or integrate the existing tool) and start a complete Plasma session and screenshot various points (if that sounds like an exiting project: please contact me, also if you want to do that as a Season of KDE project ).
Or integrate a remote rendering solution (e.g. VNC, rdesktop, spice, html5) and run a complete session through the web. That could be a very interesting feature for designers, translators, supporters and many other non-developers. Get the latest state of the code directly tested. We have things like Kubuntu CI which make it easy to test in a virtual machine, but wouldn’t it be even more awesome to just run the latest build of the CI system in the browser?
With the help of this virtual backend we are now able to start a “complete” KWin in the autotests. This allows us to very precisely test whether a specif feature works as expected. Unit tests are great, but sometimes one wants to test the complete integration and that’s now possible.
The first problem addressed with this new possibility was a bug noticed while writing this blog post. I used Kate on Wayland and the tooltips got keyboard focus. So now we have an autotest which ensures this case works.
19 Replies to “September update for Plasma’s Wayland porting”
Now I’m just waiting for a WebGL compositor which allows me to run kwin/Plasma in a browser, served by “the cloud”. ?
Thanks a lot for your hard work! Can’t wait to get some free time on my hands again to play with all this and break it in every possible way ?
Does this mean we could eventually have a persistent graphical session in a cloud node, without having to provide any sort of virtual graphical interface within the virtual environment?
sorry, I do not completely understand your question
I think he means a screen-like session that you can start on a remote machine (“the cloud”) and connect to/disconnect from at will.
Yes, a graphical version of screen/tmux. But instead of having a virtual graphics hardware interface which gets scraped by VNC/Spice/other, you don’t have a virtual graphics device at all. What I’m wondering is if it’s possible for the QImage buffer to exist on the connecting client, so that drawing instructions are sent to the remote QImage to be drawn on the client.
No, that would be a bad idea. What KWin renders are memory shared images. Not rendering on the server side would require to transmit significant more data.
Why aren’t the EGL backend mentioned?
Because it got implemented after I wrote and published the blog post.
Okay, would love if you made a post about that too.
How about a remote workspace? be great for an office environment.
i.e. have a few local workspaces for your day to day and a remote workspace for work related stuff…
Yeah that’s a possible use case, but needs more work.
I wonder how feasible it’d be for KWin to implement a “seamless” mode… In Wayland, at least, the isolation between clients would seem to make that considerably easier than X “Everyone can access global coordinates” 11.
Not sure how that works out with XWayland, but it might be _very_ neat for some variety of terminal-server/rootless-nested case.
I don’t really see the usecase for that.
Well, in combination with any kind of remote access (especially RDP), it’d basically be capable of replacing xpra.
In addition, for the use case of remote work, “seamless mode” is just generally more ergonomic: You can mix remote windows with local ones, rather than needing to switch between environments wholesale.
ah now I understand. Hmm that will be difficult. My assumption for remote is that we will send the full image and not the individual windows. Seamless mode is something which I think belongs into the toolkits (e.g. a way in Qt to render to another system).
another thing to consider is a remote sessions with multi monitor setup.
When i connect from mac macbook running osx to windows machine (using RDP) then the screen resolution of remote machine is changed to meet resolution of my local display, and if i have a second monitor connected to my local macbook then the session expands to both monitors. i like this behaviour.
on the other hand when i connect to osx machine (using Screen sharing.app) the resolution of remote machine remains the same, and i’m forced to use scrolling (i have 24” on a remote machine and 11′ on local) or change resolution manually (and there is no exactly my wide-screen resolution in the list!) which is inconvenient.
also note the way i can switch between local and remote view: when connecting to windows i can use cmd+tab to switch away from remote view. when connecting to osx i can use ctrl+left arrow
“Or integrate a remote rendering solution (e.g. VNC, rdesktop, spice, html5) and run a complete session through the web.”
A) Do you want to test “Linux” ?
B) Yeah, but…
A) Just click here: KLICK
A & B) 😀
This might be revolutionary like the live mode, imho. 🙂
Comments are closed.