Summary:
This is the first change in a refactoring series. The aim is to:
* rename AbstractBackend to Platform
* move backends/ to plugins/platforms/
* don't bind platforms to Wayland only
* provide a platform plugin for "normal" X11
* share more code between X11 and Wayland
This change moves the platform/backend from waylandServer to Application.
The init of the plugin happens directly in the Application from the
KPluginMetaData. There is no need to externally init it and set the
parent.
WaylandServer::backend() currently just delegates to
kwinApp()->platform(), the idea is to drop this method completely.
The test infrastructure is also adjusted to this change.
Test Plan: kwin_wayland still works, all tests pass
Reviewers: #plasma, sebas
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1331
The event filter is only used to let Qt compose a QKeyEvent from an
x11 event for grabbed key events. On Wayland we don't need it as we
can generate good QKeyEvents ourself. This means less event processing
as the events no longer need to pass through the
Workspace::workspaceEvent.
In addition it fixes a regression in LockScreenTest::testEffectsKeyboard
caused by the LockScreenEventFilter sending a QKeyEvent to KSldApp.
This event got intercepted by the global event filter making the test
rightfully fail.
This patch introduces additional method to Application class
that has default policy of restarting the app.
This method is overridden for wayland case disabling this step.
REVIEW: 126655
This change enables kactivities integration by default again on both
X11 and Wayland (as kactivities no longer blocks). As we have an
infrastructure to disable kactivities we can also make use of it and
offer a command line switch to disable kactivities. This might be
useful for using KWin outside of Plasma.
REVIEW: 126153
Instead of setting our own filter rules we install a categories file
to allow to configure them. This seems to still have them enabled by
default, but should at least give distributions the possibility to
disable logging by default.
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.
If startup fails and there is no Workspace the Compositor was destroyed
as a child of Application with the result of being destroyed after the
Wayland server resulting in a crash.
If the Workspace gets created the Compositor will be destroyed by the
Workspace, so there's no need to destroy it early.
This change is motivated by the fact that we need to suspend libinput
before switching the virtual terminal. Also we don't want to take over
libinput if we do not have a VirtualTerminal created - in windowed mode
we don't want libinput to be started. So binding it to the backends which
create the VirtualTerminal makes sense.
The KWin::Application gains a new signal virtualTerminalCreated which is
emitted from VirtualTerminal once it's properly setup. This is used by
Input to create Libinput integration instead of binding it to logind.
Furthermore Libinput gets suspended when the VirtualTerminal reports that
it is no longer active. For re-activation we still just use logind's
session active property.
For Xwayland we need to have the Scene (and EglDisplay) created prior
to starting Xwayland and having X11. This requires creating the
Compositor before creating Workspace and starting Xwayland.
To support this the startup of Compositor is split into two parts:
prior and after Workspace creation.
The change might also be interesting for the kwin_x11 case as it could
result in the compositor being up in a quicker way.
The --xwayland option starts a rootles Xwayland server. If a
rootless Xwayland server is used OperationModeXwayland is used
which is introduced with this change as well.
KWin::connection() uses the property to resolve the value instead of
using QX11Info. In practice this doesn't change anything at the moment,
but allows kwin_wayland to provide an xcb connection without depending
on QX11Info.
As we cannot make xcb_connection_t* available as a metatype, the
property's type is set to void*.
KWin::rootWindow() uses the property to resolve the value instead of
using QX11Info. In practice this doesn't change anything at the moment,
but allows kwin_wayland to provide a root window without depending on
QX11Info.
The porting to Qt5 broke the timestamp handling in many areas. A deeper
look into Qt's xcb plugin shows that the appTime handling is not
sufficient for KWin's need. E.g. the time is only updated in response to
a property notify event if it's for a Qt created window, which is hardly
ever the case in KWin. Another example is that key press/release events
never updated the appTime.
As the functionality in Qt is rather trivial we can do the timestamp
handling ourselves. We filter all events anyway and it is slightly faster
as we don't have to go through the QPA interface any more.
REVIEW: 122636
Adjust the KWIN_DBUS_SERVICE_SUFFIX env variable in a multi-head
scenario instead of adjusting the "org.kde.kwin" DBus service which
we actually don't use in 5.x any more.
REVIEW: 122217
kwin_wayland gains a new command line option to enable libinput support.
This is needed as logind blanks the VT when the session controller
releases the control. So a nested compositor can seriously affect the
primary session. Thus it needs a dedicated command line switch to
enable it.
By default libinput support is disabled for kwin_x11 and can be enabled
for kwin_wayland in case KWin is compiled with libinput support.
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.
KWin requires the xcb plugin otherwise KWin crashes when the first
xcb/xlib code is called. First KWin tries to set the QT_QPA_PLATFORM
to "xcb", but that doesn't protect against the command line switch.
Thus KWin also verifies that after constructing the QGuiApplication
the platform name is set to xcb, if not it exits gracefully with a
useful error message instead a crash.
To make that work the KWinSelectionOwner has to be changed to a
pointer and be delayed constructed, otherwise the crash already happens
in the KSelectionOwner.
Furthermore a small sanity check on the plugin is performed by checking
whether KWin can get the XDisplay from the QPA. If not it means that the
QPA plugin was compiled with -no-xcb-xlib which KWin doesn't support, it
still uses XLib at various places. If KWin doesn't get the Display, it
exits gracefully with a clear error message.
CCBUG: 331880
REVIEW: 116669
In the Wayland world we need to have a compositor. This means we have to
enforce that the compositor is running. If the setup fails we have to
quit, because it doesn't make any sense any more to be running.
A new method requiresCompositing() is added to the Application. If it
returns true the useCompositing option will always return true and the
unredirect fullscreen option will always return false. That way
compositing is enforced at startup and cannot end by unredirecting.
In addition this method is checked if actions are performed which would
suspend compositing. E.g. the shortcut to toggle compositing. Restarting
the compositor is still possible in order to change the selected
compositing backend without a restart. But if it fails KWin will quit.
Returns true if the OperationMode requires KWin to composite to a
Wayland surface. This replaces the checks for the WaylandBackend or env
variable used so far in the construction of the Scene.
This enum describes how KWin is operating with the available windowing
systems. By default KWin is using the OperationModeX11, but if the
Wayland backend gets started KWin is using the OperationModeWaylandAndX11
This will be extended in future when XWayland and Wayland only become
viable options.
The idea is that we can use the Application instance as a place to put
global information which should not go into kwinglobals. That is core
global things.
The crash count checking does not depend on whether or not we will
be able to claim the window manager selection. As claiming the selection
can take up to one second we should try to get as many checks which do
not depend on it out.
Done in one step as it requires changes which are better suited with a
QApplication.
To not need to parte the QCommandLineParser around the needed arguments
are added to the KWin::Application through setters and the crash count
is available through a static getter/setter pair.
Forwards all xcb events to Workspace::workspaceEvent() which got changed
to process xcb events instead of XEvents. So far all handling is
disabled. Will be re-enabled step by step in the following patches.
being v2+ (right now it says just GPL, which according to GPL itself
means any GPL). Decoration clients will come later.
CCMAIL: kwin@kde.org
svn path=/trunk/KDE/kdebase/workspace/; revision=742302