Summary:
Increases minimum Qt version to 5.7. This allows to drop the pre-5.7
virtual keyboard and various ifdefs for now unsupported versions.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D4485
On build.kde.org the autotests started to crash on tear down due to a
newer Wayland library. The reason is that the KWayland::Client::Outputs
are destroyed after the internal Wayland connection is destroyed.
This change parents the created Outputs to the Registry like the other
objects. To ensure that the KWin::QPA::Screen doesn't have a problem
with that, it is changed to a QPointer - nullptr checks are already in
place.
Hopefully that will fix the crashes on build.kde.org, but there is a
chance that more errors are hidden.
Summary:
So far SharingPlatformContext was only used if the OpenGL context
supports EGL_KHR_surfaceless_context. If not supported, KWin tried to
create a context through the Wayland API. Unfortunately on hwcomposer
platform this results in a crash as libhybris only supports the init
of EGLDisplay for one native platform.
This change tries to also use the SharingPlatformContext if there is
an OpenGL context in general. It reuses the native EGLSurface created
for the compositing scene and makes its own OpenGL context current on
that surface, too. As KWin creates an FBO, it never renders to it, so
it shouldn't matter at all.
In order to prevent EGL_BAD_MATCH errors when making Qt's OpenGL context
current also the EGLConfig from the scene is used to create the context.
Test Plan: Tested on Nexus5 with qtvirtualkeyboard in KWin
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2231
We didn't check whether creating the QPlatfromInputContext worked and
accessed the m_inputContext unconditionally which obviously crashed.
Now the connects related to QInputMethods are not setup if we failed
to create the QPlatfromInputContext.
Reviewed-By: bshah
Summary:
The idea is to have KWin provide a virtual keyboard. To support this
KWin uses the QT_IM_MODULE qtvirtualkeyboard and makes sure that the
QPA plugin loads it.
KWin has a new class VirtualKeyboard which acts as the focus object and
the "proxy" for input methods. The QPA plugin ensures that this is the
focusObject, so that all input method related events are sent to this
class. From there it will be possible to delegate to other applications
through the Wayland interfaces.
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D1638
Qt has problems initializing everything correctly if there is no screen
at startup. E.g. the breeze widget style tries to initialize some pixmaps
and this fails. In worst case hitting asserts in Qt (debug build).
This change creates a dummy screen which gets destroyed as soon as there
is a real screen.
Reviewed-By: notmart and sebas
ASAN righly complained: we need to delete our Wayland objects before
we destroy the internal client connection. Solved by better setting
parent relationships in the QPA plugin and correctly delete objects
in destroy of internal client connection.
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.
This introduces an own QPA plugin for KWin. QtWayland's plugin is not
a good solution for KWin as QtWayland is meant for Wayland clients and
not for a Wayland server. Given that it makes more sense to have a very
minimal QPA plugin which supports the use cases we actually have.
With our own QPA plugin we should be able to improve the following
areas:
* no need to create Wayland server before QApplication
* Qt::BypassWindowManagerHint can be supported
* no workaround for creating OpenGL context in main thread
* sharing OpenGL context with Qt
* OpenGL context for Qt on libhybris backend
The plugin supports so far the following features:
* creating a QPlatformWindow using KWayland::Client (ShellSurface)
* creating a QPlatformBackingStore using a ShmPool
* creating a QPlatformOpenGLContext with Wayland::EGL
* or creating a QPlatformOpenGLContext which shares with KWin's scene
* creating a QPlatformScreen for each KWayland::Client::Output
* QPlatformNativeInterface compatible to QtWayland
