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
This makes QCursor::pos and QCursor::setPos function correctly. KWin
actually wouldn't need it as KWin has the KWin::Cursor replacement, but
it allows Qt internal API to have it function correctly and also the
zoom effect does use QCursor::setPos.
We need to also destroy all idle objects when we tear down the
internal client connection. Otherwise the cleanup tries to free
the object after our Wayland connection is already destroyed.
During startup it might happen that the QPA is already loaded, but
the wayland server and it's internal connection not yet fully
created. Thus safety check for it.
This is needed to make KWin build-able on non-Linux, but is actually
only a workaround. The dependency should also be available on non-Linux.
This disables the EGL integration in the Wayland backend (QPainter still
available) and the EGL fallback in the qpa plugin (preferred context
sharing still available, but requires a working OpenGL Scene).
REVIEW: 126202
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 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.
Basically a simplified fork from kwayland-integration.
We cannot use the idletime plugin from kwayland-integration as it
a) doesn't react on our own qpa plugin name
b) performs blocking roundtrips in the main thread -> freeze
This simplifies by using our internal registry and we don't even check
whether Seat and Idle are announced: we know they are.
Reviewed-By: Bhushan Shah
KGlobalAccel plugin gets deleted by a global static. At that point
InputRedirection is already deleted but the plugin holds a static pointer
to it.
This change connects to the deleted signal by InputRedirection and
ensures that the plugin doesn't call into the deleted code any more.
This is the beginning of a new testing era for KWin: finally we are
able to test against a running KWin. This works by making use of the
new virtual framebuffer backend for Wayland. It starts a specific
Application subclass which is mostly a fork of ApplicationWayland.
The individual tests are able to influence the socket name and the
size of the virtual screen. This is supposed to be done in
initTestCase. To know when KWin is fully started one can use the
workspaceCreated signal of KWin::Application. KWin is not started in
another process, but the kwin library is used, so the test has pretty
much full introspection to everything going on inside KWin. It can
access the Workspace, WaylandServer, fake input events through
InputRedirection and so on.
Once the test KWin is running it's possible to connect to it using
KWayland::Client library. This allows to introspect the Workspace
to see whether all worked as expected (e.g. correct stacking order,
active window and so on).
This first autotest is mostly meant to illustrate how to setup a
test and how one can use KWayland::Client to interact with the mock
KWin. For more tests it is suggested to move the connections to the
Wayland server in the init() and cleanup() methods.
The change also affects the qpa plugin: the specific check to only
run in binaries called kwin_wayland doesn't hold any more. This can
now be overwritten by an env variable.
Please note that this first test will probably fail in the CI system
as it might not have XWayland which is needed by KWin.
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
Overwrite the platform name through the environment variable and ensure
that the plugin is not picked in non-kwin Wayland sessions as that puts
kglobalaccel5 into a crash restart loop.
BUG: 349911
The KGlobalAccelD which gets created by KWin needs a plugin for the
platform specific parts. This change introduces such a plugin. It's
linked against kwin so that it can integrate with the core.
On enable the plugin registers itself in the InputRedirection and
GlobalShortcutsManager checks the plugin whether a shortcut got
triggered.
As the loading of the plugin must happen after InputRedirection is
fully created a dedicated init method is added to InputRedirection.
REVIEW: 124187
