Skip to content

Split kwin_x11 and kwin_wayland code bases

kwin_x11 and kwin_wayland originate from the same code base at the moment. This allows us to implement effects, and scripts that can work both on Wayland and X11 as long as the platform specific abstractions are generic enough. For the record, that's the main reason why kwin_x11 received new features in a couple of recent plasma releases even though it's in hard maintenance mode.

kwin_x11 and kwin_wayland operate quite differently. They render outputs differently, they handle input differently. So far we've been able to find abstractions (with some hacks) that we could make work on both platforms.

But in order to push kwin_wayland further, we want to change a few things in it that will make sharing code between kwin_x11 and kwin_wayland even more harder. For example, we would like to make kwin_wayland manage graphics buffers manually. The closest thing that we could do on X11 is to use gbm + dri3, but it's not going to work with every vendor, and there's little chance that we will be able to change X11 to make it easier for us to share common abstractions.

As a way to resolve that, I think it's reasonable to split kwin_x11 and kwin_wayland codebases to "unlock" the development of the latter.

Obviously, the main disadvantage is that kwin_x11 will stop receiving new features, and it's important to keep in mind that it's already in maintenance mode. Legacy kwin would still receive bugfixes and important features could still be backported to it as long as they don't depend on wayland-specific apis or features.

Ideally, the split should be done sometime in Plasma 6 time frame. Even though we won't be able to perform the split after a few releases due to the logistics, some minimal preparation steps must be taken in 6.0, for example change how kwin is released (two tarballs for kwin_x11 and kwin_wayland) or give a notice to distro packagers.

Note that it won't solve all our problems caused by needing to maintain X11 and Wayland. It will replace one annoying problem with another.

Option 1

  • Create a branch containing kwin_x11 or a separate repo
  • Rename libkwin, libkwineffects, and kwin_x11's datadir
  • Change KCMs so the ones for kwin_wayland show up only on wayland, and kwin_x11's KCMs only show on x11?

Pros:

  • kwin_wayland and kwin_x11 can co-exist

Cons:

  • Not optimal for extensions
  • Not clear how to handle KCMs for kwin_x11 and kwin_wayland
  • Would need to be careful about keeping dbus interfaces or other kwin <-> plasma apis compatible
  • Maintenance effort to make it work

Option 2

  • Create a branch containing kwin_x11 or a separate repo
  • Rename kwin_wayland and kwin_x11 executables to kwin

Pros:

  • No special handling needed to handle conflicts between kwin_x11 and kwin_wayland

Cons:

  • Potentially not optimal for extensions
  • kwin_wayland and kwin_x11 won't be able to co-exist
  • Would need to be careful about keeping dbus interfaces or other kwin <-> plasma apis compatible
  • Maintenance effort to make it work
Edited by Vlad Zahorodnii