Now it’s in a state where it works good enough to blog about it. So after Akademy I decided to work on it and see whether we can get a plugin working. So we had to disable them by setting the QT_WAYLAND_DISABLE_WINDOWDECORATION environment variable. But in the context of KWin we do not want any decorations. This is a small issue: QtWayland creates window decorations around all Qt windows. One could consider this as a libhybris specific issue, but I wouldn’t say so – interacting with multiple EGL platforms from one process is kind of out of the specification. In the case of Mesa everything works fine, but we noticed that on libhybris the creation of a Wayland context fails if there is already one created for hwcomposer. QtWayland tries to create an OpenGL context using the EGL platform Wayland.
#QT PLATFORM CODE#
Qt(Wayland) doesn’t know which one KWin uses and might not even have code for it. That is normally not a problem but can easily become one in the case of KWin: KWin creates a “low-level” OpenGL context using the specific platform (e.g. QtQuick requires an OpenGL context and if it cannot create one it will abort.
#QT PLATFORM WINDOWS#
So in KWin we needed to remove the hint for all windows on Wayland. That is a valid approach – there is nothing I could say against it. The hint is X11 specific and doesn’t make much sense on other platforms, so the Wayland plugin doesn’t show such windows at all. KWin uses the Qt::BypassWindowManagerHint on all it’s windows because this is needed on X11. Overall I found this aspect way to fragile and consider especially the fact that the server is in the main thread as a problem.
kded, kamd), rendering of Qt internal windows in case the compositor didn’t send the frame rendered yet. eglInitialize, startup of dbus services (e.g. We fixed this one in QtWayland, but the problem was still there: any blocking call from the main gui thread to the Wayland server would freeze KWin. But this happens from the main gui thread, in which also the server lives. The wayland plugin performs a blocking roundtrip to the Wayland server during startup to wait for all outputs to be announced. This added a restriction that we have to monitor the server socket from the main thread. As KWin is the Wayland server the plugin wants to connect to, we needed to make sure that the Wayland server and the event loop are up and running before constructing the QGuiApplication. The wayland plugin is meant for Wayland clients and tries to connect to the Wayland server during the creation of the QGuiApplication. So let’s look at some of the issues which motivated me to write an own QPA plugin. KWin just doesn’t fit the usecase of QtWayland QPA plugin and it would not be a good idea to change QtWayland in a way that it supports KWin as a first-class citizen – it’s just a too special use case. This created some interesting “problems” which we had to workaround in KWin.
QtWayland provides a plugin for Wayland clients, but KWin is not a Wayland client: it is the Wayland server.
For quite some time I had been thinking about migrating away from those and use an own KWin-specific plugin at least for Wayland. In case of KWin we use the “xcb” plugin on X11 and on Wayland we used to use the “wayland” plugin provided by QtWayland. In Qt we have the Platform Abstraction (QPA) which allows to better interact with the used windowing system through a plugin.
0 kommentar(er)
