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.
The AbstractBackend registers itself in the WaylandServer allowing
external users to easily get to the backend and not needing to test
manually which backend is used.
There's quite some overlap and duplicated code. This AbstractEglBackend
tries to merge the two backends a little bit again.
This also introduces an AbstractEglTexture which supports both X11 and
Wayland "pixmaps" so that EglOnXBackend can support Wayland buffers.
Adds optional dependency to X11_XCB and gets used in X11WindowedBackend
to create an XLib Display if dependency is present.
This allows to create an EGL backend for the X11WindowedBackend.
This new backend allows to start a kwin_wayland server nested on an
X-Server by using a normal X11 window as output. This allows testing
kwin_wayland without needing to start another Wayland server first.
The behavior is triggered by using new command line arguments:
--windowed
--x11-display=<:0>
With optional --width and --height arguments.
In this mode the WaylandBackend is not created at all.
So far the backend is not fully integrated yet and only the QPainter
backend supports this mode.
This reorders the startup sequence quite a bit:
1. Create QAbstractEventDispatcher and install it on QCoreApplication
2. Create Application
3. Start Xwayland, use thread to get when its ready
4. Create xcb connection
5. perform startup
For using the wayland QPA it needs a patch in QtWayland which will be
part of Qt 5.4.2, otherwise it blocks.
The WaylandServer is at the moment only used to support starting an
Xwayland. It does not support Wayland clients yet, so don't get
excited.
For Xwayland it's using the trick of creating the Display before the
QApplication is created with manual event dispatching.
Since XCB 1.10 the sync extension is working properly. At the time of
the 5.3 release 1.10 will have been out for ~15 months, enough time
for distros to catch up and should allow us to use it.
As our CI system only supports 1.9 at the moment we cannot hard depend
on the version, instead we use feature info. As soon as our CI system
supports it, we should update the required min version and kick out the
ifdef.
REVIEW: 122377
Straight forward port from XLib based XCursor library to the
xcb variant which is considerably new. The xcb variant only allows
to create xcb_cursor_t for the default theme and size. Which suits
the needs in Cursor quite well, but means it's not a replacement for
the usage in zoom effect.
REVIEW: 122290
Was only used as fallback for older NVIDIA drivers. At the same time
also drop the call to nvidia-settings which was also only used as
a fallback for refresh rate detection.
REVIEW: 122423
libinput 0.8 is incompatible causing the build to fail. As we are in
dependency freeze the only option is to disable the build.
BUG: 342893
FIXED-IN: 5.2.1
A new implementation of the Screens interface is added which uses XRandR
directly instead of relying on QDesktopWidget. The implementation is
provided in a new implementation file screens_xrandr.cpp.
XRandRScreens comes with a unit test. Unfortunately it's rather difficult
to provide a proper unit test against XRandR. Xvfb (which is obviously
used on the CI system) doesn't provide the XRandR extension. Also on a
"normal" developer system one would not want to just execute the test as
the results are not predictable (number of available outputs?) and the
test would mess up the setup resulting in nobody wanting to execute the
test.
As a solution to both problems the unit test starts Xephyr as a nested
X server. This allows to have at least some limited tests against XRandR.
Nevertheless there are a few things which I was not able to test:
* multiple outputs
* no output at all
The nested X Server approach makes the interaction rather complex. Qt
opens it's connection against the main X Server thus QX11Info provides
a wrong connection and also KWin::connection() which is heavily used by
xcbutils and thus all the RandR wrappers have the wrong connection. To
circumvent this problem the test is GUILESS. In case it would call into
any code using QX11Info, it would probably either runtime fail or crash.
REVIEW: 117614
The build option got introduced for Plasma Active back in a time
when we did not properly aim for convergence. In a Plasma 5 world
we want to have only one shell and one window manager which adjust
itself. This means we don't want a differently compiled kwin for
plasma active, but the same one. Thus the build option doesn't
make much sense any more. A KWin for touch interface needs to support
screenedges for the case that mouse is plugged in.
CCBUG: 340960
REVIEW: 121200
Following features are supported:
* finds all plugins
** finds all themes for a theme-engine plugin
* renders previews for the plugin/themes
* loads currently used plugin/theme
* saves selected plugin/theme
* triggers config reload in KWin
Following features are currently not supported:
* Search
* Plugin configuration
* GHNS
* Button configuration
KWIN_HAVE_EGL was set to EGL_FOUND which doesn't make sense as EGL is
marked as a runtime dependency. Instead a new build option KWIN_BUILD_EGL
is added defaulting to ON. If set to OFF neither the X11 nor the Wayland
EGL backend are built.
CCBUG: 340171
As we use epoxy we don't need them any more. KWin compiles, links and
runs just fine without ever trying to find OpenGL or OpenGLES.
BUG: 340170
FIXED-IN: 5.2.0
With libinput we have the problem that we need to have privileges to
open the device files. In order to not need wrappers or suid bits, we
use logind. This means that kwin_wayland has to be the session controler.
A LogindIntegration is added to connect to logind and wrap the dbus
calls. This is based on the logind integration done for ksld in
ksmserver. The LogindIntegration is started by Workspace and the
InputRedirection tries to become the session controller and starts the
libinput integration only after this succeeded.
Libinput is an optional dependency for getting low level input events.
As opening the input devices requires root privs this is rather
pointless in the current state. But there is a small added test app which
can be executed with root privs to demonstrate the functionality. To
properly get input events we need a wrapper like it's used in weston.
So far the following is setup:
* opening devices found by udev
* forwarding keyboard events to InputRedirection
* forwarding pointer button events to InputRedirection
* forwarding pointer axis events to InputRedirection
* signals emitted for pointer motion events
Pointer motion events need some further work as they are provided
as delta events. We need to track that and map them properly.
Also missing are touch events due to me not having a touch screen.
It should be fairly simple to setup the touch events, though.
Also hotplugging of devices is not yet implemented.
Martin Gräßlin