Commit graph

64 commits

Author SHA1 Message Date
Martin Gräßlin
8797f826f9 [wayland] Determine whether libinput is needed from plugin metadata
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.
2015-07-16 10:54:29 +02:00
Martin Gräßlin
f7d317601e Install a categories file for kdebugsettings
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.
2015-07-15 12:02:31 +02:00
Martin Gräßlin
3fe270b804 [wayland] Enforce basic render loop
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".
2015-07-10 08:57:56 +02:00
Martin Gräßlin
f6458fa1e8 Port away from KToolInvocation
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.
2015-07-07 17:35:57 +02:00
Martin Gräßlin
a4ca6f196e [wayland] kwin_wayland is no longer a kdeinit_executable
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.
2015-07-06 09:57:30 +02:00
Martin Gräßlin
94827c7405 [wayland] Introduce automatic backend selection
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
2015-06-29 11:59:27 +02:00
Martin Gräßlin
fa7b2fd055 [wayland] Improve passing env variables to applications started by KWin
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.
2015-06-29 10:51:37 +02:00
Martin Gräßlin
6e58d50efa [wayland] Drop EGL_PLATFORM env variable from QProcessEnvironment passed to launched processes
Can result in interesting crashes of the launched processes, if KWin uses
e.g EGL_PLATFORM=hwcomposer.
2015-06-13 21:29:56 +02:00
Boudewijn Rempt
d457a8d92b This line wasn't intended to go in. 2015-06-13 19:10:33 +02:00
Martin Gräßlin
859a3bb598 [wayland] Add support for PlasmaWindowManagement interface
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.
2015-06-13 18:23:54 +02:00
Boudewijn Rempt
98bcdbe70a [wayland] Add a command-line option to start an input method server
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.
2015-06-13 04:06:12 +02:00
Martin Gräßlin
604b6d05f5 [wayland] Ensure Compositor is destroyed early enough
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.
2015-05-27 09:13:33 +02:00
Martin Gräßlin
c798977e55 [wayland] Ensure KWin::atoms are destroyed before doing xcb_disconnect
Destroying the Atoms might call into xcb as a request might have to be
discarded. If atoms are destroyed after disconnecting xcb, this'll crash.
2015-05-26 14:26:56 +02:00
Martin Gräßlin
f81655b7f5 [wayland] Ensure our own windows don't have flag Qt::X11BypassWindowManagerHint
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.
2015-05-26 13:53:23 +02:00
Martin Gräßlin
64e01ac2ca [wayland] Use QProcess to start XWayland server
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.
2015-05-21 15:11:11 +02:00
Martin Gräßlin
f885ce3796 [wayland] Implement notify in ApplicationWayland
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.
2015-05-20 13:11:17 +02:00
Martin Gräßlin
74ae2f503e [wayland] Flush QtWaylands wl_display and KWin's wayland server when processing events
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.
2015-05-18 15:31:40 +02:00
Martin Gräßlin
29c2ae57e0 [wayland] Use a dummy window for QtWayland's popup window handling
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.
2015-05-18 15:31:40 +02:00
Martin Gräßlin
3f94a2afc7 [wayland] Ensure QWindowSystemInterface::sendWindowSystemEvents gets called in EventDispatcher
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.
2015-05-18 15:31:40 +02:00
Martin Gräßlin
a9649885ed [wayland] Disable Qt's client side decoration for KWin
KWin's own windows don't use decorations, so we don't want Qt's
decos either.
2015-05-18 15:31:39 +02:00
Martin Graesslin
e12400a675 Add a hwcomposer backend based on libhybris
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+.
2015-05-08 10:28:52 +02:00
Martin Gräßlin
2220ae44c4 Create a plugin for each of the wayland backends
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).
2015-05-06 10:31:39 +02:00
Martin Gräßlin
33fb763e37 [wayland] Introduce a deviceIdentifier in AbstractBackend
To be used by the concrete backends for e.g. framebuffer device name,
DISPLAY or WAYLAND_DISPLAY variable.
2015-05-06 09:38:18 +02:00
Martin Gräßlin
d45cf6ee8d [wayland] Add an initialWindowSize to AbstractBackend
Useful for windowed backends like X11 and Wayland.
2015-05-06 09:26:51 +02:00
Martin Gräßlin
17d5839580 [wayland] AbstractBackend can emit an initFailed signal
Replaces the custom handling for Wayland and X11 Backend. Now they can
just emit the initFailed signal.
2015-05-06 09:26:51 +02:00
Martin Gräßlin
0782252f72 [wayland] AbstractBackend provides signal screensQueried
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.
2015-05-06 09:05:37 +02:00
Martin Gräßlin
b2f5873a28 [wayland] X11WindowedBackend anounces input support by itself
It's the one knowing what it supports, no need to do it outside.
2015-05-06 09:05:37 +02:00
Martin Gräßlin
c4f8bed815 [wayland] Use a pure virtual AbstractBackend::init method
Two backends already used an init method, let's make that the same
in all backends to be able to have shared startup code.
2015-05-06 08:34:26 +02:00
Martin Gräßlin
72db1e63a3 [wayland] Move backend implementations into a backends/<name> directory
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
2015-05-05 13:05:37 +02:00
Martin Gräßlin
3a05e4b535 Update ScreensDrm whenever the screens got queried in the DrmBackend
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.
2015-04-24 12:03:20 +02:00
Martin Gräßlin
c759551340 [wayland] Add a basic drm/kms backend
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
2015-04-24 12:03:19 +02:00
Martin Gräßlin
c8ebcf4ca2 [wayland] Pass X11 events through the native event filters
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.
2015-04-22 11:23:06 +02:00
Martin Gräßlin
db34ddda53 [wayland] Add positional arguments to be programs to starts
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.
2015-04-21 11:21:28 +02:00
David Edmundson
10f1dc3fcb Don't follow QT_DEVICE_PIXEL_RATIO
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
2015-04-17 18:13:48 +02:00
Martin Gräßlin
2b185fa7e0 [wayland] Set internal cursor through WaylandCursorTheme in AbstractBackend
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
2015-04-02 14:37:23 +02:00
Martin Gräßlin
de3788c094 [wayland] Add a framebuffer backend
The framebuffer backend currently only supports the QPainter backend
if the format matches RGB32.

