Last week I merged in a few important changes for the upcoming KWin 5.3 release. The rootless Xwayland support is integrated, which means we are a huge step closer to managing Wayland clients. Rendering, input and cursor is already using the Wayland code paths and will be shared with proper Wayland clients. I have already started working on code for that and have it working quite nicely already but decided to delay the integration for Plasma 5.4.
This means that kwin_wayland starts a Wayland server, but except Xwayland there is no application which can properly connect to it. Nevertheless it’s an important step and allows to also test the code in a better way.
In addition I worked on a better support for nesting compositors. So far one had to start Weston in order to test kwin_wayland. This is of course not optimal as it makes the development setup more difficult than it has to be. So last week I looked into developing a new backend which can use an X11 window to render to. This is comparable to Weston which can be used nested on X11. The backend is relatively straight forward: it can render to the created window using either the OpenGL or QPainter compositor, accepts input events and delegates them and passes the cursor from Wayland windows to the X11 window. The tricky part is that we cannot use any of our X11 specific libraries to create the window: we don’t use the xcb QPA, so no support from Qt and we cannot use KWindowSystem as it only allows one xcb_connection and that’s already needed for the Xwayland window manager. So I had to do things myself and as I consider this just a development feature it’s probably the worst X11 client in existance 😉 (Long term KWindowSystem should be changed to support multiple connections, would be very useful for unit tests).
The new backend triggered a small refactoring which makes it easier to implement further backends like e.g. a plain framebuffer or a drm/kms. As a small reminder: there’s an open GSoC idea for implementing the drm/kms backend and application period is to close soon.
Anyway with the nested KWin it’s now possible to create a kwin_wayland instance on the X Server using kwin_x11 and on the kwin_wayland one can create yet another kwin_wayland so that we have a KWinception:
 |
| Aus 2015-03-19 |
To start such a nested compositor use:
kwin_wayland --windowed --xwayland
Please watch the debug output for:
X-Server started on display :1
This tells the id of the created X Server (normally the next free id) and allows to start an application on the nested KWin:
DISPLAY=:1 kwrite
KWin_Wayland picks the windowing system depending on the environment variables which are defined. For DISPLAY it uses X11, for WAYLAND_DISPLAY it uses Wayland. If both are defined Wayland is preferred. If one wants to specify explicitly one can use the command line arguments –x11-display or –wayland-display. E.g.
kwin_wayland --windowed --xwayland --x11-display=:0
For X11 there are also the options –width and –height to specify an initial size (default is currently 1024×768). On Wayland these options are currently not available, the window always opens fullscreen.
Please remember that this is pretty new code and the support is still incomplete. Feature might be missing or broken. This is at the current state expected and because of that we do not yet accept bug reports. If you find a bug which you think should be fixed, please open an editor 😉
Running an X server always, rootless or otherwise, is not the greatest idea in the world as far as security goes. How will the nearest future stable KDE release handle this? Will applications prefer X even though there is a Wayland compositor running and they have support for it (because the Wayland paths are not stable)? Will there be an option to explicitly disable the built in Xwayland server from running at all?
KWin still requires an X server. Thus there cannot be an option to disable.
Does the composite can be disabled in this Kwin ? In KDE4, disabling composite means no lateral windows borders, ugly letters on windows borders, and some others. There is other bug when disabling the popup context /task bar popup that clicking on the clock the calendar is not opened..
No the compositor cannot be disabled in kwin_wayland.
Hi Martin, the funny thing about the ability to turn off the compositor in KWin is that I have used it many times to fix issues by basically restarting the compositor, and it works… I’ve done this on mine and other’s computers. For example there is a stupid problem with my exact model of Nvidia graphics card and driver that causes it to completely corrupt all the pixel/vertex buffers etc after waking it up from sleep. I simply press Shift+Alt+F12 twice and it is back to normal again haha
Maybe if there was a shortcut just for restarting the compositor…
Also, another reason I turn it off, which I guess probably isn’t really your problem, is that when I fullscreen video players like VLC or Youtube in Chrome or Firefox their play-back is a bit jerky, until I turn off compositing and everything is fixed.
Restarting is dangerous – if we cannot get back to the Compositor, you end with a broken session.
Right, you mean it is dangerous unlike now because there isn’t the uncomposited version to fall back to… maybe if it would reload the buffers when it wakes up ._.
Sorry, I won’t bother you with my niche problems anymore
You might want to check if you are using EGL backend. as EGL don’t have Texture From Pixmap extension, and thus expensive round tripe of window contents happens.
On EGL (X11) we use EGL_KHR_image and EGL_KHR_image_pixmap – if they are not available we bail out.
I just want to say. Thank you for your continued development with making Kwin/KDE fully wayland enabled.
Looking forward to a wayland native future…