Skip to content

Split X11 and Wayland specific compositor initialization code paths

With the current vision for how output backends work, the compositor should take up more responsibilities. There are a few good reasons: some things just don't make sense to be in backends, to allow sharing code across backends easier, etc. On the other hand, we have X11, with its own ways of doing things which are not always compatible with what we want to do on Wayland.

The goal of this patch is to start splitting the compositor into platform specific counterparts, with potentially moving X11 compositing in kwin_x11. The main benefit of this is that we will be able to push forward with wayland things more freely. Ideally it would be great if we could make kwin_x11 have its own low level compositing code paths that are nicely encapsulated in that executable and don't leak into libkwin abstractions.

The biggest drawback of this approach is that there is going to be some code duplication between x11 and wayland compositing code paths. But I expect it to be the case only for a short term until we start landing more abstractions in kwin_wayland, e.g. render devices, proper output layer support, etc.

Merge request reports