It does not yet support any cursors.
2015-04-01 11:05:45 +02:00
Martin Gräßlin
f4005c7f74 [wayland] Add initial support for taking over VirtualTerminals
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.
2015-04-01 11:05:45 +02:00
Martin Gräßlin
49f58059c6 [wayland] Backends are no longer singletons
They are installed in the WaylandServer, thus we don't need an explicit
singleton accessor. If we need to differentiate we can cast.
2015-03-23 14:29:07 +01:00
Martin Gräßlin
ee186a68c4 [wayland] Improve decision which backend to create
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.
2015-03-23 12:45:21 +01:00
Martin Gräßlin
6bf44b7db4 [wayland] Add an X11 output backend
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.
2015-03-20 14:08:53 +01:00
Martin Gräßlin
f73da18f2e [wayland] Enforce the wayland QPA
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.
2015-03-17 10:31:18 +01:00
Martin Gräßlin
79c49e84a4 [kwin_wayland] Pass socket file descriptor to QtWayland
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.
2015-03-17 10:20:19 +01:00
Martin Gräßlin
69a13a779d [kwin_wayland] Start Xwayland through socket file descriptor
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.
2015-03-17 10:20:19 +01:00
Martin Gräßlin
9dcd123438 [kwin_waylnad] Fix support for QtWayland's client buffer integration
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.
2015-03-17 10:20:19 +01:00
Martin Gräßlin
50ef02fa1b [wayland] Start Compositor and Scene before Workspace
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.
2015-03-17 10:20:19 +01:00
Martin Gräßlin
7e0fcc5f1a [kwin_wayland] Create screens prior to Xwayland
Gives us the correct outputs in Xwayland direct from start.
2015-03-17 10:20:19 +01:00
Martin Gräßlin
00739867b4 [kwin_wayland] Move starting Xwayland into performStartup 2015-03-17 10:20:19 +01:00
Martin Gräßlin
7369a2c3a5 [kwin_wayland] Support using platform wayland for the QPA
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.
2015-03-17 10:20:19 +01:00
Martin Gräßlin
7843bbdbfb [xwayland] Drop options to start Xephyr or Xvfb
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.
2015-03-17 10:08:27 +01:00
Martin Gräßlin
47bdce074e Let the fun begin: start a WaylandServer in kwin_wayland
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.
2015-03-17 10:08:27 +01:00