Commit graph

12 commits

Author SHA1 Message Date
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
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
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
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
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
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
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
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
f9a7b94ee7 Create dedicated kwin_x11 and kwin_wayland binaries
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.
2014-08-18 08:50:44 +02:00