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.
This backend interacts with libhybris to create a hwcomposer which is
used for creating the egl context and surface. The initial version of
this backend is based on test_hwcomposer.cpp provided by libhybris.
Please note that using the hwcomposer backend requires a newer libepoxy,
the latest stable release is not able to bring up OpenGLES, so one needs
a master build of libepoxy.
Notes on licensing:
libhybris is Apache 2.0 licensed, which is not compatile with GPLv2.
But it is compatible with GPLv3. Thus the source files in the hwcomposer
backend are licensed GPLv3+ and not GPLv2+ as the rest of KWin. If one
uses KWin without the hwcomposer backend (which is obviously the default)
the licence doesn't change. But if the hwcomposer backend is used the
overall license of KWin changes to GPLv3+.
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).
With this change all backends need to emit the screensQueried signal
at some point. So far only x11 backend did not provide the signal,
wayland had a comparable delayed init mechanism. Now all backends use
the same mechanism.
The aim is to be able to create a plugin for each of the backends.
The following directories are created:
* backends/drm
* backends/fbdev
* backends/wayland
* backends/x11
Requires to move the screensQueried signal and disconnect during
Application startup.
As Screens only hold the geometry of each screen and the overall
geometry, there is no need (yet) to update in more detail when a
DrmOutput is added or removed. The overall queried is sufficient.
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
E.g. KSelectionOwner installs a native event filter and listens for
xcb events. Without that the KSelectionOwner::claim never succeeds and
for other X11 applications it will look like Compositing is not
supported.
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.
Setting this means we get scaled screen geometry from Qt, and everything
becomes confusing when commmunicating with apps that might not have
this set.
As we use plasma units for UI everything is scaled anyway.
REVIEW: 123115
Getting the cursor image from the cursor theme is unfortunately not
straight forward. We have three different libraries and all have
drawbacks:
* XCursor - we just kicked it out
* xcb-util/cursor - only provides xcb_cursor_t, so a dependency on X
* wayland-cursor - only a client side API
The picked solution is using wayland-cursor. It provides the cursor in a
wl_buffer. Unfortunately the client side API does not easily allow to
a) read it back
b) init without a wl_shm_pool
Thus we need to work this around:
* create an internal connection
* get a ShmPool on it
* init WaylandCursorTheme with this ShmPool
* get the cursor wl_buffer from the theme
* trigger a roundtrip
* get the corresponding BufferInterface for the buffer
* set the content as the software cursor
A new Singleton VirtualTerminal is added. It interacts with Logind to
get the VTNr to take over. To get the signal to release and acquire the
VT we use a signalfd with a QSocketNotifier to monitor for signals. The
used signals must be blocked for all threads prior to startup otherwise
they are delivered to secondary threads causing issues.
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 new backend allows to start a kwin_wayland server nested on an
X-Server by using a normal X11 window as output. This allows testing
kwin_wayland without needing to start another Wayland server first.
The behavior is triggered by using new command line arguments:
--windowed
--x11-display=<:0>
With optional --width and --height arguments.
In this mode the WaylandBackend is not created at all.
So far the backend is not fully integrated yet and only the QPainter
backend supports this mode.
This requires a change present in Qt 5.4.2, without the startup will
freeze. A warning message is shown if the compiled Qt version is not
at least 5.4.2. It's only a warning and an ifdef as distros might
backport the required change.
WaylandServer allows to create a ClientConnection which is intended for
QtWayland. This allows us to easily identify our "own" surfaces. The
created file descriptor is set as env variable WAYLAND_SOCKET prior to
creating the Application. Wayland will unset it after connecting, so we
don't need to unset it. This removes the hack of setting and resetting
the WAYLAND_DISPLAY environment variable.
Creates a socketpair in WaylandServer and creates a ClientConnection for
Xwayland. The created file descriptor is passed to Xwayland through the
WAYLAND_SOCKET env variable.
QtWayland performs an eglInitialize in the main thread when for the first
time an OpenGL context/window is needed. In KWin's startup this happens
during initializing Scripting which creates a QDesktopWidget and triggers
the creation of a QWindow with a RasterGLSurface.
Calling eglInitialize in the main thread blocks as it calls wl_roundtrip.
We cannot just disable OpenGL as that would mean that we cannot use
QtQuick.
The workaround in this change is to create a QWindow with a
RasterGLSurface in a thread and call create on it. This ensures that
OpenGL gets initialized in the thread and doesn't block.
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.
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.
Only --xwayland stays supported. The option --displayfd and --rootless
are always set. Simplifies the feature matrix and the other X servers
don't make any sense now that we can start a proper rootless Xwayland.
The WaylandServer is at the moment only used to support starting an
Xwayland. It does not support Wayland clients yet, so don't get
excited.
For Xwayland it's using the trick of creating the Display before the
QApplication is created with manual event dispatching.
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.
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.
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
KWin_Wayland still needs an X-Server. To simplify the development
setup the required X-Server can be started through a command line
argument together with KWin. Unfortunately the command line arguments
processing needs to be done by hand as QCommandLineParser only allows
processing after QApplication is created which requires the started
X Server.
The nested X-Server is started by forking the application and using
execlp to load the binary. In addition a pipe is created to allow the
X-Server to write the display number to once it's ready to connect and
by that KWin is ready to create the QApplication.
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.
