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
We need to unblock the signals blocked with pthread_sigmask.
This caused kdeinit to block, because it relies on SIGUSR1.
BUG: 356580
FIXED-IN: 5.5.1
REVIEW: 126361
In order to increase the security we disable ptrace on kwin_wayland.
This makes it impossible for a another process running as the same
user to attach to kwin_wayland to install a key logger. It doesn't
protect against higher privileged users, but that's no problem: they
can just read the input device file and don't need to attach to KWin
to become a key logger.
This change is highly inspired by a similar change to kscreenlocker.
A difference is that KWin checks whether we are running under a
debugger. In such a case we still want to allow ptrace.
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
Ensures that all Wayland objects are destroyed and the cleanup handling
is performed before tearing down the Compositor. This fixes for example
a crash if a Surface with a Shadow is still around at tear down.
WaitForFinished blocks our main thread, but Xwayland wants to talk
to Wayland and blocks as well. So let's ensure events are processed
while terminating Xwayland.
Some effects do X11 calls in their cleanup code through external
libraries (e.g. KSelectionOwner). As we cannot control that we need
to ensure the effects are unloaded prior to destroying the Xwayland
connection.
We need to destroy the ClientConnections we create. Also we need
to disconnect our Xwayland error handling before destroying it, otherwise
it would trigger the abort for crashing Xwayland.
During Compositor tear down Xwayland is already destroyed. Thus it
doesn't make sense to try to delete the support properties: either
it freezes in xcb or it crashes because the connection is null.
At the same time we also ensure that the connection internally is
reset to null. Note: the one in kwinglobals.h caches and could cause
use-after-free errors. Any tear-down code must be migrated to
kwinApp()->x11Connection().
We need to destroy the compositor after Xwayland terminated and after
the internal Wayland connection is destroyed. This means when destroying
the Workspace we may no longer destroy the Compositor at the same time.
Also we need to ensure that other tear down functionality doesn't call
into the no longer existing internal client connection.
With this change kwin doesn't crash when exiting with Wayland and/or
X11 windows still open.
-use qstringliteral only when necessary (i.e. not in concat or comparison)
-use qbytearray instead of qstring when dealing with latin1 input and output (glplatform)
-use qstringref to extract numbers from strings (glplatform)
-define qt_use_qstringbuilder to optimize all string concatenations
-anidata: use ctor init lists, add windowType member initialization
REVIEW: 125933
This introduces --lockscreen option in kwin_wayland which when used will
lock screen immediately. Also dependency to newly created kscreenlocker
repo is introduced.
REVIEW: 125954
We only need to force QT_QPA_PLATFORM to be our own plugin when starting
the application. As KWin starts other processes (e.g. kcmshell5) we need
to ensure that the env variable has a sane value. No other process can
load our QPA plugin after all.
Reviewed-By: Bhushan Shah
We already unset QT_DEVICE_PIXEL_RATIO to ensure to keep out of
high dpi scaling. Now with Qt 5.6 we also need to set the attribute.
Without we crash on startup as we don't have a screen that early and
well Qt doesn't check whether it's null.
The change to reflect the available plugins in the command line options
had side effects as that made it impossible to start KWin if certain
plugins are not available.
This change ensures that we only check the option value if they are set
in the first place.
In addition the multi checks to verify whether combinations are valid
is removed as that makes in reality no sense any more (only few plugins
installed by distros) and doesn't scale any more with the increasing
numbers of backends.
A new backend which doesn't present the rendered output. It uses a
QPainter scene, renders to a QImage but doesn't present it anywhere.
Thus a real virtual backend.
By exporting the environment variable KWIN_WAYLAND_VIRTUAL_SCREENSHOTS
the backend creates a temporary dir, prints the path to std-out and
saves each rendered frame into that directory. Of course with exit it
will be deleted again.
As distributions do not ship all plugins let's try to filter the options
based on the plugins which are actually available. There is no point in
allowing e.g. framebuffer just to notice then that the plugin is not
shipped ending in confusing error for the user. So let's only add the
options which actually make sense.
Distributions do package each backend plugin in a dedicated package,
which means just because KWin got compiled with a specific backend,
doesn't mean it is also available at runtime.
In order to better support this reality this change introduces a
list-backends command line option. Each of the plugins got the json
metadata extended by the KPlugin syntax, so that we have a name and
description to print.
As we already locate all plugins anyway, the additional findPlugins for
the selected backend is changed to search the list of all plugin meta
data.
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.
Our QPA plugin does not require a running Wayland server at startup,
so we can move the startup after creating the application.
Nice side effect: --help works now.
The hack to perform the first eglInitialize in a thread is no longer
needed, as our internal QPA plugin is either able to share the
EGLDisplay or performs the potentially blocking eglInitialize in a
thread.
If the backend specifies
{
"input": false
}
in it's plugin metadata, it means that it does not handle input by
itself. In that case we can enforce libinput.
With this change one does no longer need to specify --libinput when
starting kwin_wayland on the drm or fbdev backend. So
kwin_wayland --xwayland
will bring up a fully functional kwin_wayland on drm platform.
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.
Looks like Qt 5.5 changed the default back to threaded and that can
result in dead locks of the compositor. So better enforce to basic
for the time being.
Another reason to have an own QPA to get rid of these "regressions".
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.
kdeinit_executable doesn't make sense in the case of kwin_wayland as
start_kdeinit_wrapper will be executed after kwin_wayland thus the
framework doesn't work.
If none of the backend specific command line options are passed, we
try to autmatically determine the proper plugin.
1. if DISPLAY is set -> x11 backend
2. if WAYLAND_DISPLAY is set -> wayland backend
3. if compiled with libhybris and ANDROID_ROOT is set -> hwcomposer backend
4. if compiled with DRM -> drm backend
5. if nothing selected yet, fallback to fbdev
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.
So far this only allows to trigger show desktop functionality and exports
the state.
In future this should be restricted to just one dedicated desktop shell
process.
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.
