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
