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.
According to 4b686a204250b4416fce79fa55b8a89c5193de38 in kde-workspace,
the support for private colormaps was mainly useful to 8bit displays,
which are relic of time now.
At the moment, the wayland compositor has to handle the case of having
no workspace. This should be unnecessary and it creates a pesky cycling
dependency between Workspace and Compositor.
Given that the Workspace acts more like a container and kwin starts
accepting client connections after starting compositing, it's possible
to create the Workspace earlier and simplify the start() function a bit.
The main motivation behind this change is to encapsulate X11 compositor
implementation to the point that it can be moved from libkwin to
kwin_x11.
There are two options: either get rid of suspend and resume requests, or
add suspend and resume virtual functions in the Compositor. The apps
must definitely not rely on the dbus api, they must use the X11 api.
Compositing suspension api works only on X11 and it's quite obscure,
it's not used by any other KDE component.
So this patch goes for the most simplest option: dropping the requests.
The Shadow no longer owns the texture, so it can be loaded while
compositing is off.
This changes removes the compositing status check to simplify code.
This allows checking if the given override redirect is the composite
overlay window without resorting to platform specific implementation of
Compositor.
Currently, the Workspace is responsible for rerouting
X11Window::blockingCompositingChanged to
X11Compositor::updateClientCompositingBlocking(). It has a few issues:
if the client is initially blocking compositing, it's not going to work
as expected. The second issue is that it creates a coupling between
platform specific compositor implementation and generic Workspace. It's
a blocker for moving X11Compositor to kwin_x11 executable, etc.
implicit sync doesn't work properly with glFlush + KMS and llvmpipe doesn't support
EGL_ANDROID_native_fence_sync either, so we need to wait for rendering to complete
in a blocking fashion.
If somebody else claims the compositing selection, we definitely do not
want to stop compositing. It will also help with encapsulating
X11-specific code and splitting it out in the future.
Config loading is split in two groups: loading compositing config and
loading the rest. They are loaded separately at different times. Some
options are loaded in the Options constructor, some are loaded when compositing
starts, some are loaded when the Workspace is created. It's not easy to
keep track of what loads what and when.
This change simplifies option handling by loading all options in bulk
and decouples Options from OutputBackend and GLPlatform to ensure that
it can safely load options before kwin is fully operational.
Before 885e9acb6e
Application::processStartupEnvironment() returned
QProcessEnvironment::systemEnvironment() which means the current
environment of KWin when this function was called. By setting
InheritFromParent we can replicate this behavior.
This fixes KWin starting processes on X11.
