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.
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.
The QtWayland QPA plugin does not create windows with
X11BypassWindowManagerHint which means that KWin's internal windows are
not shown at all. Even worse in QtQuick it can result in a freeze due to
blocking wait for a frame rendered which can just never happen.
As windows could be created by e.g. scripts or look and feel packages we
cannot ensure that the flag will never be set in source code.
Thus we use ApplicationWayland::notify to filter for Show events and
check whether the window to be shown is bypassing window manager hits.
If it is, we unset the flag, destroy the window and show a new one.
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.
QtWayland and mesa might dead lock KWin if we start rendering a QWindow
before Qt/Mesa got the last frame callback. They perform blocking wayland
event reading on the main gui thread which makes it impossible for KWin
to do the compositing and send the callback.
To workaround this problem we fake a frameRendered directly after each
damage event for a Qt internal window. Unfortunately this is not yet
completely sufficient, thus we also need to ensure that the wayland
events are processed before any events are processed which would cause
a repaint and block. Thus we first flush QtWayland's wl_display and then
our Server connection. If there were any damage events we can be sure
that the frameRendered is sent before Qt attempts to render.
QtWayland only creates popup windows if they have a parent QWindow or
if there is any window which had input. It's not enough to fake an
enter, it needs to be either a pointer button press or key press.
As KWin's useraction menu doesn't have a parent and we most likely
never send a pointer press to any QWindow it doesn't get shown. To
circumvent this we create a dummy window and fake a button press/release
on the window. After that Qt is tricked into believing there's a parent
window and shows the popup.
Faking the input is only done with at least Qt 5.5 as QtWayland crashes
on pointer event without a keymap being installed. As KWin does not yet
send keymaps we better disable the dangerous code path. With Qt 5.5 the
crash condition is fixed.
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.
