The connect to Compositor::sceneCreated must be disconnected again,
otherwise a restart of the Compositor results in Workspace being created
again.
Thanks to our autotests for finding this problem!
Summary:
Just continues with the steps without starting XWayland.
This does not yet fully support kwin_wayland without X11, it currently
still crashes on teardown.
Test Plan: kwin_wayland --socket=wayland-1 kwrite (note the missing --xwayland)
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7924
Summary:
This change ensures that kwin_wayland does not pull in KCrash. We
don't want and need KCrash in the Wayland case. If KWin crashes the
session goes down - restarting doesn't make any sense, we need to
relogin.
Similar drkonqi just doesn't work as it doesn't have a windowing
system to connect to. After all the windowing system just crashed.
Also the AlternativeWM dialog doesn't make any sense on Wayland.
Similar thought: there is no windowing system to show this nice dialog.
Overall it's better to have system default behavior
(e.g. systemd-coredump) than using KCrash in the very special case of
kwin_wayland.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1550
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 is similar to the applications to start. That is the value of the
command line argument is interpreted as a command to start.
The difference is that when this application exits, KWin will also quit.
The argument is so to say interpreted as a session.
Reviewed-By: Bhushan Shah
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.
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 an env variable is set outside of KWin (e.g. QT_QPA_PLATFORM) we
want KWin to pass the original env variable to the started process and
not pass none instead because it's one of KWin's special changed
variables.
Thus we take the environment before we adjust it and pass that to the
started processes with our own DISPLAY and WAYLAND_DISPLAY added.
Input-method servers, like maliit, need to be known to KWin since KWin
needs to know about virtual keyboards. Virtual keyboards should be shown
as OSD layers, and they are one of the types of windows that actually
should be showable when the lock screen is active.
kwin_wayland --inputmethod /path/to/your/input-server
tries to start the input server. The input-server's window never gets
keyboard focus and is shown on top of all windows except for KWin's
internal clients.
The code didn't use QProcess as in the early days of main_wayland.cpp
Xwayland had to be started before the QGuiApplication was constructed.
As this requirement doesn't exist any more we can use QProcess and
improve the interaction by e.g. provide useful error messages if
Xwayland couldn't be started.
If we get an Expose event for any QWindow we need to ensure that all
wayland events on both client (Qt) and server (KWin) side are dispatched.
Otherwise it could happen that Qt starts rendering although the last
frame callback has not yet been emitted, causing the main gui thread to
be blocked.
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.
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).
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
This allows to start applications once kwin_wayland is started. E.g.
kwin_wayland --libinput --xwayland --framebuffer /usr/bin/startkde
Thus it would start startkde once both Wayland Server and Xwayland
are up and running and ready for connection. This resolves the problem
that prior to startup it is not known which will be the X11 display
variable. By passing the environment to the process by KWin this problem
is resolved.
Both Wayland and X11 backend are bound to the --windowed flag. Which
one to create is decided whether DISPLAY or WAYLAND_DISPLAY env variables
are set with Wayland having precedence over X11. Passing the display as
command line argument overwrites the env variable and takes further
precedence. E.g. if WAYLAND_DISPLAY is exported and --x11-display
argument is provided, it will create X11 backend. Similarly there is now
a --wayland-display command line argument.
If no backend got created, kwin_wayland will exit.
The singleton variant of WaylandBackend is adjusted to take the display
as argument and pass it to the Connection.
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.
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.
