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.
The wayland protocols need the .c files compiled in gnu90 mode.
All known compilers used for kwin support the -std= flag, so setting it
unconditionally should be fine
REVIEW: 120231
So far this new module contains:
* Display
* OutputInterface
Display manages the server socket and server event loop. In general it's
the entry point to any part of the server.
OutputInterface is the abstraction for the wl_output interface on server
side. An OutputInterface is created through the Display.
The auto tests for ConnectionThread and Output are adjusted to use the
internal server instead of starting Weston. Especially the Output test
could be extended to test much more as we have absolute control over
the server now.
Moved from wayland_backend.[h|cpp] to buffer.[h|cpp] and
shm_pool.[h|cpp]. Buffer is slightly adjusted to have the ShmPool
passed in as a ctor argument and the ctor is private and friended with
ShmPool, so that it can only be constructed from ShmPool.
A Surface class is split out which holds a wl_surface and supports
attaching a buffer, setting the damage and emitting a signal when the
frame callback got called.
It doesn't come with a unit test yet as it first needs the ShmPool
and Buffer properly split out to easily set it up.
New classes Shell and ShellSurface are created. Both are in shell.[h|cpp]
to indicate their close relationship with the Shell having to create the
ShellSurface.
WaylandBackend is adjusted to hold a Shell* and ShellSurface* instead of
the lower level structs. This also required adjustements to the creation
of the Backend as it now doesn't set a default size any more. Thus the
backendReady signal may not be emitted before the initial configure
event arrived. This also makes it easier to support either the fullscreen
shell or wl_shell at the same time.
Of course a unit test is added for the two new classes. This needs to
be extended once we have more control over the mock Wayland server.
At the same time adding an autotest for the Output, moving the listener
into the Output class and providing enums for Subpixel and Transform.
KWin now requires wl_ouput interface version 2 as that allows us to emit
the changed signal in a better way.
The unit test is not yet capable of testing everything, we need a mock
Wayland server which is more flexible.
The FullscreenShell is a Wayland protocol provided by Weston to have
exactly one surface per output. This is exactly what KWin needs. So
in case the Wayland server we connect to provides the FullscreenShell
we prefer it over the normal Shell and mapping our surface as fullscreen.
The protocol is not yet part of wayland-client library, so the header
and source file needs to be generated. This is done during the build
process using the external tool wayland-scanner. The protocol
description is copied from the Westion 1.5 sources.
REVIEW: 119839
The Wayland::Registry class wraps wl_registry handling. It keeps track
of the interfaces in the registry and emits signals whenever a known
interface gets announced or removed. So far it only tracks the interfaces
which are used and needed by KWin.
The Wayland event queue is moved into a dedicated thread and a
new class is created for just creating the connection and listening
for events. The WaylandBackend creates the thread and uses an event
queue for the main thread.
REVIEW: 119761
All of kwin except the main function goes into a new (private) library
called kwin. Two new kdeinit_executables are created:
* kwin_x11
* kwin_wayland
Both only use a dedicated main_x11.cpp and main_wayland.cpp with the
main function and a KWin::Application subclass and linking the new
kwin library.
The main idea behind this is to be able to perform more sane sanity
checks. E.g. on Wayland we don't need to first test whether we can
create an X11 connection. Instead we should abort if we cannot connect
to the Wayland display. Also the multi-head checks are not needed on
Wayland, etc. etc. As most of that code is in the main function to
simplify it's better to split.
This will also make it easier to diverge more easily in future. The
Wayland variant can introduce more suited command line arguments for
example. This already started by having the --replace option only
available in X11 variant. The Wayland backend is still a window manager,
but doesn't claim the manager selection.
NOTE: this is not working completely yet, lots of code is still ifdefed
other parts are still broken.
The main difference for the new decoration API is that it is neither
QWidget nor QWindow based. It's just a QObject which processes input
events and has a paint method to render the decoration. This means all
the workarounds for the QWidget interception are removed. Also the paint
redirector is removed. Instead each compositor has now its own renderer
which can be optimized for the specific case. E.g. the OpenGL compositor
renders to a scratch image which gets copied into the combined texture,
the XRender compositor copies into the XPixmaps.
Input events are also changed. The events are composed into QMouseEvents
and passed through the decoration, which might accept them. If they are
not accpted we assume that it's a press on the decoration area allowing
us to resize/move the window. Input events are not completely working
yet, e.g. wheel events are not yet processed and double click on deco
is not yet working.
Overall KDecoration2 is way more stateful and KWin core needs more
adjustments for it. E.g. borders are allowed to be disabled at any time.
Remove the manually written GL dispatch code, and use libepoxy
to resolve functions.
The only exceptions are GLX_MESA_swap_control, which is not in
the XML API registry, and GL_ARB_robustness/GL_EXT_robustness.
For the latter we want to resolve the functions to the same names
on both GLES and desktop GL, and plug in our own implementations
when the extension is not supported.
This servers two purposes.
1. it makes KWin/5 co-installable with KWin/4 as now binary and
all libraries etc. are renamed or installed to a different
location.
2. In future we need a dedicated X11 and Wayland main function
anyway. Thus it makes most sense to rename to kwin_x11 directly
instead of first renaming to kwin5. The reason why we need to
have dedicated main functions is that kwin needs to check early
whether X11 is working or Wayland is working. Right now the first
thing kwin does is trying to connect to the XServer. This happens
before the QApplication is constructed and before command line
args are processed. On Wayland we won't want to test whether we
can connect to the XServer. As it's too early to check whether we
are starting kwin for X11 or Wayland the most convenient way is to
have dedicated binaries - thus a rename is needed. Just renaming
kwin for wayland is also not a good idea as in future the "main"
kwin will be for wayland not for X11. Another case for the dedicated
binaries is the Application class, which right now first tries to
claim the X11 Window Manager Selection. Again on Wayland even with
XWayland we won't need that. KWin will be the window manager for
XWayland if KWin is the Wayland compositor. There is no need to even
try to support anything else. Most likely it will even be KWin to
start the XWayland server, so we can be sure that there is no other
WM running and thus no need to claim the selection and abort if it
fails.
REVIEW: 118266
ICCCM dependency is a beast due to two different existing versions in
different packages. Thus it cannot be a hard dep without causing problems
for our downstreams.
This change ensures that ICCCM is really considered as an optional dep
and that the version we need is found, if not we mark it as non-found.
ICCCM is only used by one test application which can easily be disabled
and some enum values are used in events.cpp. If ICCCM is not found those
are replaced by defines generated in config-kwin.h.
BUG: 336035
Similar to the already existing DBusInterface wrapper for the
org.kde.KWin interface a new CompositorDBusInterface is introduced for
org.kde.kwin.Compositing.
That way the DBus interface is split from the implementation and DBus
specific methods are no longer required in the Compositor class.
The deprecated DBus methods
* toggleCompositing(bool)
* setCompositing(bool)
are removed.
REVIEW: 118463
When find_package(KF5 CONFIG REQUIRED) is called, any subsequent
find_package(KF5) calls will be marked as required too. So,
find optional frameworks separately to avoid configure failure
if they are missing.
Also add information about the status of the optional packages
to the feature summary.
REVIEW: 117728
New build option KWIN_BUILD_COVERAGE which adds
"-fprofile-arcs -ftest-coverage" to CMAKE_CXX_FLAGS and "-lgcov" to
CMAKE_EXE_LINKER_FLAGS.
REVIEW: 117369
* Ported last qt4_wrap thingy to qt5_wrap thingy
* Include KF5Init (needed for kdeinit_executable
* Optionally include KF5DocTools and bind the docs subdirectory to it
* Include GenerateExportHeaders
Effect loading gets split by the kind of effects KWin supports:
* Built-In Effects
* Scripted Effects
* Binary Plugin Effects
For this a new AbstractEffectLoader is added which will have several
sub-classes:
* BuiltInEffectLoader
* ScriptedEffectLoader
* PluginEffectLoader
* EffectLoader
The EffectLoader will be what the EffectsHandlerImpl is using and it just
delegates to the three other types of loaders. Thus the handler doesn't
need to care about the different kinds of effects. The loading is
supposed to be completely async and the EffectLoader emits a signal
whenever an Effect got loaded. The EffectsHandlerImpl is supposed to
connect to this signal and insert it into its own Effect management.
Unloading is not performed by the loader, but by the EffectsHandler.
There is one important change which needs to be implemented: the ordering
cannot be provided by the loader and thus needs to be added to the
Effects directly.
So far only the BuiltInEffectsLoader is implemented. It's not yet
integrated into the EffectsHandlerImpl, but a unit test is added which
tries to perform the various operations provided by the loader and the
BuiltInEffects. The test should cover all cases except the Check Default
functionality which is only used by Blur and Contrast effects. This
cannot be mocked yet as the GLPlatform doesn't allow mocking yet.
We don't need to protect the build system against adding extra
directories in the CMAKE_MODULE_PATH This also prepares kde-workspace
to be build with a simple CMakeLists.txt in the root directory.
