...and use PATH_VARS to make the config file work with absolute paths.
Two reasons to do this:
- DBUS_INTERFACES_INSTALL_DIR is marked deprecated
- Not hard-coding the packackage prefix is helpful on a multiarch
layout where the prefix is /usr/${host} but arch-independent files
should still be installed to /usr/share (i.e a level below the
prefix).
REVIEW: 125843
We no longer need to have the event dispatcher created before starting
the QApplication, thus we can leave it to the QPA plugin to creat it.
Also we don't need to implement our own dispatcher any more but can
use one from Qt5PlatformSupport as we link it anyways. The special
need for dispatching the WaylandServer is no longer needed as we can
explicitly dispatch it from the QPA plugin if needed.
This introduces an own QPA plugin for KWin. QtWayland's plugin is not
a good solution for KWin as QtWayland is meant for Wayland clients and
not for a Wayland server. Given that it makes more sense to have a very
minimal QPA plugin which supports the use cases we actually have.
With our own QPA plugin we should be able to improve the following
areas:
* no need to create Wayland server before QApplication
* Qt::BypassWindowManagerHint can be supported
* no workaround for creating OpenGL context in main thread
* sharing OpenGL context with Qt
* OpenGL context for Qt on libhybris backend
The plugin supports so far the following features:
* creating a QPlatformWindow using KWayland::Client (ShellSurface)
* creating a QPlatformBackingStore using a ShmPool
* creating a QPlatformOpenGLContext with Wayland::EGL
* or creating a QPlatformOpenGLContext which shares with KWin's scene
* creating a QPlatformScreen for each KWayland::Client::Output
* QPlatformNativeInterface compatible to QtWayland
Let's rather not build the plugin if we don't have the dependency
then building it without OpenGL support. Simplifies the code a bit
and makes the backend overall more useful and goes along with e.g.
the Wayland one which has EGL also as a hard dependency for the
plugin.
REVIEW: 124697
The build option wasn't used for 5.x at all and in this way doesn't make
any sense nowadays. We want to have a converged desktop which also means
that the window manager should be able to switch to a different form
factor with a full feature set (plug in external screen to smartphone and
it should be full desktop). A trimmed down KWin with compiled out
functionality cannot do that. Also the need for trimmed down KWin becomes
less and less important given the improved hardware we target nowadays.
This change got triggered by the announcement to close down the Plasma
Active mailinglist [1], which shows that having a build option called
Plasma Active is no longer needed.
[1] http://permalink.gmane.org/gmane.comp.kde.devel.active/4343
REVIEW: 124694
It doesn't make much sense any more as we do no longer link EGL since the
switch to epoxy. And epoxy pulls it in at runtime if needed.
Even more on Wayland it's just plain stupid to have EGL disabled. So
removing the option just simplifies our code base without any
disadvantages.
REVIEW: 124695
The problem with KToolInvocation is that it creates a dead lock on
Wayland in case kdeinit is not already running. It starts kdeinit
and does a QProcess::waitForFinished and our kdeinit needs to interact
with the wayland server. So dead lock.
As KRun also calls into the dangerous code path it's no option which
leaves us with QProcess to start the processes.
A nice side-effect is that we no don't need to link KF5::Service any
more from kwin_core. Now once Plasma and Notification don't use it
any more, it will be gone completely.
kdeinit_executable doesn't make sense in the case of kwin_wayland as
start_kdeinit_wrapper will be executed after kwin_wayland thus the
framework doesn't work.
The KGlobalAccelD which gets created by KWin needs a plugin for the
platform specific parts. This change introduces such a plugin. It's
linked against kwin so that it can integrate with the core.
On enable the plugin registers itself in the InputRedirection and
GlobalShortcutsManager checks the plugin whether a shortcut got
triggered.
As the loading of the plugin must happen after InputRedirection is
fully created a dedicated init method is added to InputRedirection.
REVIEW: 124187
We need XCB 1.10 for sync to work. Sync was optional with a version check
to make it work on build.kde.org. The CI system supports XCB 1.10 now, so
it's better to have it as a mandatory requirement.
KWin used the wrong event dispatcher: QEventDispatcherUNIX insted of
QUnixEventDispatcherQPA. This caused QWindow related events never to
be send to their destination. Which is one of the reasons why KWin's
own windows are not shown at all.
As we cannot easily use QUnixEventDispatcherQPA we do the same as
that class. Inherit from QEventDispatcherUNIX and call into
QWindowSystemInterface::sendWindowSystemEvents.
The idea for this base class is to provide access to all elements which
make up a managed "Client" being it X11 or Wayland. They share a lot,
like they have a caption, they can be minimized, etc. etc.
Of course it would have also been possible to derive a new class from
Client, but that looks like the more difficult task as Client is very
X11 specific.
So far only a very small interface is extracted with pure-virtual
methods. This is going to change by moving the functionality up into
the AbstractClient.
The interface extracted so far is inspired by the usage of FocusChain
and users of FocusChain.
The ShellClient is a Toplevel subclass for a
KWayland::Server::ShellSurfaceInterface. It gets created when a new
ShellSurfaceInterface is created and destoryed when it gets unmapped.
So far the usage is still rather limited. The ShellClient is opened
at position (0/0). While it's possible to pass pointer events to it,
it's not yet possible to activate it, so no keyboard focus.
This backend interacts with libhybris to create a hwcomposer which is
used for creating the egl context and surface. The initial version of
this backend is based on test_hwcomposer.cpp provided by libhybris.
Please note that using the hwcomposer backend requires a newer libepoxy,
the latest stable release is not able to bring up OpenGLES, so one needs
a master build of libepoxy.
Notes on licensing:
libhybris is Apache 2.0 licensed, which is not compatile with GPLv2.
But it is compatible with GPLv3. Thus the source files in the hwcomposer
backend are licensed GPLv3+ and not GPLv2+ as the rest of KWin. If one
uses KWin without the hwcomposer backend (which is obviously the default)
the licence doesn't change. But if the hwcomposer backend is used the
overall license of KWin changes to GPLv3+.
Each of the backends becomes a plugin. This allows kwin_wayland to load
the requested plugin and kwin itself doesn't need to link all the
libraries needed. E.g. libdrm is no longer linked if running kwin_x11.
Also this allows to create backends for the non-standard EGL platforms
(examples could be raspberrypi or Android devices).
The aim is to be able to create a plugin for each of the backends.
The following directories are created:
* backends/drm
* backends/fbdev
* backends/wayland
* backends/x11
Uses EGL_MESA_platform_gbm to get an EglDisplay from a gbm_device.
The DrmBackend can provide a DrmBuffer for a gbm_surface and present
it.
Unfortunately buffer age seems to be slightly broken and we still have
artefacts.
Introduces a new (optional) dependency: libdrm.
The DrmBackend currently supports finding the first connected output.
It can create shared memory buffers which are used by SceneQPainter to
do double buffered rendering.
There is still lots to do, the following things are not yet working:
* multiple outputs
* page flip
* OpenGL (through gbm)
* restoring mode setting to start value
A new Singleton VirtualTerminal is added. It interacts with Logind to
get the VTNr to take over. To get the signal to release and acquire the
VT we use a signalfd with a QSocketNotifier to monitor for signals. The
used signals must be blocked for all threads prior to startup otherwise
they are delivered to secondary threads causing issues.
Adapt to API changes introduced by b62e8888cd39301e00ad98dfe791fa66676408fb.
It adds DecoratedClient::color(group, role) for getting colors that are
not included in QPalette. Breeze used to read these colors from
kdeglobals, breaking per window color schemes. KWin now handles reading
these colors along with QPalette loading with DecorationPalette.
REVIEW: 122883
We released three versions with it being disabled and it doesn't look
like it will come back any time soon. Also the build was broken at least
since the repo splitting due to incorrect path to dbus xml.
In addition the connection to decorations got dropped already with the
change to kdecoration2. Which means it anyway needs large adjustements
to get the code working again.
Overall it doesn't look like it makes lots of sense to keep the code
around for someone working on it in future. If that happens this change
can be reverted.
